geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Whence the geronimo kernel?
Date Thu, 05 Mar 2009 14:46:26 GMT
Agree that it is time to start looking at OSGi and thanks for kicking 
this off!


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.
> 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
> at this point I think geronimo would be running on osgi, still using 
> gbeans.
> - 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