RE: [Cactus plugin] Full new rewrite

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

Note: I'm cc-ing the cactus dev list as it is of interest to both lists
(probably even more to the cactus one and conversation should probably
be moved to there).

See below.

> -----Original Message-----
> From: Florin Vancea [mailto:fvancea@maxiq.ro]
> Sent: 24 May 2003 12:12
> To: dev@maven.apache.org
> Cc: Vincent Massol
> Subject: Re: [Cactus plugin] Full new rewrite
> 
> Hello Vincent, hello all.
> 
> This _is_ indeed a rework (as you promised not so long ago).
> 
> Probably it works as intended, but I would have a few comments. In
order
> to
> be understood, I will have to start with my history with 2.0.

It has not yet been fully tested yet (I had tried it on Resin 2.x and
Tomcat 4.x). I have just fixed a bug to make it work with JBoss 3.2.1.

> 
> I am using JBoss 3.x as target container in development cycle.
> As soon as the ant-integration module was used in Cactus plugin I
noticed
> that deployment of artifact (cactified WAR) was not handled quite
properly
> in my particular case. I was (and am) running jboss permanently and
take
> advantage of its hot-deploy feature. Therefore, when trying Cactus
within
> Maven I was naturally expecting to use the same (already started)
JBoss.
> As I checked, the test runner task was prepared to "understand" this,
as
> it
> does not blindly try to start and stop the container. Cool.
> However, it also does not wait for hot-deployment to completely
happen. If
> I
> start the container from scratch, this is not an issue, but if the
> container
> is already started and I do a WAR copy into confname/deploy dir, then
the
> tests are run sometimes _before_ the deployment (using the old WAR) or
> _during_ the deployment. In both cases horrible error logs occur and
of
> course the build fails.

Ah yes. This is definitely a use case I have not tested: hot
redeployment... (I always start the container from scratch). Your help
is very valuable!

> 
> Then I decided that if it's not implemented than probably I'm the one
> being
> weird 

absolutely not. It's simply that we haven't really looked at hot
deployment so far. With your help, we can hopefully fix it quickly.

