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:46:46 GMT
Guillaume Nodet wrote:
> On Wed, Mar 11, 2009 at 08:57, Gianny Damour 
> < <>> 
> 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).
I have to agree with Guillaume on this.  A lot of the difficulties that 
people run into with trying to configure the classloading options on 
Geronimo can become non-issues under the OSGi model.  Those sorts of 
problems are handled automatically by the OSGi framework.  On the 
downside, a lot more work needs to go into specifying the package 
dependencies.  This can make "bundlizing" a jar an interesting exercise 
the first time.

> 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 ...
OSGi is definitely moving in that direction.  There are a number of RFCs 
in the works for how that sort of autodiscovery should behave running on 
an OSGi framework.  The new blueprint service will provide a native 
application assembly model, and other RFCs cover discovering/running 
different types of JEE application types.

> 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
>     (
>     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:
> ------------------------
> Open Source SOA

View raw message