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
