geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [OSGi] Support for RFC 124?
Date Wed, 08 Apr 2009 19:24:46 GMT
I have started some stuff related to that too.  The plan was to see if
it's possible to implement RFC 124 on top of Felix iPojo.
I have the apis, schemas and some of the parsing working ...
If anyone is interested, we could maybe set up a lab for that.

On Wed, Apr 8, 2009 at 19:23, Jarek Gawor <> wrote:
> Btw, I checked in under
> a tiny
> bit of code that I was playing around with to better understand RFC
> 124. I'll keep on working and experimenting with it but anyone is
> welcome to join. I'm planning to add some of the RFC 124 API
> definitions next in order see what it would take to implement these
> API.
> Jarek
> On Wed, Apr 1, 2009 at 6:47 AM, Rick McGuire <> wrote:
>> Davanum Srinivas wrote:
>>> Folks,
>>> Any interest in support for RFC 124, "A Component Model for OSGi"?
>>> This is in addition to typical J2EE artifacts that we already support.
>>> thanks,
>>> dims
>> Time, I think, to give this thread a kick.
>> There are lots of different aspects to this, so I think we should first make
>> an attempt at deciding what the target goal is here.  RFC 124 (aka, the
>> "blueprint service") is inherently an OSGi thing, so first we need to
>> address what it means to add OSGi to Geronimo.  And, I think, in general,
>> this really means "OSGi as a Geronimo application programming model".
>> This can have multiple meanings.  One approach, already under discussion in
>> the "Whence Geronimo kernel?" thread would be rearchitect the Geronimo
>> kernel around OSGi bundles and the OSGi classloading model.  In this mode,
>> an application model should be fairly simple to add, though there may be
>> some issues of bridging between the OSGi "bundle world" and the JEE
>> programming model.  Additions like the blueprint service might be directly
>> usable within the Geronimo kernel for assembly and injection.
>> Another approach would be to add an OSGi application container to Geronimo.
>>  This would allow OSGi/blueprint-based applications to be hosted on
>> Geronimo, and there may be some Geronimo services that get exposed to the
>> apps, but the apps run in their own separate environment.
>> The container approach is, I believe, probably the easier path, but we I
>> think we lose a lot of the advantages of the OSGi model in other places.
>>  Also, OSGi is working on a number of additional RFCs that will add
>> different JEE concepts to the platform.  I'd hate to think that Geronimo
>> might need to maintain two versions of each of these pieces, one for the
>> OSGi container and one for the non-OSGi world.
>> Anyway, I think regardless of the implementation approach, we need to start
>> discussing this in terms of "what does it mean to host an OSGi application
>> on Geronimo?".  Here are a few questions that immediately come to mind:
>> 1.  How are applications deployed?  Is there some higher-level deployment
>> model than the bundle level?
>> 2.  What services are available Geronimo application environment?  Blueprint
>> is certainly one service, what others do we need?
>> 3.  How is the config-admin service managed?  Do we need Geronimo console
>> access and editting of config admin properties?
>> 4.  Are there any bridges from the OSGi world to the JEE world?  For
>> example, is is possible to export service registry instances to JNDI?
>> I think this is a good starting point for discussing ideas....I'm sure there
>> are additional questions that will come up in the discussions.
>> Rick

Guillaume Nodet
Open Source SOA

View raw message