geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Re: Some thoughts about enabling for OSGi
Date Wed, 26 Aug 2009 05:19:43 GMT
2009/8/26 Guillaume Nodet <>

> On Tue, Aug 25, 2009 at 17:43, Rick McGuire <> wrote:
>> I've been trying to pull together some thoughts about what it might mean
>> for Geronimo to enable itself for OSGi applications and what needs to be
>> added to the server beyond just adopting an OSGi classloading model.  That
>> sort of change would be primarily transparent for most existing
>> applications, but to make the change worthwhile, we'd also want to make
>> Geronimo into a real OSGi application platform.
>> So, beyond just having the framework environment, what would be the
>> require elements?  Ok, to start with, most (all?) real OSGi platforms have
>> some concept of a bundle repository.  The bundle repository is where
>> installed bundles are stored and there is generally some sort of
>> loading/provisioning strategy associated with the repository that eliminates
>> the need for an application to manually install and start each of its
>> dependent bundles.  I think the characteristics of how the Geronimo bundle
>> repository is a discussion topic all of its own, so for now, I'll just
>> assume this piece is there.  As part of server bootstrap, there will be a
>> configured startup of bundles from the repository that are necessary to
>> bring up the server.  This will be similar to the module bootstrapping the
>> server already goes through.  There will also need to be a mechanism for
>> adding bundles to the repository, probably both as a command line tool and
>> via the console.
>> The Geronimo server will need to provision the framework with an initial
>> set of services that will be available for installed bundles to use.  Some
>> of these services will interact with other portions of the Geronimo server,
>> while others are platform-agnostic, but provide important bundle-management
>> services.  Looking through the OSGi compendium specifications, the following
>> look like a good recommended set:
>>   * EventAdmin service (generalized Event broadcast service).  This is
>>     fairly self contained, and we can probably just use the Felix
>>     reference implementation.
>>   * Logging service.  This is a standardized OSGi logging API.  The
>>     reference implementation is just a circular queue and does not
>>     actually log entries to any persistent storage.  The Geronimo OSGi
>>     logging service should be integrated with the general logging
>>     support.  The PAX logging service looks like a good starting point
>>     for this.  I understand that the Geronimo Blueprint service
>>     implementation is already using this version.
>>   * Config Admin.  This is a persistent store for configuration data.
>> I think this one will be an general expectation for many bundles
>>     that are installed on Geronimo, so we'd need to provide an
>>     instance of this.
> In addition, and related to Config Admin, support for meta type information
> could be useful.  This allows describing what the configuration should look
> like, and this allows automatic generation of UI for configuration for
> example.  This is what the Felix web console does.
>>   * UserAdmin service.  This is an interface to an authentication
>>     system associated with a platform.  I believe this would be fairly
>>     simple to map to the Geronimo authentication services.
> I think there is a need for integrating the UserAdmin with JAAS at some
> point.  I'm not aware of such a thing yet, but that's something I had in
> mind.
>>   * Declarative services.  The ability for bundles to declaratively
>>     publish services to the services registry.  We'd need to support
>>     this to allow bundles to be used portably across framework host
>>     environments.  This should not require any special integration
>>     with the rest of Geronimo.
> Not sure if there is a need to support both by defaults.  If we rely on
> Blueprint for example, DS could only be installed if users need that, as an
> optional add-on maybe.
Agree, I guess there won't be so much app based on it after blueprint
shipped. If we use blueprint, the 3-party plugin developer should also rely
on it. Otherwise, he need install the DS add-on.

>>   * Blueprint services.  A more sophisticated component assembly
>>     model.  This also should not require any special Geronimo
>>     integration.
> * Preferences Service.  Allows bundles to persistently store
>>     preference information.  This is a bundle-driven capability, which
>>     is a bit different than the config admin service.  I'm not sure
>>     how prevalently this is used, so this one might not be a requirement.
>> Interestingly, this diagram of Karaf architecture has quite a bit in
>> common with what I've just described once you replace "Spring DM" with
>> "Blueprint Service".  There could be an advantage to leverage prior
>> experience with this environment here.
>> One key aspect to all of this is deployment and administration.  The
>> Geronimo server will need to provide the conduit for deploying new bundles
>> to this environment, as well as administrative function.  The OSGi
>> Enterprise Expert Group (EEG) is working on a specification for using JMX
>> for managing OSGi environments.  The reference implementation for this
>> specification includes a framework neutral set of MBeans for tracking
>> installed bundles, registered services, config admin, etc.  These look like
>> a good model to follow and can be the basis for providing console-like
>> administration capabilities.  There may be additional MBeans we'd like to
>> provide for other services, such as the Blueprint service.
>> This is probably a good staring point for the discussions.  There are
>> likely other facilities we'll need to add here, but I think this is probably
>> a good starting point for the discussions.
>> Rick
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

View raw message