geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Cai <>
Subject Re: Whence the geronimo kernel?
Date Thu, 05 Mar 2009 07:56:57 GMT
This is defintely a good move! How will that affect the programming model
around Geronimo? Obviously some users are not happy with the complexity of
the deployment plan [1].



2009/3/5 Ivan <>

> It is a good idea.
> I encounter some similar issues about the multiparent classloader. From the
> pom.xml, currently, it is hard to know which jar is in the classpath. The
> dependies between the configurations are also too complex, I notice that the
> restart/reload codes in the configurationManager is very very ...
> Maybe we could replace all the codes in the configurationManager, and just
> delegate it to the OSGI module/lifecycle layer.
> Thanks !
> 2009/3/5 David Jencks <>
> 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
> --
> Ivan

View raw message