Really? I think it is the simplest classloader API with the most
flexibility... or maybe I'm just tainted by all that UCL mess... so
anything other than that is simple.
BUT, jokes aside, Classworlds is really simple to create hierarchies,
either from configuration or programatically. Some of the more
advanced import scoping fluff could get complicated, but I just don't
use that.
--jason
On Jan 30, 2006, at 10:34 PM, Dain Sundstrom wrote:
I don't consider classworlds simple at all.
-dain
On Jan 30, 2006, at 9:14 PM, Jason Dillon wrote:
"a real simple way to define classloader hierarchies", sounds like
you want Classworlds....
--jason
-----Original Message-----
From: James Strachan <[EMAIL PROTECTED]>
Date: Mon, 30 Jan 2006 11:03:24
To:dev@geronimo.apache.org
Subject: Re: [vote] XBean donation
On 29 Jan 2006, at 18:50, Dain Sundstrom wrote:
On Jan 27, 2006, at 1:11 PM, Aaron Mulder wrote:
+1
I assume this will just be a regular subproject at present. If
one of
the XBean folks could talk a little about how XBean could
ultimately
be adopted by Geronimo (the app server), that would be great. I
think
we talked about ways that Geronimo and XBean could move to close
the
gap and thus eventually make it possible to for Geronimo to adopt
XBean without it being such a massive change, but I'm a little
fuzzy
on the details.
Thanks,
Aaron
You're a bit fuzzy on the detail because every is a bit fuzzy. I
have a few idea about how to integrate the code, but we're not
going to know exactly how the integration will work or if we want
to do it at all until we try. Just wanted to drop a warning before
jumping into my ideas.
XBean has several modules most of which are designed for direct
XBean users like Service-Mix, ActiveMQ and XFire, so I'm going to
only address the kernel and server module.
The kernel in XBean has a very light weight kernel compared to the
Geronimo kernel. For example, the Geronimo kernel directly
supports object name queries, and in XBean name querying is an
optional service. The other big difference is the code is just
easier to follow :) *If* we decide to switch to the XBean kernel,
we can easily create an implementation of the current Geronimo
kernel interface that simply calls through to the XBean kernel. I
had this working with the XBean 1.0 kernel, but haven't written a
bridge for the 2.0 kernel yet.
The server module is more tricky. The server module contains
simplified start up code, support for spring based configurations
and some experimental class loaders. All of these will take work
to determine if they are beneficial to Geronimo and if so, how to
integrate them with out breaking current users. I think that more
importantly than integrating the code is integrating the ideas in
the server module. For example, the startup code in XBean would
allow us to eliminate the serialized object graph in the our
startup jars, which contain important attributes that we can't edit.
Agreed.
I think once we import the code into an xbean module we can start
experimenting with a cleaner & more lightweight POJO based kernel/
server/deployer that avoids much of the GBean plumbing. e.g. I'd love
a real simple way to define classloader hierarchies and to auto-
deploy & redeploy spring.xml & xbean.xml files inside those class
loaders as a nice simple Spring/POJO container.
James
-------
http://radio.weblogs.com/0112098/
