On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote:
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks
<[email protected]> 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
expressed)
</rant>
thanks
david jencks
Jarek
