geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Whence the geronimo kernel?
Date Wed, 11 Mar 2009 08:11:00 GMT
On Wed, Mar 11, 2009 at 08:57, Gianny Damour

> 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 (
> 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

Guillaume Nodet
Open Source SOA

View raw message