You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2009/11/21 09:50:59 UTC

ee apps in trunk

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

Re: ee apps in trunk

Posted by David Jencks <da...@yahoo.com>.

On Nov 23, 2009, at 12:12 AM, Delos wrote:

> 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.

I'm not sure how that would help.  We have no problem constructing a  
single bundle with everything from the ear inside it  -- we already  
unpack ears to this format, we'd just need to add more entries to the  
bundle classpath for the wars.  The problem is how to have several  
bundles each with its own classloader for the individual wars.  I  
suspect we'll have to just set up more than one bundle from such an ear.

thanks
david jencks

>
> Thanks!
>
> 2009/11/23 David Jencks <da...@yahoo.com>
>
> 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 <da...@yahoo.com>
>> 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,
>
> Delos