geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Whence the geronimo kernel?
Date Wed, 11 Mar 2009 10:53:53 GMT
David Jencks wrote:
> So as mentioned below I'm starting to look into the osgi classloading 
> bit, sort of "from the bottom".
> Another approach to many of these issues is perhaps "from the top", 
> from the point of view of going from a presumably xml plan to a bunch 
> of objects.
> I've long thought that it must be possible to leverage jaxb to do most 
> of the heavy lifting here.  In particular sxc is some code we can 
> presumably actually extend to do stuff like constructor dependency 
> injection.  So another avenue that could perhaps be approached in 
> parallel would be to investigate sxc, jaxb, xbean-spring, 
> xbean-reflect, the blueprint service schema, and jsr299 requirements 
> and see what we can come up with.
> For instance, it might be possible to have a large part of the 
> blueprint service functionality in jaxb-enabled objects that jaxb 
> instantiates from the xml.  The "init" method could deal with feeding 
> the metadata into the blueprint service core.  Maybe we can get sxc to 
> use xbean-reflect to create the objects.
Don't fall into the trap of thinking of the blueprint service as just a 
"bean assembler".  There's a lot more going on in the runtime beyond 
just creating class instances and injecting dependencies.  There are 
different sorts of lifecyle considerations (lazy-init, prototype scope), 
as well as all of the work that goes into supporting the dynamics of the 
OSGi service registry.  

> So far this is more or less wild speculation in my head...  but I 
> think it would be a lot of fun to investigate.

I thnk it will be too!
> thanks
> david jencks
> On Mar 4, 2009, at 4: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.
>> 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