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 06:48:23 GMT
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.


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