geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Whence the geronimo kernel?
Date Thu, 05 Mar 2009 11:13:41 GMT
The one difficulty I see in moving from the current Geronimo 
classloading model to the OSGi model is dealing with the change in 
granularity.  In the current model, the granularity is at the jar level 
and using the one-classloader-per-jar model, you get all of the classes 
contained in the jar.  This is generally the source of the various class 
loading conflict we see with Geronimo.  Different jars might contain 
their own versions of classes, creating the conflict. 

With the OSGi model, each bundle explicitly specifies its classloading 
dependencies in the form of package imports and also specifies which 
classes it makes available for others to use as package exports.  Any 
packages not specified as exports are private to the bundle scope and 
are only directly visible to the bundle itself. 

The bnd tools created by Peter Kriens is a good step toward converting 
jars into bundles.  It examines all of the class files contained in a 
jar and figures out which files need to be imported from other source 
and constructs the appropriate headers.  This works ok if the bundle 
doesn't need to export any packages.  If exports are required, then 
additional information about the jar is required. 

There are a couple of additional downsides to the static analysys: 

1)  This type of analysis can detect which packages are required, but 
doesn't tell you anything about which versions of the packages are 
needed.  This can probably be sorted out by coupling the analysis 
information with information from the maven-style dependencies.  That 
is, your jar requires package org.apache.foo.bar and you specify you 
have a dependency on org.apache.foo-1.3.2 which happens to export 
org.apache.foo.bar package, so your bundle import dependency for 
org.apache.foo.bar is set to the 1.3.2 version level.

2)  It's not very good at determining dynamic classloading 
dependencies.  This also requires some additional metadata to indicate 
certain packages are going to be required by the application.

Rick

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


Mime
View raw message