Guillaume Nodet wrote:
>
>
> On Wed, Mar 11, 2009 at 08:57, Gianny Damour
> <gianny.damour@optusnet.com.au <mailto:gianny.damour@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
>
>
|