geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Fun with ears and osgi
Date Mon, 07 Dec 2009 19:37:16 GMT
David Jencks wrote:
> Working on the admin console I've run into the problem that ears most 
> naturally translate into more than one osgi bundle -- at least one 
> bundle for each web module, maybe one per module.
>
> Right now the deployment system is putting the wars inside the car 
> file, just like in 2.2, but as bundles.  It looks like we are 
> generating sort of reasonable metadata for the embedded bundles but 
> there is certainly no way to access them.
>
> I can think of several approaches here:
>
> 1. For now at least, just have one bundle per ear.  This is probably 
> just a couple lines to change and should work for all reasonable apps.
>
> 2. modify the pax mvn url handler so it can deal with bundles hidden 
> inside bundles.  This has the advantage that an ear is still a single 
> artifact but is otherwise slightly weird.
>
> 3. modify geronimo to package the wars as entirely separate bundles 
> from the main ear.  Maybe we can use the war module name as the 
> classifier.

I was giving some more thought to how to rework the RFC 66 
implementation to have external configuration information that we could 
then use the ConfigurationManager to start to deploy the WAB bundle to 
the web container.  This is very much the same problem as the EAR with 
embedded bundles.  However, in the RFC 66 situation, the WAB bundle must 
be external, since the starting of that bundle drives the creation of 
the configuration in the first place.  If an EAR was handled the same 
way (using separate bundles), this ends up being very similar processing.

Rick
>
> In the interests of getting something working quickly I will probably 
> try (1) first.  I'm intrigued by (2) but would certainly appreciate 
> some discussion before I spend much time on either (2) or (3)..... and 
> maybe someone has an even better idea.
>
> I assume there is a similar problem for app clients....
>
> thanks
> david jencks
>
>


Mime
View raw message