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 Fri, 04 Dec 2009 16:57:05 GMT
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 <linsun.unc@gmail.com> 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
>> (http://incubator.apache.org/aries/applications.html).
>>
>> Lin
>>
>> On Thu, Dec 3, 2009 at 8:26 PM, David Jencks <david_jencks@yahoo.com> 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
>>>
>>>
>>>       
>
>   


Mime
View raw message