Hi David, I think this is a good move and worthy investigation! I have some comments below.
On Wed, Mar 4, 2009 at 7:56 PM, David Jencks <david_jen...@yahoo.com> 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. I have used the Import-Package function. The bundle I was trying to build can get javax.transaction pacakge from the J2SE or the geronimo's jta spec jar, so I had to specify the exact version of the javax.transaction package in the Import-Package attribute and let the bnd tool figure out the rest. This works well for me. The bnd tool cannot auto-discover this so this have to be done manually AFAIK. > 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 Osgi is building a bundle repository RFC (think it is rfc 112). I haven't looked into detail so not sure if it is related to maven at all, but you may want to check it out. > > at this point I think geronimo would be running on osgi, still using gbeans. Are you envisioning all the geronimo plugins converted to OSGi bundles to run in the OSGi based kernel? > - 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 > >
