geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Delos <>
Subject Re: ee apps in trunk
Date Mon, 23 Nov 2009 08:12:32 GMT
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.


2009/11/23 David Jencks <>

> 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 <>
>> 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.
>> comments welcome...
>> thanks
>> david jencks
> --
> Ivan

Best Regards,


View raw message