Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4A9C1880.50905@apache.org>
Date: Mon, 31 Aug 2009 14:37:52 -0400
From: Donald Woods <dwoods@apache.org>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Some thoughts about enabling for OSGi
References: <4A940695.8000204@gmail.com>
 <b23ecedc0908250851v1d810b0m5f69f9e3ff3a754@mail.gmail.com>
In-Reply-To: <b23ecedc0908250851v1d810b0m5f69f9e3ff3a754@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Guillaume Nodet wrote:
> On Tue, Aug 25, 2009 at 17:43, Rick McGuire <rickmcg@gmail.com 
> <mailto:rickmcg@gmail.com>> 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.

How about just extending the existing Admin Console support in Felix?
We'll still need a web ui, but it should always be optional, like it is 
in Felix and Karaf today.

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

Are there are maven plugins for using Karaf in a junit environment or to 
help build custom Karaf assemblies?


> 
> 
> 
>     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
> 
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
> 
>