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 <rick...@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 <linsun....@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_jen...@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 >>>> >>>> >>>> >> >> > >
