This is defintely a good move! How will that affect the programming model around Geronimo? Obviously some users are not happy with the complexity of the deployment plan [1].
-Jack [1] http://www.nabble.com/your-current-Geronimo-evaluation-td22329850s134.html 2009/3/5 Ivan <xhh...@gmail.com> > It is a good idea. > I encounter some similar issues about the multiparent classloader. From the > pom.xml, currently, it is hard to know which jar is in the classpath. The > dependies between the configurations are also too complex, I notice that the > restart/reload codes in the configurationManager is very very ... > Maybe we could replace all the codes in the configurationManager, and just > delegate it to the OSGI module/lifecycle layer. > Thanks ! > > > 2009/3/5 David Jencks <david_jen...@yahoo.com> > > 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 >> >> > > > -- > Ivan >
