Guillaume Nodet wrote:
On Wed, Mar 11, 2009 at 08:57, Gianny Damour
<gianny.dam...@optusnet.com.au <mailto:gianny.dam...@optusnet.com.au>>
wrote:
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 D).
I have to agree with Guillaume on this. A lot of the difficulties that
people run into with trying to configure the classloading options on
Geronimo can become non-issues under the OSGi model. Those sorts of
problems are handled automatically by the OSGi framework. On the
downside, a lot more work needs to go into specifying the package
dependencies. This can make "bundlizing" a jar an interesting exercise
the first time.
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 ...
OSGi is definitely moving in that direction. There are a number of RFCs
in the works for how that sort of autodiscovery should behave running on
an OSGi framework. The new blueprint service will provide a native
application assembly model, and other RFCs cover discovering/running
different types of JEE application types.
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
(http://www.grails.org/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 bundles.
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: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
