geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [vote] XBean donation
Date Mon, 30 Jan 2006 12:00:08 GMT
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 :-)


> James
> -------

"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)
 * Open Source Training & Support.

View raw message