During the development of eosgi-e4-plugin, the following question was raised: How can we shut down the started OSGi container in the way that shutdown hooks are called?

I did a lot of searching, but could not find a satisfiable solution. Let’s see what I have found.

Executing kill command

There is the option to call kill command on Unix systems and send SIGINT or SIGTERM to the JVM. The problems with this:

• I do not want to execute one more process just to kill another one if not necessary
• There is no such command on Windows. There is no command in windows that can send SIGINT or SIGTERM to a process

Using JNA and Native calls

Another option is to use JNA. This works pretty well in Linux, but Windows is still a problem. One can call WM_CLOSE on every window of an application or send a Ctrl+C event to the console of the running process, but there is no solution if the running program neither has a console nor a window. That is the case when a process is started with Eclipse Launcher. The console of the application is redirected; therefore external process cannot send CTRL events to it.

Trick: Use Attach API and a dynamically installed Java Agent

When a programmer calls System.exit(int) or Runtime.getRuntime().exit(int) within a java process, it starts clean shutdown procedure where all of the shutdown hooks are called. The goal is to force a code snippet in the target JVM to call the exit method. How to do that?

With Java Attach API it is possible to connect to any JVM that runs on the same host. It is also possible to load a Java Agent into the connected JVM. What if the Java Agent calls the exit method? That is possible. I tested it and it works well.

To save time for others, I implemented the Java Agent as an OpenSource project and uploaded it to Maven Central. It is configurable. One can tell via the Agent arguments

• what exit code should be used for the standard shutdown procedure
• should the JVM shut down forcibly with a different exit code if the standard shutdown procedure does not end within a timeout? This can happen if a non-daemon thread is locked.

Feel free to use this technique and let us know if it worked for you!

A couple of weeks ago I sent a form to OSGi dev mailing list. I have started to share the summary of answers with the community. As there were many questions, I decided to split the content and publicize it as several posts. If you are interested, the previous part is here. This is the final part of the series.

Getting information about the container

In the last years, we worked with Blueprint, Declarative Services and we developed our component model. For Blueprint, we created a webconsole plugin; there was already one for DS and we also developed a webconsole plugin for our component model ECM.

Every time I had an issue, I opened webconsole. A bundle did not start? Let’s check it in webconsole. Is a service available? Let’s check it in webconsole. Do others work in the same way as I do? Is it good if we develop only webconsole plugins when we create a technology like ECM? I asked, and I was a bit surprised when I saw the answers:

Others:

• Cloud RTI has extensive consoles for that
• Karaf console
• Apache Karaf Shell has a lot of extra information.
• custom webconsole
• karaf shell (3x)
• Liferay’s App Manager

Oops! I think it is time to start supporting Gogo Shell, too. We will do so in the future.

Deploying modules

While I found webconsole to be excellent to get information about the system, it was difficult to use it to deploy each bundle during development. When we moved to OSGi, we started with FileInstall. That is good for a start, but the IDE should support deploying the bundles with their dependencies in my opinion. I was interested how others solve with this task.

The first answer is “Development Environment deploys them”.

Other answers:

• Cloud RTI based, or via Apache ACE
• Home made launcher
• Docker
• Apache Karaf Feature Installer does it, usually the required bundles are grouped as features and deployed accordingly.
• Karaf console
• home-made fileinstall that doesn’t yell about duplicate bundles
• Maven and bundle:watch functionality of Apache Karaf when container is running, Apache Karaf features otherwise
• Automated IDE Construction via Tycho
• exported runnable jar
• karaf shell and features
• Manually
• Karaf features
• maven
• Apache Sling OSGi Installer
• liferay-ide

Third party modules

I was interested, how others search for third party modules that have the required functionality. I typically find a technology by searching on google, download it from maven central and check if the MANIFEST headers exist. I had the idea that others might know better tricks, so I asked:

Others are:

• Sling provisioning model
• mostly manual, or a combination of the above, and we copy them into the project
• search.maven.org, usually you’ll find that the “bundle” in question is or is not build with the maven-bundle-plugin, that’s usually good enough as indicator, if not I’m using bundles from the Apache ServiceMix Project
• ServiceMix
• mvnrepository.com
• p2-maven-plugin
• Index-based search across repos within NetBeans

What problems do developers face during working with OSGi?

My first years with OSGi was a torture for me. There was a new mystery every day that we had to solve. The learning curve was extremely high. However, I believed that one day we would benefit from the sacrifice we had made.

We had to learn which patterns and technologies do not work in OSGi. Magical patterns like AOP that we loved before became our biggest enemy.  It is getting much better and I must say that our development workflow is much more effective than it was before.

