On Wed, Mar 11, 2009 at 08:57, Gianny Damour <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). 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 ... 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
