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 Wed, 11 Mar 2009 18:27:18 GMT
On Wed, Mar 11, 2009 at 1:29 PM, 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 OSGI.

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.


View raw message