> and I did my own hacking: Whipped up my own Ant task doing JMX
> "surveillance" to block the build until proper undeploy/deploy took
place.
> Since I did not want to hack two projects if I could help it, I hacked
> only
> Maven's plugin to replace build-tests-jboss3x.xml from integration jar
"on
> the fly" with my own version that did the JMX waiting.
> 
> Now 3.0 kicks in, and I have to say it looks elegant (no more weird
jars
> unpacked locally). But this is bad news for me, since the new kit does
not
> work as I'd expect when the container is already started.
> I took the time to dig in Cactus sources from CVS and it appears
> (confirmed
> by my tests) that:
> 
> "If the container is already started, no deployment takes place
(method
> JBoss3xContainer.prepare() is never called ) and tests are run
directly."
> And fail or run whatever WAR they find in there, not necessarily the
fresh
> one.
> 
> It is reasonable to suppose that this is intended behavior and that
one
> would expect the caller to make its own deployment beforehand. I can
live
> with that. However, I would like to know what's the projected course
of
> action:
> 
> 1. Is this the planned way to go? Then Maven plugin (at least my
version
> but
> maybe I'm not the only one) should take care of deploying the
cactified
> WAR.
> At the very least, there should be a warning somewhere in the
generated
> docs
> that one should do it via <preGoal name="cactus:test" > in its
maven.xml.
> I
> could help with that if needed.

No, that's not the intention I believe. Our goal is to make it the
simplest possible for end users. That said, there are 2 main front-ends
(aka integration) for Cactus for automated builds:

1/ The Ant integration: this is for advanced users who wish to
completely control their builds. There is a <generic> container tag that
can be used in inside the <cactus> task to control everything.

2/ The Maven integration is for end users who want to use Cactus in the
easiest possible manner. It currently supports the most basic uses cases
and my goal is to improve it to support more and more scenarios as I get
feedback from its users, such as what you are reporting.

> 
> or
> 
> 2. This is a slip in cactus-ant and it will get corrected, such that
when
> the container is already started the deployment still takes place (but
> please, do not forget to JMX-wait for complete deployment or deploy
via
> JMX
> "in place" the cactified WAR). Then the plugin is fine as-is, but
changes
> are strongly required in cactus-ant to support the "developer mode"
usage
> pattern. If this is the case, please-please do not forget the waiting
> stuff,
> otherwise the whole package will get unusable with hot-deploy JBoss,
not
> even in "mode 1" above.

+1. Thanks for the suggestion. Could you send us your JMX-wait
implementation so that we can use it?

> 
> Thanks for reading this far; I'm expecting your opinions.
> 

Thanks for your feedback.
-Vincent

> Florin
> 
> ----- Original Message -----
> From: "Vincent Massol" <vm...@pivolis.com>
> To: <de...@maven.apache.org>
> Cc: <us...@maven.apache.org>
> Sent: Saturday, May 24, 2003 12:12 AM
> Subject: [Cactus plugin] Full new rewrite
> 
> 
> > Hi,
> >
> > I have just committed a full rewrite of the Maven Cactus plugin. As
it
> > is a rewrite, I have increased the version to 3.0 (it was
2.1-SNAPSHOT
> > before). Note that the 3.0 version is still in development and is
not
> > released yet. I'm waiting for feedback before releasing it.
> >
> > The new version of the Cactus plugin now relies on the newest
Cactus/Ant
> > integration which has completely changed since version 2.0 of the
Maven
> > plugin. Thanks to the new Cactus/Ant, some features have also been
> > added. The plugin now uses the new <cactifywar> and <cactus> Ant
tasks
> > (see http://jakarta.apache.org/cactus/integration/ant/index.html for
> > more details).
> >
> > Note that version 2.1-SNAPSHOT will never get released as 1/ a bug
ad
> > been introduced and 2/ the direction is to use the Cactus/Ant
> > integration which has been changed in Cactus CVS.
> >
> > Please give it a try and report any issue on the Maven mailing
> > lists/JIRA. You can find a read-made test application in
> >
http://cvs.apache.org/viewcvs.cgi/maven/src/plugins-build/cactus/sample/
> > if you wish.
> >
> > Thank you
> > -Vincent
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> 



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

Re: [Cactus plugin] Full new rewrite

[Florin Vancea <fv...@maxiq.ro>]

BackNote :) : I'm only hooked up to maven-dev list and I'd really-really not
link into cactus-dev unless I really have to. There are already too many
lists I'm trying to track and once I "adopt" one it's hard for me to let go
:)
Therefore, whoever is participating in this thread from cactus-dev,
pretty-please cc to me, too, especially if this issue moves out of
maven-dev.

This cleared, see below.

----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Florin Vancea'" <fv...@maxiq.ro>
Cc: <de...@maven.apache.org>; "'Cactus Developers List'"
<ca...@jakarta.apache.org>
Sent: Saturday, May 24, 2003 2:47 PM
Subject: RE: [Cactus plugin] Full new rewrite


> Note: I'm cc-ing the cactus dev list as it is of interest to both lists
> (probably even more to the cactus one and conversation should probably
> be moved to there).
>
> See below.
>
[snip]
>
> Ah yes. This is definitely a use case I have not tested: hot
> redeployment... (I always start the container from scratch). Your help
> is very valuable!
>

Thanks.

> >
> > Then I decided that if it's not implemented than probably I'm the one
> > being
> > weird
>
> absolutely not. It's simply that we haven't really looked at hot
> deployment so far. With your help, we can hopefully fix it quickly.

Let's try then.

>
[snip]
>
> No, that's not the intention I believe. Our goal is to make it the
> simplest possible for end users. That said, there are 2 main front-ends
> (aka integration) for Cactus for automated builds:
>
> 1/ The Ant integration: this is for advanced users who wish to
> completely control their builds. There is a <generic> container tag that
> can be used in inside the <cactus> task to control everything.

Now that you mentioned it, I took a peek into GenericContainer. It seems to
me it has no "deploy" task. I believe some containers have to be started for
deploy to take place (i.e. just copying the artifact somewhere is not
enough). Shouldn't there be also a "deploy" hook?
Actually the processing as I see it (based on my experience with JBoss) is
something like:
1. Start if not already started. (this may also prepare some config-info if
needed)
2. Deploy cactified WAR. Make sure deployment is over. (this step may need
some additional info if we were not the creators of the current config - we
were not the ones who started in step 1.)
3. Run tests (this is the job of some higher entity, like the <cactus> tag)
4. Shutdown if we started it. (maybe here we should cleanup/undeploy, at
least when tests succeeded).

