geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Some thoughts about enabling for OSGi
Date Tue, 25 Aug 2009 15:51:50 GMT
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.

The Blueprint impl uses an OSGi logging service if available but has not
dependency on the implementation.

>   * 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.
>   * 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.
>   * 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.
>   * 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.

Karaf has switched to Blueprint services some time ago (I guess I need to
update the web site I suppose).  So there's no Spring-DM dependency anymore,
though it can be easily deployed using "karaf features".

> 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.

Karaf embeds the RI for JMX management of OSGi.

I really think it would make sense to see if we can Karaf and Geronimo can
collaborate together.  I always have in mind Karaf becoming a TLP at some
point.   Improvements to Karaf would be very welcomed, I'm sure.

Karaf goal was really to be a minimal, but yet usable, OSGi runtime for
server side applications, such as ServiceMix, ActiveMQ.  So I don't really
see why it would not be a good fit for Geronimo.  And if it isn't yet, it
might make sense to see how it can become so ...

> 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

Guillaume Nodet
Open Source SOA

View raw message