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