[Updated version of a post originally shared on G+ on the 22nd of June 2012]
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.
There are a number of other smaller
issues but the above are the most annoying.
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.
Conclusion
All
in all Eclipse Virgo is an exciting piece of technology. It's a full
featured OSGi and Web container packaged with lots of useful diagnostic
features that enables blending traditional Web Applications with OSGi
(enterprise) applications. True modularity is visible in Virgo itself,
which comes in 3 different flavors (Nano, Kernel, Tomcat Server). I
believe it's a solid product and probably the best option for OSGi
enterprise applications.