I was interested if others have issues like we had. I got the following answers:

Availability of OSGi metadata from source (or correctness when available), though it’s improving (thanks ServiceMix!). Class loader and caching.

A lot of third party code is tough to modularize

Digging for dependencies when some external libraries need to be repackaged + Widespread use of ThreadContext classloader and Class.forName

The tools are still poorly integrated, dealing with services/remote services WRT tooling is overly complicated

Third party libraries with poor support for OSGi

Training younger developers and importing non osgi compatible libraries

Disconnect between OSGi community.

Camp 1 – OSGi Alliance promotes BndTools, Eclipse, Declarative services.

Camp 2 – Open source Karaf/Aries – most tutorials/solutions/user forum based around Blueprint rather than DS, use Maven rather than BndTools as poor Karaf BndTools integration.

Camp 3 – others -> Everit, Amdatu, Osgiliath, SpringDM, Gemini Blueprint, CDI

How does a new person starting with OSGi know where to start given all these different options?

Coming from JEE or Spring background it is not as easy developing OSGi applications.

Maturity of OSGi technology e.g. only recently has a speced solution for DS with transactions/JPA/JDBC been implemented.

JEE/Spring offers a lot out of the box that is easy to use e.g security, easy integation with Camel, Web services etc things that would often been considered the bread and butter in the ‘Enterprise’ space.

Documentation/examples/tutorials lacking compared with say the Spring reference manuals

No technical problems, but coworkers often lost need help because there’s very few resources online to fix problems, because of the size of the community

Integrating external technologies (like eg. Vaadin for Web UIs) which are not (really) OSGi ready in terms of missing dependencies and requirements at runtime

Integration with EJB, framework state/persistence

Dynamic proxy based Spring AOP

No IDE Refactoring for changing service reference binding (lazy) to interface binding (eager) and vice versa. No IDE Templates for using service lookup where component binding are unavailable. No IDE Templates for common OSGI methods including annotations.
ConfigurationAdmin multiton management is cumbersome especially when updating existing configuration. ConfigurationAdmin should have plugable persistence so that configuration may come from somewhere else other than the bundle storage (i.e. a Database).
IDE assistance and proposals for LDAP filter string generation.
Using Junit Test classes as a component to do integration/system tests.

steep leaning curve, feel hard to debug what’s went wrong

DS service outjection would be nice …

Adaption of legacy code to dynamics, elimination of technical dept, the utter lack of useful documentation

Some 3rd-party libraries still don’t play nice (e.g. still use Class.forName). OSGi is still not as wide-spread – despite being so much better – in the heads of people as e.g. Spring is. Sometimes missed visualization of wiring and state to analyze deployment problems in complex setups.

osgi repository is not so good to use

Tough learning curve for new developers.

Reaching out to customers is much harder than using the Java EE keyword.

Wow! People have lot’s of things in mind. I do not know how it is with others, but it was very instructive for me to read answers.

We were facing some of the issues, and we made solutions for some of them. I will work hard on making these solutions available to others within the next weeks/months. Where contact address was provided together with the answer, and we might have a solution, I will get in touch.

Introduction

I am happy to announce that three new modules are available to use that simplify the job of sending emails:

• email-api: Interfaces and classes to handle emails
• email-javamail: Java Mail (JSR 919) based implementation of email-api
• email-javamail-ecm: ECM components to use email sending functionality easily within OSGi environments

Programmers can use the API to:

• Easily create emails with TEXT or HTML content or both
• Add inline images to the HTML content
• Add attachments
• Send emails
• Send multiple emails with on one channel (faster processing)

Why did we need another API?

We investigated the available APIs in Java and found the following:

• It is very difficult to use javax.mail
• Constructing emails and sending email functionality are not clearly separated in commons-email. By not having the separation, it is not possible to build solutions where the same interface can be used to send or persist emails in a queue
• Spring needs lots of dependencies that do not work well within a modularized environment

I am happy to announce the jexl based implementation of Everit expression-api.

We have used the mvel based implementation till now. Although it is 3x faster than jexl, we decided to go with the last one due to the following reasons:

• To code of jexl is clean. In the future, we will be able to add the same optimizations as MVEL has. We could not really do bugfixing on MVEL as its code is messy.
• As jexl does not have optimizers at the moment, it works well within OSGi. We had serious issues with MVEL and due to the messy code, it was truly hard to fix them.
• Jexl uses the same syntax for inline maps and arrays as Javascript does. If we use jexl in templating-html, we will be able to use the template with a templating engine written in javascript later.