>
> 2/ The Maven integration is for end users who want to use Cactus in the
> easiest possible manner. It currently supports the most basic uses cases
> and my goal is to improve it to support more and more scenarios as I get
> feedback from its users, such as what you are reporting.

For continuous integration purposes, the start/test/stop approach is best,
since it goes cleaner. However for development (even if it's just developing
tests) starting/stopping something like JBoss, with a full-feature setup,
it's a huge hit.

>
> >
> > or
> >
> > 2. This is a slip in cactus-ant and it will get corrected, such that
> when
> > the container is already started the deployment still takes place (but
> > please, do not forget to JMX-wait for complete deployment or deploy
> via
> > JMX
> > "in place" the cactified WAR). Then the plugin is fine as-is, but
> changes
> > are strongly required in cactus-ant to support the "developer mode"
> usage
> > pattern. If this is the case, please-please do not forget the waiting
> > stuff,
> > otherwise the whole package will get unusable with hot-deploy JBoss,
> not
> > even in "mode 1" above.
>
> +1. Thanks for the suggestion. Could you send us your JMX-wait
> implementation so that we can use it?

Now that'll take some time. It's a messy one. If still wanted after reading
the following, I'll do it. (don't forget the licensing issues for the client
part of JBoss, too).
I wanted to clean it up to the point it is postable some time in the past,
for maven-jboss-plugin, but James was quicker to provide a much simpler
approach. His idea is usable here, too. The only drawback is that it's
applicable for deployment "in place", i.e. it deploys the very WAR locally
produced (be it file or dir structure). After testing it should be mandatory
to undeploy it automatically, otherwise executing a subsequent "clean"
target will/might blow the running JBoss.

Another possibility would be after starting to go like:
1. delete the WAR from /deploy/ dir
2. wait until a HTTP request for that Cactus context fails 404
3. copy the new WAR
4. wait until a "dummy" request for that Cactus context succeeds (NOT a test
request)
5. start testing

This is tricky, due to the thread pooling that goes underneath in the
servlet container. Lots of odd errors (actually expectable due to the
approach) will pop in the debug/console and might even cause more unexpected
results.

Yet another way would be to "reserve" a dir sibling to JBoss's canonical
/deploy. Let's call it /cactusdeploy. it would go like this:
1. make sure cactudeploy exists (beware: shouldn't be
autodeploy-configured).
2-pre. trigger undeployment of any same-named existing WAR there using HTTP
adapter (James-way)
2. copy the WAR there
3. trigger deployment using HTTP adapter (James-way)
4. run the tests
5. undeploy using HTTP adapter (if desired, for cleaning-up)

If something goes bad, the leftover is in jboss dir structure and not
affected by clean, and furthermore not loaded automatically on next restart
(i.e. no risk for bloating or conflicts).
The disadvantage is that one additional copy is required.

Yet-yet another way: As I said the previous time, there is an Ant task in
JBoss distribution itself. However, AFAIK, even the 3.2 series do not have
the final touch on it, let alone 3.0x ones.

>
> >
> > Thanks for reading this far; I'm expecting your opinions.
> >
>
> Thanks for your feedback.
> -Vincent
>

Florin



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

Re: [Cactus plugin] Full new rewrite

[Florin Vancea <fv...@maxiq.ro>]

BackNote :) : I'm only hooked up to maven-dev list and I'd really-really not
link into cactus-dev unless I really have to. There are already too many
lists I'm trying to track and once I "adopt" one it's hard for me to let go
:)
Therefore, whoever is participating in this thread from cactus-dev,
pretty-please cc to me, too, especially if this issue moves out of
maven-dev.

This cleared, see below.

----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Florin Vancea'" <fv...@maxiq.ro>
Cc: <de...@maven.apache.org>; "'Cactus Developers List'"
<ca...@jakarta.apache.org>
Sent: Saturday, May 24, 2003 2:47 PM
Subject: RE: [Cactus plugin] Full new rewrite


> Note: I'm cc-ing the cactus dev list as it is of interest to both lists
> (probably even more to the cactus one and conversation should probably
> be moved to there).
>
> See below.
>
[snip]
>
> Ah yes. This is definitely a use case I have not tested: hot
> redeployment... (I always start the container from scratch). Your help
> is very valuable!
>

Thanks.

