jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florin Vancea" <fvan...@maxiq.ro>
Subject Controlling automated develop-time deployments to JBoss via JMX
Date Fri, 04 Jul 2003 16:28:04 GMT
Hello all,

sorry for cross-posting, I think it's necessary and I hope you'll agree
after reading up to the end.

~~~ Cactus-targeted section (mainly) ~~~
As I promised, I looked into the JMX way to control deployments on JBoss.
Now I prepared a small package exposing a bean able to be used as a Ant task
(and of course as plain bean, too).
This bean basically waits for a specified URL or filepath to achieve
"deployed" or "undeployed" status in a running JBoss instance.
Incidentally, it can be used to monitor the deployment status of
"jboss-service.xml", thus monitoring the proper start of the server before
shooting Cactus HTTP requests at it. Or I think so, 'cause I have not tried
yet this trick.
Embedding this in the integration part of Cactus would solve "at grassroot"
the 500ms JBoss startup timeout issue I raised three weeks ago. At least for
JBoss.

Please read on.

~~~ Maven-targeted section ~~~

Maven users could also make good use (IMO) of this "deployment monitor"
feature. Picture the situation:
One project is containing some classes making remote requests to EJB's
running in the container. Before testing those classes, the
latest-and-greatest EAR carrying the EJB's must be deployed into the server
(with a preGoal name="test:test" in maven.xml). But before starting the
actual testing we should make sure the EJB's are completely deployed. JMX
monitoring would come to the rescue, either as a Jelly-instantiated bean or
as a plain Ant task.

Please read on.

~~~ common section ~~~

The cool thing (again IMO) is that the bean (and the whole package) does not
really depend (at least not compile-time) on the bunch of JBoss and other
classes needed to do JMX with JBoss. This means no class version clashes, no
need to worry "am I using again the 3.0.4 client classes against the 3.2.1
server?".

Now why the crosspost:
If I would offer the pack to Cactus (provided they would accept it :) ),
Maven users would not be able to (directly) use the bean. Pity (not for me,
'cause I brew my own :) ).
The place of this gizmo is not inside the Maven JBoss plugin either.
Furthermore, Cactus would still rely on timeouts then, which is a bad idea
and was my primary reason to write the pack.

My only idea is that it should be a package on its own, used as a dependency
by both Maven and Cactus. This way it can grow, to provide additional things
like autodetecting of HTTP listener ports, autodetecting of current running
config, ... you get the picture.

I do not have the possibility to host a public CVS, otherwise I would make
this right away a public package hosted on my server.

I have no experience with licensing, so I cannot tell on which of the open
source servers this should/might go. To me it seems maybe a Jakarta thingie,
but I may be wrong, due to its (potential) LGPL-ness.

Please give me some advice.

And in the meanwhile, for those really interested, the ones that got so far
into this story, please check http://open.maxiq.com/jbossjmx/ to see what's
all about in binary and source form. And if you've been there, maybe you
drop me a note with your opinion.

Florin



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


Mime
View raw message