"a real simple way to define classloader hierarchies", sounds like you want Classworlds....
--jason -----Original Message----- From: James Strachan <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 11:03:24 To:[email protected] 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 ------- http://radio.weblogs.com/0112098/
