I've made some progress on this - here is what I'm trying to do:
- Put all Glassfish bundles into the Target Platform of my Eclipse workspace.
- Develop a hybrid OSGi/Java EE application as a set of plugin projects, using nothing but Eclipse PDE (no WTP, no Glassfish plugin)
- Use an OSGi Framework launcher to run and debug my application in Eclipse.
I'm using Glassfish 3.1-b24, Eclipse 3.6.1 and the sample code from
http://blog.arungupta.me/wp-content/uploads/2010/10/javaone2010-s313522.zip
So far, this approach works more or less smoothly for WABs and library bundles, but currently not for EJB bundles.
All in all, both Glassfish and Eclipse make some implicit assumptions that work fine in isolation but are incompatible in combination. It would be great if both communities would sort out these issues, which would give an enormous productivity boost for hybrid OSGi/Java EE development.
A summary of the main issues I've encountered:
1) Glassfish should let the user do their own provisioning. Glassfish should not launch an OSGi framework and install its own bundles. The user should be able to take a set of Glassfish bundles, install them in any OSGi framework running any number of third-party bundles, and then start one of the installed Glassfish bundles to launch a Java EE 6 container.
Currently, the autoprovisioning done by bundle org.glassfish.core.glassfish conflicts with the target platform/OSGi launcher provisioning and validation in Eclipse. If you launch your application with all bundles from the Glassfish target platform, there will be lots of warnings for duplicate bundles, because org.glassfish.core.glassfish tries to reinstall all bundles. On the other hand, if you only launch your application and org.glassfish.core.glassfish, "Validate Bundles" in the launcher fails because all the dependencies are missing. Besides, some configuration information provided by the bootstrap mechanism is missing.
2) I had to delete the Felix Gogo bundles from the Glassfish installation. Somehow they don't play well along Equinox, and after all, Equinox has its own shell.
3) I had to set a couple of system properties:
com.sun.aas.installRoot
com.sun.aas.instanceRoot
java.ext.dirs
java.endorsed.dirs
4) After that, some bundles still have unsatisfied dependencies, but so far this seems to have no negative effect at runtime.
5) The Glassfish modules folder contains some non-bundles, e.g. concurrent.jar and jtype.jar. I don't know what Felix does with them, but Equinox ignores them, complying to the OSGi spec.
6) For a Web bundle, you have to tweak the PDE build.properties so that the class files land in WEB-INF/classes. This is doable, but currently causes warnings in Eclipse. PDE should allow more flexibility.
7) EJB bundles fail to deploy, and this is a blocker. The root cause is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=160133: For a bundle launched directly from the workspace in exploded form, Bundle.getEntryPaths() does not return the expected results, classes are in /bin/com/acme/Foo.class and not in /com/acme/Foo.class.
This breaks the OSGi EJB deployment where Glassfish tries to use Bundle.getEntryPaths() to explode bundles with an Export-EJB header to a temporary storage.
While this is definitely a bug in Equinox (reported in 2006!), I still wonder why Glassfish needs to copy the bundle resouces or to scan them with Bundle.getEntryPaths(). Could this be avoided by setting Export-EJB to an explicit class list instead of using ALL?
Best regards,
Harald
[Message sent by forum member 'hwellmann']
http://forums.java.net/jive/thread.jspa?messageID=485700