geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [vote] XBean donation
Date Tue, 31 Jan 2006 06:34:49 GMT
I don't consider classworlds simple at all.


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 <>
> Date: Mon, 30 Jan 2006 11:03:24
> 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
> -------

View raw message