geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <>
Subject Re: Whence the geronimo kernel?
Date Thu, 12 Mar 2009 05:51:01 GMT
On Wed, Mar 11, 2009 at 3:30 PM, David Jencks <> wrote:
>> Right but that's an important problem which we run into all the time
>> in Geronimo (same jar loaded by two different classloaders). And the
>> solution to this problem is to create another
>> configuration/classloader and make that the parent of the two. This is
>> a pretty 'static' solution while osgi offers 'dynamic' solution where
>> it figures out at runtime which packages to wire together. So
>> Geronimo's and osgi's classloading models might be equivalent ONLY IF
>> we support classloader-per-jar model. Hiding classes/packages in a
>> classloader is not enough.
> Our classloading system does support classloader-per-jar right now, but we
> haven't set up enough classloaders to act that way, and I'm hoping that osgi
> will provide the same features with less work.

Right, no argument there.

>  From a conceptual point of
> view I don't see why osgi would be any more or less dynamic than geronimo.
>  The classes are coming out of some versioned jar and IMNSHO you are
> unlikely to want to allow the resolution method to pick anything other than
> the version of the jar for you.  If you leave out the version in the
> dependency geronimo will pick one for you... I'm not sure what the
> equivalent osgi configuration would be.

The point I was trying to make is that with Geronimo the classloader
hierarchy is pretty much created/setup at build time while in osgi if
you are using Import-Package is at runtime. Here's an example. Say, we
have configuration A that has dependency on configuration B and C.
Both B and C have dependency on commons-logging.jar. In Geronimo it
would be very likely that you would run into ClassCastExceptions with
such configuration. And the only way to fix it, it would be to create
a new configuration D that would have the dependency on
commons-logging.jar and B and C configurations would have to be
updated to have dependency on D.
In osgi world, bundle B and C would define a Import-Package on the
commons-logging package and the osgi system at runtime would figure
out that B and C must be wired to the same bundle that provides the
commons-logging library.
So classloader-per-jar is important and so is the runtime dependency
resolution to make sure that the same library is not loaded from two
different classloaders within the hierarchy.

<random thoughts>
Hmm... I'm not sure what would happen if B and C used Require-Bundle
and specify two different bundle names for libraries that provide the
commons-logging library. Would we would see ClassCastExceptions (same
as in Geronimo right now) or would osgi just pick one of these bundles
as the default?

Hmm... in Geronimo with artifact substitutions can we substitute jar
for car or car for jar?
</random thoughts>

> Basically it seems to me that osgi has the same problem as geronimo here,
> that you have to include some really intrusive metadata in every jar to
> specify the classloading behavior.  Osgi has merely brainwashed everyone
> into thinking that its metadata is desirable since its part of the manifest
> whereas geronimo has some weird binary goo that no one is familiar with.
>  Maven does the same thing, packing the pom into every jar it builds (plus
> supplying it alongside in the repository)
> So, everyone has the same problem -- you need a bunch of classloader
> metadata associated with the artifacts you want to use -- and pretty much
> agrees on the content, although each solution emphasizes different things.
>  IMO no one has a good solution yet.  For instance AFAICT the felix  bundle
> maven plugin is typically used to effectively convert the maven artifact
> dependencies to equivalent package import/export specifications.

Yep, I agree.


View raw message