geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay McHugh <>
Subject Re: Fun with ears and osgi
Date Fri, 04 Dec 2009 17:41:55 GMT
Thanks Rick,

That is exactly what I have been hoping the direction was.

I think things will be getting very exciting once the OSGi enterprise
specs are finalized and implemented (in Aries and otherwise).


On Fri, Dec 4, 2009 at 10:57 AM, Rick McGuire <> wrote:
> Jay McHugh wrote:
>> Hello all,
>> This gets into a question that I have had about the OSGi-ification
>> goal of the server.
>> That is, how much are we trying to keep the internal architecture of
>> Geronimo hidden?  Are we looking to have a server that is able to
>> install any old Java EE apps and resources (that just happens to be
>> OSGi on the inside)?  Or, are we trying to build a server environment
>> where everyone 'knows' that it is OSGi and (if possible) builds their
>> applications taking that into account?
> It is a little of both, actually.  JEE applications will still be JEE
> applications and (generally) unaware of all of the OSGi stuff going on
> underneath.  The underlying classloading model will be the OSGi one, and the
> server when it builds the configuration for a deployed application ensures
> that all of the OSGi import/exports get created so that the configuration
> functions.  This is not entirely different than what is done in prior
> releases....the biggest difference is the underlying classloading model.
> At the same time, there's a desire to be able to host/deploy applications
> that actually are OSGi aware.  One of the end targets is to be able to host
> applications created for the Aries project runtime environment.  These
> applications will be using many of the same services used by JEE
> applications (JPA, JNDI, web containers, etc.) but accessing them in a
> loosely coupled, OSGi-centric manner.
> The work going on right now is first to get the underlying pieces of the
> server to be OSGi-based and using an OSGi classloading model.  David is
> currently looking at the second piece, which is how to take a legacy JEE
> application and create the plugin environment so that all of these
> applications will run unchanged in a JEE-certified environment.  The next
> step after this will be to create the Aries environment that will allow more
> OSGi-centric applications built using the Aries programming model to be
> deployed and managed.
> Rick
>> It seems like the direction we are going is the latter.
>> Am I seeing things correctly?
>> Jay
>> On Fri, Dec 4, 2009 at 9:25 AM, Lin Sun <> wrote:
>>> Hi,
>>> I wonder if ear should continue working as what what they were working
>>> before and would not be installed as bundles in OSGi framework.  And
>>> if users want to leverage OSGi functions in ear, they would have to
>>> migrate their ear file to an Aries Application
>>> (
>>> Lin
>>> On Thu, Dec 3, 2009 at 8:26 PM, 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.
>>>> 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

View raw message