geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chi runhua <>
Subject Re: What happened to Geronimo plugins in 3.0
Date Tue, 17 Aug 2010 16:03:27 GMT
David, really appreciate your detailed comments.  I might need a little bit
more time to fully digest those information.

Will ping this thread if I have any other questions.


On Thu, Aug 12, 2010 at 3:41 AM, David Jencks <>wrote:

> Hi Jeff,
> Thanks for nudging me to try to answer some of these questions.  I've been
> meaning to for a long time.
> First of all, in my mind, most of the basic infrastructure in geronimo
> trunk is in a temporary state of transition.  My eventual goals include
> - using osgi services for all inter-component wiring
> - eliminating gbeans and the geronimo kernel
> - wiring objects together in what is now a plugin using either blueprint or
> custom code adapted to Declarative Services
> - use of config admin instead of artifact_aliases.propertes and
> and config.xml
> - using karaf features to install dependencies
> - using OBR much more extensively
> - consider relying on the bundles installed into the framework instead of
> the "source" bundles in our repository directory
> At a slightly higher level I think that most of our ee support would
> benefit from using a strategy like openejb with basically a single component
> per module that includes an info tree that describes all the stuff for that
> module.  For example, openejb could have one component (currently a gbean)
> that contains the info tree for all the ejbs in the module.  Web apps could
> be converted to one component (again currently a gbean) that has an info
> tree for the entire web app.
> However, we aren't there yet and I think we want to get pretty complete ee
> support in place before changing the fundamental architecture yet again.
> On Aug 11, 2010, at 2:36 AM, chi runhua wrote:
> > Hi devs,
> >
> > I'm trying to sort out how the geronimo plugin works in 3.0 and what the
> differences are comparing to the ones in the previous version. After reading
> some code and JIRAs, I'm quite confused...., such as
> >     *  is a geronimo-plugin.xml file required any longer?
> yes. It has two essential purposes at the moment:
> - act like a karaf features descriptor and tell what other dependencies
> need to be installed for this plugin
> - act like a config admin descriptor and install stuff into config.xml,
> and
> >     *  what's relationship between a geronimo plugin and an OSGi bundle?
>  A plugin is a bundle actually now?
> All plugins are bundles.  I think there's still some xml in a plan that has
> no effect that describes our previous classloading strategy (hidden-classes,
> non-overridable-classes, etc).  However you can specify explicit
> import-package and export-package (to extend what we generate automatically)
> The plugins that we build to construct the server out of only have
> configuration in them, no classes.  This seems to be an unusual strategy for
> osgi, where people usually seem to have blueprint bundles with both classes
> and configuration.  I'm not sure what I think about trying to combine
> classes and configuration.  It seems to me that it makes use of the classes
> much more restricted, although it does allow much more encapsulation.
> >     *  How to expose services from a geronimo plugin?
> You can get any gbean into the osgi service registry with a little bit of
> configuration:
> - use the org.apache.geronimo.gbean.annotation.OsgiService annotation on
> the gbean class. If desired you can specify the exposed service interfaces
> in this annotation.
> - if desired have the gbean implement org.osgi.framework.ServiceFactory
> - you can add service interfaces and service properties to the GBeanData.
> At the moment you can only do this in code in a builder but if there's a
> reason we could add xml for this.
> >     *  What purpose does a repository.xml in a geronimo-plugin package
> serve?
> Geronimo has an OBR instance that is mostly used for aries EBA deployment
> right now.  Currently it is set up from scanning the repository directory in
> the server.  I'm not sure this reliance on the actual repository directory
> is a good idea.  My idea is that each plugin (or karaf feature) should have
> a repository.xml for its dependencies and that all of these should get
> merged together in the geronimo OBR.  The repository.xml is a first step
> towards trying this out to see if it is workable.
> >     *  How to manage the Lifecyle of a geronimo plugin?
> One of the bad fits between geronimo and osgi is that our plugins have an
> additional lifecycle state beyond the bundle being started, namely having
> the gbeans started.  Theoretically we can eliminate this problem by using
> lazy service activation for osgi services.  One difference is that starting
> gbeans in a plugin is done through and explicit command and lazy service
> activation occurs whenever something requests the service.  We may have to
> be careful to be sure that deployment work doesn't start runtime services,
> e.g. processing a web app to fill out its deployment info doesn't start a
> web connector.
> So, right now you have to use the geronimo ConfigurationManager to manage
> the state of a plugin.
> Hopefully this will help :-)
> thanks
> david jencks
> >      ........
> >
> > Could anyone shed some light on me?
> >
> > Thanks a lot.
> >
> > Jeff

View raw message