geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gurkan Erdogdu <>
Subject Re: Whence the geronimo kernel?
Date Thu, 12 Mar 2009 11:38:17 GMT
Hi Gianny,

As a keen observer of the Geronimo dev List , I would like to ask question on this subject.

Gianny, do you want to say that there is an UniversalClassLoader for all the server instance
that contains the other class loaders. IOW, try to change hierarchical class loaders with
the flat class loader repository?

Do you mean that if  jar is already loaded by the any class loader that is registered in the
UniversalClassLoader, it will always load the same jar?



From: Gianny Damour <>
Sent: Thursday, March 12, 2009 12:25:34 PM
Subject: Re: Whence the geronimo kernel?

On 12/03/2009, at 4:29 AM, David Jencks wrote:

> On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
>> 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.
> I agree.  I doubt Guillaume has seen your additions to classloading in trunk which allow
you to not export packages from a classloader.  I haven't tried to prove it mathematically
but I think that with this feature the classloading models for geronimo and osgi are equivalent
in that you can express the same ability to access classes with either of them.  Of course,
the notation you use to express this and the specific information included in the configuration
is different.
> I think I probably have the most experience with classloading problems in geronimo and
the only real problem that arises is loading a jar in two different classloaders.   This can
be solved by a classloader-per-jar model which offers no theoretical problems to set up in
geronimo but practically would take a lot of work (and maven projects to build a plugin per
jar).  So I think we'll have to see what kind of problems we get with trying to actually use


Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar
model. Under the hood of a MultiParentClassLoader we can replace the current implementation
of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders
(one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across
all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy
respecting the maven dependency declarations. So, we could install the pom of the dependencies
in the repo and lazily parse them when MultiParentClassLoader are created to build this global
and share tree of URLClassLoaders.

I just started to work on it and I will post back my findings (i should be able to complete
this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully
still be useful.


> One thing I'd really like actual user data on is how people actually specify osgi classloading
info in real life.  I'm very aware that in theory you are supposed to specify the package
imports and exports for your bundle but I've been told that in real life everyone with a serious
osgi project actually specifies the jar dependencies they want using require-bundle.
> thanks
> david jencks
>> Thanks,
>> Gianny
>> On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote:
>>> 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
>>> 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 (
>>> 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
>>> 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