geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Whence the geronimo kernel?
Date Wed, 11 Mar 2009 19:30:06 GMT

On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote:

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

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

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.

<rant coherency="questionable">
To me it seems like there are two opposing forces at work here.  On  
the one hand you want your code to be able to run in a variety of  
environments.  On the other hand you want to be able to know and  
specify stuff about the environment.  The environment basically boils  
down to a graph of a bunch of jars.  (with osgi, the classes you  
specifiy in import/export requirements are in fact coming from some  
jar, somewhere).  So how are you going to specify that graph?  How are  
you going to make it flexible?  What's the boundary between your app  
and the outside world?

Maven and geronimo deal with this by having your app specify the jars  
it wants and by allowing some way to substitute jars (artifact-aliases  
in geronimo, exclusions in maven).  osgi lets you specify the jars you  
want (require-bundle.... I don't know if there's any way of overriding  
this like in geronimo and maven) or by import/export specifications.   
As far as I know in osgi to control what you get with import/export  
specifications you have to control what jars are known to the osgi  
implementation.  Maven and geronimo are unfortunately tieing your app  
to particlar implementations but let you specify that implementation  
easily.  Osgi is not forcing you to specify which implementation you  
want but is saying that specifying it is someone else's problem.

Think of what happens when you assemble a geronimo custom server.  You  
specify the particular "app" plugins you want (say your app deployed  
with jetty and cxf and myfaces and a db pool and amq config) and  
geronimo uses the dependency information to pull in everything else  
you need for a complete server.  If you want a different db pool you  
use artifact aliases to get that one instead.  Geronimo and maven are  
asymmetric in that there is one "primary" dependency specified in the  
plugin itself (say the db pool you want) but you can override it  
somehow.  I don't know how to specify stuff like this conveniently in  
osgi.  (I'm aware that I'm mixing up classloading and service  
dependencies here but think I still have a point even if not very well  

david jencks
> Jarek

View raw message