geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <jga...@gmail.com>
Subject Re: ee apps in trunk
Date Mon, 23 Nov 2009 19:28:01 GMT
David,

I just ran into this problem with system-database plugin and a rar
module. During deployment a right Bundle-Classpath entry was added for
the rar module to the car manifest entry. However, after deployment,
car-maven-plugin in archive-car goal overwrote the manifest entry with
its own data which did not include the Bundle-Classpath entry. I
committed a tiny fix for this problem but obviously we need to improve
how the car deployment is done or update the car-maven-plugin.

The good news is that with that tiny fix I was able to deploy the
system-database plugin and see that the derby database was created ok.
However, I'm not sure what happens if some other module tries to use
the system-database plugin.

Jarek

On Mon, Nov 23, 2009 at 3:03 AM, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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 <david_jencks@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
>
>

Mime
View raw message