geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Whence the geronimo kernel?
Date Thu, 05 Mar 2009 08:28:48 GMT
We've spoken about this, in the past. I'm certainly in favor of  
exploring this...

On Mar 4, 2009, at 7: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.

Agreed.

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

Classloaders certainly can be hard. In some ways, however, I think  
we'll be trading one set of problems for another. Hopefully, the net  
sum is in our benefit...


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

Agreed.

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

Right. So, this is a pretty strong motivation, IMO. Users are looking  
for an OSGi standards-based mechanism for installing services/ 
applications, without having to learn/conform to Geronimo techniques.

> 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

Agreed.

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

Sounds like a good start. I think there'll be a lot of learning/ 
discovery that will be taking place. So, prolly not much point in over- 
refining, now.

Definitely interested. However, likely to be somewhat time- 
constrained. Will do what I can...

--kevan

Mime
View raw message