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:
- 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.
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”.
- Cloud RTI based, or via Apache ACE
- Home made launcher
- 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
- Karaf features
- Apache Sling OSGi Installer
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:
- 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
- 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.