James Strachan wrote:
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.
This sounds like my dreams come true - I can't wait :-)
Jules
James
-------
http://radio.weblogs.com/0112098/
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
