geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: What happened to Geronimo plugins in 3.0
Date Wed, 11 Aug 2010 19:41:38 GMT
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 config-substitutions.properties
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, config-substitutions.properties
and artifact_aliases.properties

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


Mime
View raw message