geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Whence the geronimo kernel?
Date Wed, 11 Mar 2009 08:46:46 GMT
Hi,

So let's agree to disagree for now. This may be related to my  
personal way of comparing stuff which is pretty much limited to:
1. understand what the requirements are.
2. understand how the technologies support these requirements. I do  
not need all the bells and whistles that a technology offers to  
fulfill the requirements. Moreover comparing stuff based on  
technology differentiators not clearly linked to the requirements is  
pointless.
3. assess best way forward based on above scoring.

Key steps are 1 and 2 where stuff offering all the bells and whistles  
may well be scored as good as other stuff (I clearly do not support  
over-bloated stuff...).

Obviously, I am keen to be proven wrong and adjust accordingly. So  
far, I am still saying that the main challenge is to properly tune  
export/import of dependency declarations. For me, the technology is  
not the core issue and switching is not going to resolve problems.

Thanks,
Gianny

On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote:

>
>
> On Wed, Mar 11, 2009 at 08:57, Gianny Damour  
> <gianny.damour@optusnet.com.au> wrote:
> Hi,
>
> 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.
>
> I have to disagree with that.  The CLing mechanism is very  
> different in Geronimo (from what I recall) and OSGi.  Geronimo uses  
> a multi-parent classloader style with some nice features to be able  
> to hide / never override + parent or self-first delegation.
> OSGi CLind is very different: the first one is that you don't  
> really have parent classloaders: the classloader for a given OSGi  
> bundle is calculated wrt to the constraints expressed in the OSGi  
> manifest using imported packages or required bundles.
> Let's take an example:
>    bundle A needs api packages from bundles B and C
>    implementation classes from bundle B and C needs something from  
> bundle D but with different versions
> OSGi will be able to handle that because of non tree-like CLind  
> mechanism: if bundle A is wired to bundle B, it does not have to  
> see all the requirements from bundle B, and same for C.  Therefore,  
> bundle A can be wired to both B and C without problems because it  
> will not see bundle D at all (so there's no conflicts between the  
> two versions of bundle D).
>
> OSGi has a much more powerful CLing mechanism where you can express  
> lots of different constraints.  The drawback is that establishing  
> the classloader can take a bit of time, so going to OSGi most  
> certainly leads to a big slowdown at startup while creating the  
> classloaders.
>
> Also, OSGi does not really play nicely with the usual JEE way to  
> discover implementations through the MANIFEST/services entries.   
> That's kinda what we've tried to solve in servicemix specs, though  
> I'm not sure if that really applies everywhere because I would  
> imagine the classloaders for EARs are not really OSGi classloaders ...
>
> I certainly don't want to say OSGi is not the way to go, just want  
> to make the point that there are benefits but also drawbacks.
>
>
>
> 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 (http:// 
> www.grails.org/Spring+Bean+Builder).
>
> If there is an interest in a scripting approach, then I can  
> investigate further.
>
> Thoughts?
>
> Thanks,
> Gianny
>
>
> 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
>
>
>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>


Mime
View raw message