Cargo
  1. Cargo
  2. CARGO-1100

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

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: