Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19564

deploy plugin - issue with tomcat 7 context path using parallel deployment

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: deploy-plugin
    • Labels:
    • Environment:
      Tomcat 7.0.34
      Jenkins 1.530
      deploy plugin 1.9
    • Similar Issues:

      Description

      I would like to take advantage of Tomcat 7 parallel deployment feature and I generated my app with the following name:

      myapp##1.0.0.war

      Deploying it manually copying it in tomcat webapps work as expected, unzipping it in myapp##1.0.0 folder and running the app with context path "myapp".

      Deploying with Jenkins, I'm not able to configure deploy plugin in order to perform the deployment without the context path. In fact:

      • If I put the context path "myapp" in the settings of the job, the WAR is copied in tomcat webapps with name myapp.war and I loose the parallel deployment benefits.
      • if I leave the context path blank in the job settings the war is copied with the proper name myapp##1.0.0.war but I get the following error on tomcat logs:
      Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Failed to deploy application at context path /myapp//1.0.0
      

      Is there any solution/workaround?

      Many thanks in advance for your help, best regards

        Attachments

          Activity

          Hide
          djl2 Darrell Lowrance added a comment -

          I'm having this exact same problem. Was a workaround ever found?

          Show
          djl2 Darrell Lowrance added a comment - I'm having this exact same problem. Was a workaround ever found?
          Hide
          mdeggers Mark Eggers added a comment -

          Jenkins 1.574 / Tomcat 7.0.55 / JRE 1.7.0_60 / Deployer 1.10

          I think this is a more subtle issue may actually be a Cargo issue (haven't checked the bugs there).

          I was able to deploy a WAR file with the name appName##NN.war (where NN is constructed from the BUILD_NUMBER) once. I accomplished this by using the following Ant glob pattern for the WAR/EAR file:

          */.war

          I left the context path blank, and I made sure to not include a context.xml with a path attribute.

          However, the second attempt (the actual parallel deployment) failed with:

          ERROR: Publisher hudson.plugins.deploy.DeployPublisher
          aborted due to exception
          org.codehaus.cargo.container.ContainerException:
          Failed to undeploy /home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##14.war

          Once I undeployed the application from the remote Tomcat, I could then successfully run another Maven deploy job, which incremented the BUILD_NUMBER.

          I can post the entire stack trace if needed.

          First of all, the entire point of doing a parallel deploy is to avoid undeploying a live application.

          Second of all, the undeploy command needs to be instrumented in order to handle versions (/manager/text/undeploy?context=ConsumeIt&version=14)

          While Cargo's performUndeploy for Tomcat7x overrides the stock method, the Javadoc doesn't mention versions.

          getPath and getVersion explicitly mention version support.

          My initial reaction is that the Tomcat7xRemoteDeployer Cargo class needs to recognize that it's dealing with a versioned WAR file and not attempt to undeploy.

          For the undeploy command, there needs to be an optional version component.

          It appears that Tomcat8xRemoteDeployer suffers from the same issue.

          Show
          mdeggers Mark Eggers added a comment - Jenkins 1.574 / Tomcat 7.0.55 / JRE 1.7.0_60 / Deployer 1.10 I think this is a more subtle issue may actually be a Cargo issue (haven't checked the bugs there). I was able to deploy a WAR file with the name appName##NN.war (where NN is constructed from the BUILD_NUMBER) once. I accomplished this by using the following Ant glob pattern for the WAR/EAR file: * / .war I left the context path blank, and I made sure to not include a context.xml with a path attribute. However, the second attempt (the actual parallel deployment) failed with: ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception org.codehaus.cargo.container.ContainerException: Failed to undeploy /home/tcadmin/.jenkins/jobs/ConsumeIT-Deploy/workspace/target/ConsumeIt##14.war Once I undeployed the application from the remote Tomcat, I could then successfully run another Maven deploy job, which incremented the BUILD_NUMBER. I can post the entire stack trace if needed. First of all, the entire point of doing a parallel deploy is to avoid undeploying a live application. Second of all, the undeploy command needs to be instrumented in order to handle versions (/manager/text/undeploy?context=ConsumeIt&version=14) While Cargo's performUndeploy for Tomcat7x overrides the stock method, the Javadoc doesn't mention versions. getPath and getVersion explicitly mention version support. My initial reaction is that the Tomcat7xRemoteDeployer Cargo class needs to recognize that it's dealing with a versioned WAR file and not attempt to undeploy. For the undeploy command, there needs to be an optional version component. It appears that Tomcat8xRemoteDeployer suffers from the same issue.
          Hide
          kaosko kaosko added a comment -

          Looks like the issue is fixed in a newer version of Cargo (see https://codehaus-cargo.atlassian.net/browse/CARGO-1041), but the plugin would need be updated.

          Show
          kaosko kaosko added a comment - Looks like the issue is fixed in a newer version of Cargo (see https://codehaus-cargo.atlassian.net/browse/CARGO-1041 ), but the plugin would need be updated.
          Hide
          jansohn Robin Jansohn added a comment -

          this should be fixed since v1.10

          Show
          jansohn Robin Jansohn added a comment - this should be fixed since v1.10

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            mottam76 Marco Motta
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: