geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dillon" <>
Subject Re: [vote] XBean donation
Date Tue, 31 Jan 2006 05:14:33 GMT
"a real simple way to define classloader hierarchies", sounds like you want Classworlds....


-----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.


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.


View raw message