geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Future directions towards better osgi integration
Date Tue, 06 Jul 2010 23:13:55 GMT
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.

david jencks

View raw message