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/12/04 02:26:22 UTC
Fun with ears and osgi
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
Re: Fun with ears and osgi
Posted by Rick McGuire <ri...@gmail.com>.
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
>
>
Re: Fun with ears and osgi
Posted by Delos <da...@gmail.com>.
For method (1), how to wrap all the content from WARs and ejb JARs in a
single bundle. Do you mean just expand the WARs and JARs in the bundle?
2009/12/4 David Jencks <da...@yahoo.com>
> 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
>
>
--
Best Regards,
Delos
Re: Fun with ears and osgi
Posted by Jay McHugh <ja...@gmail.com>.
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).
Jay
On Fri, Dec 4, 2009 at 10:57 AM, Rick McGuire <ri...@gmail.com> 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 <li...@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 <da...@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
>>>>
>>>>
>>>>
>>
>>
>
>
Re: Fun with ears and osgi
Posted by Rick McGuire <ri...@gmail.com>.
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 <li...@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 <da...@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
>>>
>>>
>>>
>
>
Re: Fun with ears and osgi
Posted by Jay McHugh <ja...@gmail.com>.
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 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 <li...@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 <da...@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
>>
>>
>
Re: Fun with ears and osgi
Posted by Lin Sun <li...@gmail.com>.
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 <da...@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
>
>