FW: Controlling automated develop-time deployments to JBoss via JMX

[Vincent Massol <vm...@pivolis.com>]

Oops. I meant to send this to the Cactus mailing list in the first
place.

-Vincent

> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: 13 September 2003 17:22
> To: 'Maven Developers List'
> Cc: 'fvancea@maxiq.ro'
> Subject: RE: Controlling automated develop-time deployments to JBoss
via
> JMX
> 
> Hi Florin,
> 
> Sorry about not answering this one. What happens is that I am not into
JMX
> at the moment and I would need to get involved in that to digest your
> post. I really believe this is where we should go in Cactus, i.e.
JMX-ify
> all deployments, so this is certainly something we'll revisit in the
> future. I'm just not ready personally for it.
> 
> Now, that said we need help! If you were to submit patches against CVS
> HEAD  to implement this JMX stuff, and provided it is transparent to
the
> users, then we could commit it easily.
> 
> WRT to the place, I wouldn't worry to much. I would suggest you put in
> action somewhere (Could be in Cactus or somewhere else), tweak it,
make it
> work nicely and if it outgrows the project it is in, then move it
> somewhere else.
> 
> For example, I'd like to separate the container start/stop/deploy
stuff
> from Cactus and make something generic, such as commons-container in
the
> Jakarta Commons project. This would probably go with it. I'd probably
do
> this around the end of the year (unless someone does it first). In the
> meantime, we can improve the Cactus/Ant integration, making sure to
remain
> as generic as possible.
> 
> Of course, once it is moved to commons-container, both Cactus and
Maven
> plugins could use it.
> 
> What do you think?
> 
> Thanks
> -Vincent
> 
> > -----Original Message-----
> > From: Florin Vancea [mailto:fvancea@maxiq.ro]
> > Sent: 04 July 2003 18:28
> > To: 'Cactus Developers List'; Maven Developers List
> > Subject: Controlling automated develop-time deployments to JBoss via
JMX
> >
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org