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 <[email protected]> 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 <[email protected]> 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
