Sorry. I meant to send this to the Cactus mailing list. -Vincent
> -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 13 September 2003 17:22 > To: 'Maven Developers List' > Cc: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
