geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: Whence the geronimo kernel?
Date Wed, 11 Mar 2009 07:57:37 GMT

FWIW, I believe that improving the configuration style to simplify  
the means of creating a bunch of objects in the kernel has more  
benefits than swapping the classloading infra. On paper OSGi may  
appear as superior from a classloading isolation perspective;  
however, I believe the current CLing design is nearly up to par with  
the OSGi one and that the main challenge is to properly tune export/ 
import dependency declarations.

The JAXB approach to turn xml plans to a bunch of objects is  
certainly interesting. I believe it is still a technology limiting  
decision whereby a lot of custom code will have to be implemented to  
support various style (factory methods or beans et cetera) of  
configurations. I have been bouncing around this idea a while back  
and here it is again. Why do we want to define a XML language to  
create a bunch of objects when scripting can do that for us?

I believe that xbean-spring is still unnecessary noisy when compared  
to something like the Spring Bean Builder ( 

If there is an interest in a scripting approach, then I can  
investigate further.



On 11/03/2009, at 6:54 AM, 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.
> So far this is more or less wild speculation in my head...  but I  
> think it would be a lot of fun to investigate.
> 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