geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: ee apps in trunk
Date Mon, 23 Nov 2009 08:03:42 GMT

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.

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

View raw message