Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <ec6e67fd0603170100j1cb9b855se8c2e14a3e610cee@mail.gmail.com>
References: <ec6e67fd0603170100j1cb9b855se8c2e14a3e610cee@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8E3F426D-2723-4633-B34E-E3AA736161EF@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Supporting XBean services within the GBean kernel
Date: Fri, 17 Mar 2006 10:19:00 -0800
To: dev@geronimo.apache.org

James, you always ask the hardest questions :)

On Mar 17, 2006, at 1:00 AM, James Strachan wrote:

> I fell for the charms of XBean a long time ago; both ActiveMQ and  
> ServiceMix have been using it as its primary configuration  
> mechanism for some time. I recently XBean-ified Jetty too which  
> took about an hour and can currently configure most of Jetty.  
> Incidentally there's currently a real simple file system based  
> deployer that can walk the file system building up classpath trees  
> and booting up any XBean or Spring applications it finds. e.g. the  
> following test repository boots up ActiveMQ fully configured via  
> XBean. (This deployer could use some work to be able to deal with  
> service and classpath dependencies, to allow graphs rather than  
> just trees to be used)
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-server/ 
> src/test/repository/
>
> The GBean integration of ActiveMQ has always been pretty simple and  
> limited; I"ve always wanted full rich integration where every  
> single transport connector, network connector, journal  
> configuration, thread pool, queue, topic, connection & subscription  
> are all richly available to the GBean kernel & management subsystem  
> etc. We kinda have that today with a combination of XBean and JMX;  
> but it doesn't really integrate yet with the GBean kernel.
>
> So I'm wondering if we can put together some kind of GBean facade  
> to XBean; so the current kernel sees the XBean world as just a  
> bunch of GBeans and anything which can deploy in XBean (which  
> includes pretty much every Spring application on the planet)  
> suddenly becomes available nicely into the GBean world.

The short answer is not without a lot of work and re-architecting of  
the Geronimo kernel.  My rough plan is to not do a full XBean  
integration until Geronimo 2.0, but in the 1.x tree I would like to  
continue to simplify and add more features from xbean.  Specifically,  
I would like to integrate the xbean-reflect package for building  
attributes into Geronimo.  This will allow us to build arbitrarily  
complex attribute values which can contain references to other  
GBeans.  I have already added an optional flag to turn of proxing of  
references between GBeans and hope to have that always on in Geronimo  
1.2.  I doubt we will be able to add xbean-spring to Geronimo until 2.0.

> Something like a GBean which boots up the XBean kernel and exposes  
> all the registered services as GBeans would do the trick. It  
> shouldn't be too hard right?

Unfortunately, it just isn't the way Geronimo works.

> A second question is; what to do about JMX. In ActiveMQ we've  
> written a bunch of MBeans so whether you use ActiveMQ in J2SE or  
> J2EE you can point JConsole at the JVM and see all the various  
> stats, queue depths, buffer sizes and so forth. Some of these  
> things are created at deployment time; though most of them come and  
> go as clients connect to the broker and the brokers own runtime  
> state changes e.g. deach connection & subscription has an MBean;  
> clients can create new destinations at runtime etc. How would it be  
> best to integrate those into the GBean infrastructure - or would it  
> be best to just leave them in JMX and let the management portlets  
> just use JMX to access them.

I'm not sure on this one.

-dain