> >
> > Then I decided that if it's not implemented than probably I'm the one
> > being
> > weird
>
> absolutely not. It's simply that we haven't really looked at hot
> deployment so far. With your help, we can hopefully fix it quickly.

Let's try then.

>
[snip]
>
> No, that's not the intention I believe. Our goal is to make it the
> simplest possible for end users. That said, there are 2 main front-ends
> (aka integration) for Cactus for automated builds:
>
> 1/ The Ant integration: this is for advanced users who wish to
> completely control their builds. There is a <generic> container tag that
> can be used in inside the <cactus> task to control everything.

Now that you mentioned it, I took a peek into GenericContainer. It seems to
me it has no "deploy" task. I believe some containers have to be started for
deploy to take place (i.e. just copying the artifact somewhere is not
enough). Shouldn't there be also a "deploy" hook?
Actually the processing as I see it (based on my experience with JBoss) is
something like:
1. Start if not already started. (this may also prepare some config-info if
needed)
2. Deploy cactified WAR. Make sure deployment is over. (this step may need
some additional info if we were not the creators of the current config - we
were not the ones who started in step 1.)
3. Run tests (this is the job of some higher entity, like the <cactus> tag)
4. Shutdown if we started it. (maybe here we should cleanup/undeploy, at
least when tests succeeded).

>
> 2/ The Maven integration is for end users who want to use Cactus in the
> easiest possible manner. It currently supports the most basic uses cases
> and my goal is to improve it to support more and more scenarios as I get
> feedback from its users, such as what you are reporting.

For continuous integration purposes, the start/test/stop approach is best,
since it goes cleaner. However for development (even if it's just developing
tests) starting/stopping something like JBoss, with a full-feature setup,
it's a huge hit.

>
> >
> > or
> >
> > 2. This is a slip in cactus-ant and it will get corrected, such that
> when
> > the container is already started the deployment still takes place (but
> > please, do not forget to JMX-wait for complete deployment or deploy
> via
> > JMX
> > "in place" the cactified WAR). Then the plugin is fine as-is, but
> changes
> > are strongly required in cactus-ant to support the "developer mode"
> usage
> > pattern. If this is the case, please-please do not forget the waiting
> > stuff,
> > otherwise the whole package will get unusable with hot-deploy JBoss,
> not
> > even in "mode 1" above.
>
> +1. Thanks for the suggestion. Could you send us your JMX-wait
> implementation so that we can use it?

Now that'll take some time. It's a messy one. If still wanted after reading
the following, I'll do it. (don't forget the licensing issues for the client
part of JBoss, too).
I wanted to clean it up to the point it is postable some time in the past,
for maven-jboss-plugin, but James was quicker to provide a much simpler
approach. His idea is usable here, too. The only drawback is that it's
applicable for deployment "in place", i.e. it deploys the very WAR locally
produced (be it file or dir structure). After testing it should be mandatory
to undeploy it automatically, otherwise executing a subsequent "clean"
target will/might blow the running JBoss.

Another possibility would be after starting to go like:
1. delete the WAR from /deploy/ dir
2. wait until a HTTP request for that Cactus context fails 404
3. copy the new WAR
4. wait until a "dummy" request for that Cactus context succeeds (NOT a test
request)
5. start testing

This is tricky, due to the thread pooling that goes underneath in the
servlet container. Lots of odd errors (actually expectable due to the
approach) will pop in the debug/console and might even cause more unexpected
results.

Yet another way would be to "reserve" a dir sibling to JBoss's canonical
/deploy. Let's call it /cactusdeploy. it would go like this:
1. make sure cactudeploy exists (beware: shouldn't be
autodeploy-configured).
2-pre. trigger undeployment of any same-named existing WAR there using HTTP
adapter (James-way)
2. copy the WAR there
3. trigger deployment using HTTP adapter (James-way)
4. run the tests
5. undeploy using HTTP adapter (if desired, for cleaning-up)

If something goes bad, the leftover is in jboss dir structure and not
affected by clean, and furthermore not loaded automatically on next restart
(i.e. no risk for bloating or conflicts).
The disadvantage is that one additional copy is required.

Yet-yet another way: As I said the previous time, there is an Ant task in
JBoss distribution itself. However, AFAIK, even the 3.2 series do not have
the final touch on it, let alone 3.0x ones.

>
> >
> > Thanks for reading this far; I'm expecting your opinions.
> >
>
> Thanks for your feedback.
> -Vincent
>

Florin



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