You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by James Strachan <ja...@gmail.com> on 2006/03/17 10:00:53 UTC
Supporting XBean services within the GBean kernel
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.
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?
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.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Supporting XBean services within the GBean kernel
Posted by Guillaume Nodet <gu...@worldonline.fr>.
James Strachan wrote:
>
> 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.
>
>
> <http://radio.weblogs.com/0112098/>
The problem is that Geronimo jmx connector only exposes GBeans and not
real MBeans, so that all these MBeans won't be accessible through JMX...
Guillaume Nodet
Re: Supporting XBean services within the GBean kernel
Posted by James Strachan <ja...@gmail.com>.
On 3/17/06, Dain Sundstrom <da...@iq80.com> wrote:
> James, you always ask the hardest questions :)
:)
> On Mar 17, 2006, at 1:00 AM, James Strachan wrote:
[snip]
> 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.
You're right, it probably is better to wait for 2.0; though I'm sure
we can come up with some kind of solution for 1.x even if it is a bit
crappy. e.g. previous GBean integrations of ActiveMQ were pretty much
one crappy GBean that created all of the ActiveMQ POJOs and just
registered a single GBean with Geronimo; so worst case I'm sure we can
do something similar where we have a simple XBeanGBean that might
create oodles of POJOs, but just exposes itself as a single GBean; I
was secretly hoping we could do something a little better than that -
but even that, I'd be OK with it as a tactical solution until the 2.0
goodness comes along.
e.g. deploy any Spring/XBean XML config file as a single GBean would
be pretty useful; even if its not that granular
But certainly, 2.0 is where the fun's gonna start :)
--
James
-------
http://radio.weblogs.com/0112098/
Re: Supporting XBean services within the GBean kernel
Posted by Dain Sundstrom <da...@iq80.com>.
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