You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/09/13 17:21:47 UTC
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
Re: Controlling automated develop-time deployments to JBoss via JMX
Posted by Florin Vancea <fv...@maxiq.ro>.
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" <vm...@pivolis.com>
To: "'Maven Developers List'" <de...@maven.apache.org>
Cc: <fv...@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
RE: Controlling automated develop-time deployments to JBoss via JMX
Posted by Vincent Massol <vm...@pivolis.com>.
Sorry. I meant to send this to the Cactus mailing list.
-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
>
>
>
> ---------------------------------------------------------------------
> 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