On Nov 22, 2009, at 6:01 PM, Ivan wrote:
For a EJB/WAR, I could see what Bundle-ClassPath contains. But for an EAR package, what does it contain, all the jar files in the libraries, ejb jars and web related classes ? I am just thinking what the classloader structure of an EE application, especially for an EAR application. In the classic environment, for an EAR contains libraries and webapplications, we usually create a parent classloader for the EAR, and create a classloader for WAR package. Then, in the OSGI environment, how should it be ?
If only a bundle classloader is created and the bundle-classpath contains all the embedded jar files/classes, will it break the EE rules ? How about dividing the ear package into more than one bundle ?
There are two issues I know of:
1. osgi allows only one level of nesting of jars, whereas ee allows 2 (jars inside rars and wars). This isn't really a problem for us since we repackage the ear anyway so we can (continue to) unpack as many nesting levels as we want (as we do now).
2. Currently wars are set up as semi-independent configurations. I guess we will want to have them as additional bundles. I haven't figured out a good plan for this yet. We've thought about deploying ejb modules and rar modules as separate configurations also, perhaps this will turn out to be an easy thing to do.
Right now I'm concentrating on getting a single war or rar to deploy.... then we can think more about ears.
BTW at the moment I'm putting the osgi info into the Environment object and generating the manifest from that.
2009/11/21 David Jencks <firstname.lastname@example.org>
I've played with the welcome app servers a bit and found that the next significant problem is that we aren't setting the Bundle-ClassPath manifest header in our car bundles. This shouldn't be an obstacle for ejb jars, but is for anything else.
My plan is to solve this as part of GERONIMO-4911
by storing all the manifest info in the ConfigurationData. Perhaps this can replace some of the info in the environment field, although that is also used to figure out which plugins need to be started before the current one.