My team and I have been working on an OSGi enterprise prototype since April 2012. We decided to use Eclipse Virgo Tomcat Server as our application server. Here is the experience collected so far, using Virgo 3.5M4 and version 1.0.0.201205110321-MILESTONE of the Virgo tools, both pre-release versions.
Documentation and other sources of information
Virgo comes with a lot of official documentation, and the documentation quality is generally high. On the other hand, if you look over the Web for articles, blog posts, forum posts etc you won't find that much besides the official documentation and the Eclipse community forums.And while the quality of Virgo is generally very high, keep in mind that if you experience an uncommon issue, chances are that you will have to solve it on your own.
A good knowledge of the OSGi specification is really required to work with Virgo. Even long time Eclipse plug-in developers may have troubles developing proper OSGi bundles, because Eclipse plug-in developers are typically used to requiring bundles rather than importing packages, and because of the different boot delegation of Equinox when used in Eclipse, see http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi/
Error reporting
Virgo is very good in giving you precise error and diagnostic information if your OSGi bundles fail to be resolved. The Virgo error messages are much much better than Equinox's and this is very very valuable.Attention points
Even if Virgo is an OSGi application server, and even if it is based on Equinox, Virgo does not support split packages and does not favor required bundles.I totally agree that split packages are evil, a very dangerous pitfall of the OSGi specification. So I was originally pretty happy with this decision, till I wanted to use the Equinox Registry in my application. In fact, I found out that the org.eclipse.core.runtime package is split across multiple bundles, and could not find a way to have the Equinox Registry bundles work "as is" in Virgo. A user in the Virgo Eclipse forums advised me to create a Plan (a virgo deployment artefact) that would include the bundles with the split package, but that did not solve my issue. I eventually worked around the problem by repackaging the Equinox registry bundles in a single bundle. Maybe other solutions are possible, but this was the fastest solution. The second important attention point is that Virgo authors dislike the use of Require-Bundle manifest header. I again understand the decision and I agree that one should prefer Import-Package, but what I dislike is that Virgo offers an alternative header attribute Import-Bundle that is Virgo specific, and does not belong to the OSGi specification. It is a sort of macro which will make Virgo enhance your bundle headers at deploy time to make them import all packages of the imported bundle. While this may appear as a convenient macro, it is Virgo specific and it will prevent your application from running in other OSGi containers or OSGi application servers (unless of course you modify the MANIFEST). So I have decided not to use it.
IDE Tools
If you are a long time Eclipse plug-in developer like me you are probably used to the PDE and love it, and you may expect to be able to develop bundles for Virgo using PDE.Unluckily this is not possible, and you have to use the Virgo Tools, a totally different toolset. You could develop bundles with PDE, export them as binaries and deploy to Virgo, and it will of course work, but if you want to be able to build and run from the workspace your projects cannot be PDE plug-in projects but must be Virgo Tools' OSGi Bundle projects. The bad thing here is that developing with Virgo Tools is not as smooth as developing with PDE tools.
Here are a few examples:
- Much like PDE, Virgo Tools add a container to your project build path. The container should automatically populate the classpath according to bundle dependencies. In practice, the container is often out of sync resulting in spurious build errors, and you have to open the MANIFEST, add a blank, save and build to fix them. Plus, if you don't use autobuild, you'll need to build twice: once for the container to be updated after you change the MANIFEST and a second time for the code to be compiled after the container has updated.
- If you want to import a package from another bundle in the workspace, you must enlist the other bundle in your Project References property page for the container to see it, but the MANIFEST editor will not help you, you'll need to switch to the source view and manually add the imported package.
- If one of your workspace bundles exports packages that are included in some embedded JARs and you need another bundle to use classes from those packages, you'll have again to manually import the package, but you'll also need to add those JARs to your Java Project Buildpath, otherwise the dependant bundle will not compile, because the container will never see the JARs.
Runtime Bugs
We spotted 3 defects, two related to the EclipseLink - Gemini JPA integration:https://bugs.eclipse.org/bugs/show_bug.cgi?id=381369
https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397
And one in the EcilpseGemini Web component, part of Virgo Server:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=380362
As usual the Eclipse community has been great in providing support and advice to workaround the issues.
Great Virgo features
- Very good diagnostic tools. Logs, dumps, detailed wiring information, all those features simplify problem determination of malfunctioning OSGi applications.
- User regions. You can deploy bundles in isolated user regions (exported packages and offered OSGi services will be visible and usable only by bundles in the same region). You can have the same bundles deployed more than once in different user regions, because virgo will qualify the bundle symbolic name with the region name.
- Deployment artifacts galore. You can deploy to Virgo Tomcat Server bundles, plain WAR files, Plans, PARs, Web Application Bundles (WAB) and all that flexibility allows you to deploy OSGi enterprise applications and plain old Web Applications within the same Virgo instance. Plain WARs can even load classes from the deployed OSGi bundles.
- Hot swapping. You can easily remove/add a deployment artefact (e.g. a bundle) from/to the server, without stopping the server and the application. Of course you need to make proper use of OSGi ServiceTrackers, the OSGi Extender pattern and write your application code to deal with such use cases.
- No more issues with 3rd party libraries When working with traditional J2EE application servers a frequent issue consists in classloading problems that may originate when your application and the app server use different versions of the same third party library. In such cases, depending on the app server of use, you have different ways of bypassing the problem, but none of them is really perfect, and in general, I wish I'd never have to deal with such issues. I am glad OSGi and Virgo free me from those problems.