geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Future directions towards better osgi integration
Date Thu, 08 Jul 2010 00:37:12 GMT

On Jul 6, 2010, at 4:13 PM, David Jencks wrote:

> What we have now in trunk more or less works OK but does not really take good advantage
of many osgi standard features, instead often duplicating some functionality with stuff ported
from earlier geronimo versions.  Here are a few ideas on how we might be more osgi friendly.
> 1. use osgi jndi to back up our java: jndi namespace.  Right now we're constructing our
own references that poke around in the geronimo kernel gbean registry to find the target.
 This is very similar to what the osgi: namespace does in the osgi service registry.  I think
we can bind jndi links to the osgi jndi name and get into the service registry that way. 
We're already binding connection factories in the service registry, we can do admin objects
and ejbs pretty easily too.  I'm experimenting with this in connector.
> 2. Use karaf features instead of our plugin dependency management.  Currently these are
very similar, our addition is to unpack stuff from bundles on installation if requested. 
We can do this independently of the features functionality, and we can talk to karaf about
whether this unpack idea would be good there.
> 3. Build ee artifacts into eba's.  Although it isn't really counter-spec to through everything
except app clients in an ear into one bundle/classloader, it doesn't seem ideal.  I think
one bundle per module (and possibly one additional bundle per @DataSource annotation) will
be more flexible.  BTW we have a problem currently in getting the app and global jndi contexts
onto the app client.  If we deploy each rar and datasource into a separate bundle we can just
start these on the app client too so the jndi stuff will be avaliable.
> 4. Replace gbeans with some combination of blueprint, blueprint namespace handlers, and
whatever else is needed.  The plugins that use plain gbeans can be converted to blueprint
pretty easily.  Our use of gbeans to wrap EE application components is less straightforward.
 We may be able to generate fairly simple blueprint plans in a special namespace that will
give access to the appropriate bundles containing the container classes.  This will take some
investigation.  I wonder if processing the xml into a neutral data tree like the openejb info
tree would be a useful approach.
> I've worried that (4) will take months and break everything from when it starts to when
it's complete.  However I am now starting to think that if we do 1-3 first there's a small
chance that (4) can be done plugin-by-plugin without completely breaking the server.
> 5. Figure out how to support jsr-77 (ee management) without gbeans.  One of the basic
functions of gbeans was to support jsr-77 directly.  Without them we'll have to figure out
what mbeans to register and how to do it.  Since the jsr-77 mbean structure is often totally
nuts, this will probably simplify the working code a bit, but will add another layer of goo.
 On the other hand we can presumably make it optional.

Another point..... currently we use our directed acyclic graph of plugins to determine which
gbeans are visible to references in a plugin.  This mechanism is just not going to be present
in the future.  We can think about trying to use subsystems or something else, but for now
we might be able to just make all the gbean refeences global, which will simplify stuff a
lot.  It may break systems that have multiple possible services satisfying a reference, but
we'll have to find a way to deal with that anyway.

david jencks

> thanks
> david jencks

View raw message