My two cents: Seems EAR is a complicated case.I think "Fragment Bundle" in OSGI may help. A fragment don't have its own classloader except that of host bundle.If so, EAR may be a host bundle, while ejb jars and WARs are all fragments.
Thanks! 2009/11/23 David Jencks <[email protected]> > > 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 ? > Thanks ! > > > > 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. > > thanks > david jencks > > > > 2009/11/21 David Jencks <[email protected]> > >> 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<https://issues.apache.org/jira/browse/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. >> >> comments welcome... >> >> thanks >> david jencks >> >> > > > -- > Ivan > > > -- Best Regards, Delos
