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: domain of james.strachan@gmail.com
 designates 64.233.182.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=s9y9kh42C8+PnR9Xw5+r29+wHCWkD0P+Pu+UjwPbRsv7dL9vrR7iMezJDjrg/cydLAFMmokBP7p0gwlB4bsfHNdurcoE6iyEX91PDLRjS+7xuNGGRkDcsXLltM6U23LGa9E+Vluv3hW+19g/lEhh2f0WThtYNARYL03TsV4AkQo=
Message-ID: <ec6e67fd0603170100j1cb9b855se8c2e14a3e610cee@mail.gmail.com>
Date: Fri, 17 Mar 2006 09:00:53 +0000
From: "James Strachan" <james.strachan@gmail.com>
To: dev@geronimo.apache.org
Subject: Supporting XBean services within the GBean kernel
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_498_12597606.1142586053768"

------=_Part_498_12597606.1142586053768
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I fell for the charms of XBean a long time ago; both ActiveMQ and ServiceMi=
x
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/

------=_Part_498_12597606.1142586053768
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I fell for the charms of XBean a long time ago; both ActiveMQ and ServiceMi=
x 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.=20
e.g. the following test repository boots up ActiveMQ fully configured via X=
Bean. (This deployer could use some work to be able to deal with service an=
d classpath dependencies, to allow graphs rather than just trees to be used=
)
<br><a href=3D"http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-s=
erver/src/test/repository/">http://svn.apache.org/repos/asf/geronimo/xbean/=
trunk/xbean-server/src/test/repository/</a><br><br>The GBean integration of=
 ActiveMQ has always been pretty simple and limited; I&quot;ve always wante=
d full rich integration where every single transport connector, network con=
nector, journal configuration, thread pool, queue, topic, connection &amp; =
subscription are all richly available to the GBean kernel &amp; 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.
<br><br>So I'm wondering if we can put together some kind of GBean facade t=
o XBean; so the current kernel sees the XBean world as just a bunch of GBea=
ns and anything which can deploy in XBean (which includes pretty much every=
 Spring application on the planet) suddenly becomes available nicely into t=
he GBean world.
<br clear=3D"all"><br>Something like a GBean which boots up the XBean kerne=
l and exposes all the registered services as GBeans would do the trick. It =
shouldn't be too hard right?<br><br>A second question is; what to do about =
JMX. In ActiveMQ we've written a bunch of MBeans so whether you use ActiveM=
Q 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 c=
reated at deployment time; though most of them come and go as clients conne=
ct to the broker and the brokers own runtime state changes=20
e.g. deach connection &amp; subscription has an MBean; clients can create n=
ew destinations at runtime etc. How would it be best to integrate those int=
o 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.
<br><br>-- <br><br>James<br>-------<br><a href=3D"http://radio.weblogs.com/=
0112098/">http://radio.weblogs.com/0112098/</a>

------=_Part_498_12597606.1142586053768--