geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <>
Subject Re: Whence the geronimo kernel?
Date Thu, 05 Mar 2009 15:18:08 GMT
Hi David, I think this is a good move and worthy investigation!  I
have some comments below.

On Wed, Mar 4, 2009 at 7:56 PM, David Jencks <> wrote:
> Geronimo has been around for a while and despite the many good features
> gbeans and the geronimo kernel are not catching on big time.  I think we
> want to consider taking action now to avoid ending up being dragged down by
> supporting a dead container.  Here are a few thoughts.
> Actual problems with geronimo:
> - gbeans are too restrictive.  It's too hard to instantiate other peoples
> components as gbeans.  GBeans don't support common patterns like factory
> methods, factory beans, etc etc, and require the component to be
> instantiated directly by the gbean framework.
> - it's too hard to get the classloaders to work.  The most common problem is
> a class cast exception due to loading the same jar in two plugins.
>  NoClassDefFound errors from an optional jar in a child classloader are also
> really annoying.
> Really good things about geronimo I haven't seen elsewhere (at least in one
> place):
> - gbean dependencies work across plugins.  Dependencies are a unified
> system, not per-plugin.
> - gbean dependencies are resolved in the ancestors of a plugin, not server
> wide.  This means that you can't make a partially specified dependency
> ambiguous by deploying additional plugins.  I consider this an extremely
> important feature for predictability.
> - plugin dependencies allow assembly of a server from the explicit
> dependencies which are normally the same as the maven dependencies.
> Other projects and specs that have stuff we should look into:
> maven.  Maven has a lot better infrastructure for dealing with dependency
> resolution from partial transitive dependency specification than we do.  We
> should look into using more of their infrastructure.
> osgi. osgi has a lot of similarities to geronimo. The osgi classloading
> model is getting a lot of people excited.  The import-bundle idea is pretty
> much the same as our classloader model where every jar is a plugin.  I don't
> know if people are really using the allegedly recommended method of
> specifying imports and exports and letting the osgi runtime figure out where
> they come from; this seems worth investigating to me. Also, we get periodic
> inquiries about when we are going to support osgi and the was ce folks get
> even more.

I have used the Import-Package function.   The bundle I was trying to
build  can get javax.transaction pacakge from the J2SE or the
geronimo's jta spec jar, so I had to specify the exact version of the
javax.transaction package in the Import-Package attribute and let the
bnd tool figure out the rest.  This works well for me.   The bnd tool
cannot auto-discover this so this have to be done manually AFAIK.

> osgi blueprint service (rfc 124) This appears to be a simple wiring
> framework for a single plugin.  IIUC it uses the osgi service registry for
> component dependencies between bundles.
> xbean-spring.  I'd be reluctant to try to implement a blueprint service that
> didn't provide the xbean-spring capabilities really well
> ee6 dependency injection.  EE6 is going to have a pretty sophisticated
> dependency injection service which we'll need to support anyway.  We should
> try to figure out how much of the core we can assemble using it.
> Other great stuff we have:
> xbean-reflect, xbean-finder, xbean-spring
> These ideas have been floating around in my head for a long time and I've
> chatted with various people about them occasionally.   While more discussion
> is certainly needed on everything here I need to do some implementation to
> understand much more.  So, what I'm planning to do:
> Dave's crazy work plan...
> - Try to use the osgi classloader.  I think this involves putting the
> classloader creation in Configuration into a service.  Configurations will
> turn into osgi bundles.  I'll put the Kernel in the osgi ServiceRegistry so
> the Configuration bundle activator should be able to use it to resolve
> cross-plugin dependencies.
> - try to figure out how maven dependency resolution fits into osgi.
> - see if eclipse p2 is relevant for provisioning geronimo repositories

Osgi is building a bundle repository RFC (think it is rfc 112).  I
haven't looked into detail so not sure if it is related to maven at
all, but you may want to check it out.

> at this point I think geronimo would be running on osgi, still using gbeans.

Are you envisioning all the geronimo plugins converted to OSGi bundles
to run in the OSGi based kernel?

> - look into relaxing the gbean framework so it is more plugin-at-a-time
> rather than gbean-at-a-time
> - see how that differs from the blueprint service, ee DI, and xbean-spring.
>  Try to support all of these at once.
> Thoughts? Counter proposals?  Anyone interested?
> many thanks
> david jencks

View raw message