Cargo

Add the ability ignore failures when undeploy fails (for example, if the application is not deployed)

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.2.1
  • Fix Version/s: 1.2.2
  • Component/s: Maven2
  • Labels:
    None
  • Complexity:
    Intermediate
  • Tested on JDKs:
    1.7
  • Number of attachments :
    0

Description

The deployment against a JBoass AS 7 is very restrictive.
One need to know the exact state of the server.

Is the application deployed or not?

It is not allowed to undeploy a not existent application. The resulting error is:
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deployer-undeploy (undeploy-project) on project XXX: Execution undeploy-project of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:deployer-undeploy failed: Cannot undeploy deployable org.codehaus.cargo.container.jboss.deployable.JBossWAR[YYY.war]: Deployment action UNDEPLOY failed: "JBAS014807: Management resource '[(\"deployment\" => \"YYY.war\")]' not found" -> [Help 1]

With other application servers I could not recognize this behavior!

The original JBoss deployment plugin "jboss-as-maven-plugin" has the same strange behavior. But at least it gaves the option to deploy over an existing application via the use of "force".

In our usecase we want to undeploy the application before every new deployment - if it does exist. Of course this is not possible initial. But a Tomcat instance ignores that. JBoss throws an exception.

It would be nice, if cargo could catch this annoying exception.

And other option could be to support to "force" a deployment. JBoss supports to force a deployment. So it re-deploys, if the application does exist. I do not realy like the last solution, but it es better than nothing.

Thanks in advance for your reply!

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. CARGO-242 cargo:smartdeploy

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Stephan

CARGO has three possible deployer actions:

  • deploy
  • undeploy
  • redeploy

The third is very probably what you're looking for: it will try to undeploy the application, and then deploy it.

Can you please try?

Thank you

Show
Savas Ali Tokmen added a comment - Hi Stephan CARGO has three possible deployer actions: deploy undeploy redeploy The third is very probably what you're looking for: it will try to undeploy the application, and then deploy it. Can you please try? Thank you
Hide
Permalink
Stephan Lau added a comment -

Hi Savas

The redeploy action works like described. Thank you. But that is not exactly what we need.

Our deployment is not that easy. Before we can deploy a new application version, we often change the database schema (using the liquibase maven plugin).
So it is no bad idea to undeploy an eventually existing older application version before manipulating the database structure.

With another project where we use a Tomcat instance this works like charme with CARGO.
The same usecase does not work as expected with an JBoss instance.

My question - before everything else - is: What is the defined behavior of your API?
I found no information about this. It would be nice to have a well defined behavior, which does not change if anyone changes the target application server.

Many greetings

Show
Stephan Lau added a comment - Hi Savas The redeploy action works like described. Thank you. But that is not exactly what we need. Our deployment is not that easy. Before we can deploy a new application version, we often change the database schema (using the liquibase maven plugin). So it is no bad idea to undeploy an eventually existing older application version before manipulating the database structure. With another project where we use a Tomcat instance this works like charme with CARGO. The same usecase does not work as expected with an JBoss instance. My question - before everything else - is: What is the defined behavior of your API? I found no information about this. It would be nice to have a well defined behavior, which does not change if anyone changes the target application server. Many greetings
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Stephan

Normally, undeploy is expected to fail if the application is not deployed yet; as a result the behavior in Tomcat is not the correct one and the one on JBoss is correct.

If you wish, we could an option so that the undeploy action would ignore failures.

Cheers

Show
Savas Ali Tokmen added a comment - Hi Stephan Normally, undeploy is expected to fail if the application is not deployed yet; as a result the behavior in Tomcat is not the correct one and the one on JBoss is correct. If you wish, we could an option so that the undeploy action would ignore failures. Cheers
Hide
Permalink
Stephan Lau added a comment -

Hi Savas

So the cat is the one with the bad behavoir. Now everything is clear.
The "ignore-failure-option" would be great.

Best regards

Show
Stephan Lau added a comment - Hi Savas So the cat is the one with the bad behavoir. Now everything is clear. The "ignore-failure-option" would be great. Best regards
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Stephan

I have just commited revision 3285. You can try version 1.2.2-SNAPSHOT; instructions on http://cargo.codehaus.org/Maven2+Plugin+Installation#Maven2PluginInstallation-snapshots

This revision introduces the following change: if the deployable has a timeout set, then the deploy as well as undeploy calls will:

  • If the deploy/undeploy call fails, simply log it
  • Look for the timeout URL to detect when deployment/undeployment completes

This has the advantage that "real" undeployment issues will not be ignored; as the watchdog will see that the application is still accessible after undeploy.

To set the deployable timeout, please read: http://cargo.codehaus.org/Deploying+to+a+running+container or the example in http://cargo.codehaus.org/Starting+and+stopping+a+container#Startingandstoppingacontainer-autodeploy

Let me know if this helps.

Thank you

Show
Savas Ali Tokmen added a comment - Hi Stephan I have just commited revision 3285. You can try version 1.2.2-SNAPSHOT; instructions on http://cargo.codehaus.org/Maven2+Plugin+Installation#Maven2PluginInstallation-snapshots This revision introduces the following change: if the deployable has a timeout set, then the deploy as well as undeploy calls will: If the deploy/undeploy call fails, simply log it Look for the timeout URL to detect when deployment/undeployment completes This has the advantage that "real" undeployment issues will not be ignored; as the watchdog will see that the application is still accessible after undeploy. To set the deployable timeout, please read: http://cargo.codehaus.org/Deploying+to+a+running+container or the example in http://cargo.codehaus.org/Starting+and+stopping+a+container#Startingandstoppingacontainer-autodeploy Let me know if this helps. Thank you
Hide
Permalink
Savas Ali Tokmen added a comment -

Closing, in the absence of response.

Show
Savas Ali Tokmen added a comment - Closing, in the absence of response.
Hide
Permalink
Savas Ali Tokmen added a comment -

Also updated http://cargo.codehaus.org/Deploying+to+a+running+container accordingly, with the usage guide.

Show
Savas Ali Tokmen added a comment - Also updated http://cargo.codehaus.org/Deploying+to+a+running+container accordingly, with the usage guide.

People

  • Assignee:
    Savas Ali Tokmen
    Reporter:
    Stephan Lau
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: