Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Message-ID: <0bb601c383ee$9795fc30$0b6fa8c0@jazz>
From: "Florin Vancea" <fvancea@maxiq.ro>
To: "Vincent Massol" <vmassol@pivolis.com>,
   "'Maven Developers List'" <dev@maven.apache.org>
References: <000901c37a0a$c0cdf2d0$9f24b4d4@vma>
Subject: Re: Controlling automated develop-time deployments to JBoss via JMX
Date: Fri, 26 Sep 2003 08:25:25 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Sorry for the long delay, this time on my side.

As far as Maven is concerned, waiting for the release would be the best
thing to do. Plugin status will be clarified by then.
As far as Cactus is concerned, you call the shots.
As far as I am concerned, I am (and very likely will be) a little busy, so I
cannot afford at the moment to do anything on this issue. As soon as things
clear, I will try to catch up with things and if it's still an open issue
I'll try to do something.

Florin

----- Original Message -----
From: "Vincent Massol" <vmassol@pivolis.com>
To: "'Maven Developers List'" <dev@maven.apache.org>
Cc: <fvancea@maxiq.ro>
Sent: Saturday, September 13, 2003 6:21 PM
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
>
>
>


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