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

NumberFormatException when parsing deploy url

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After Updating deploy to container plugin from 1.13 to 1.14 I got a NumberFormatException parsing the deploy URL "http://localhost:28080".

      The Errormessage was:
      01:01:53 [DeployPublisher][INFO] Attempting to deploy 2 war file(s)01:01:54 ERROR: Step ‘Deploy war/ear to a container’ aborted due to exception: 01:01:54 java.lang.NumberFormatException: For input string: "28080null"01:01:54 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)01:01:54 at java.lang.Integer.parseInt(Integer.java:580)01:01:54 at java.lang.Integer.parseInt(Integer.java:615)01:01:54 at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:222)01:01:54 at java.net.URL.<init>(URL.java:622)01:01:54 Caused: java.net.MalformedURLException: For input string: "28080null"01:01:54 at java.net.URL.<init>(URL.java:627)01:01:54 at java.net.URL.<init>(URL.java:490)01:01:54 at java.net.URL.<init>(URL.java:439)01:01:54 at hudson.plugins.deploy.tomcat.TomcatAdapter.configure(TomcatAdapter.java:50)01:01:54 Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to sst-j-trunk*01:01:54* at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)01:01:54 at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)01:01:54 at hudson.remoting.Channel.call(Channel.java:957)01:01:54 at hudson.FilePath.act(FilePath.java:1072)01:01:54 at hudson.FilePath.act(FilePath.java:1061)01:01:54 at hudson.plugins.deploy.CargoContainerAdapter.redeployFile(CargoContainerAdapter.java:133)01:01:54 at hudson.plugins.deploy.PasswordProtectedAdapterCargo.redeployFile(PasswordProtectedAdapterCargo.java:95)01:01:54 at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:113)01:01:54 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:79)01:01:54 at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)01:01:54 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:741)01:01:54 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)01:01:54 at hudson.model.Build$BuildExecution.post2(Build.java:186)01:01:54 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)01:01:54 at hudson.model.Run.execute(Run.java:1840)01:01:54 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)01:01:54 at hudson.model.ResourceController.execute(ResourceController.java:97)01:01:54 at hudson.model.Executor.run(Executor.java:429)01:01:54 Caused: java.lang.AssertionError*01:01:54* at hudson.plugins.deploy.tomcat.TomcatAdapter.configure(TomcatAdapter.java:53)01:01:54 at hudson.plugins.deploy.CargoContainerAdapter.getContainer(CargoContainerAdapter.java:64)01:01:54 at hudson.plugins.deploy.CargoContainerAdapter$DeployCallable.invoke(CargoContainerAdapter.java:166)01:01:54 at hudson.plugins.deploy.CargoContainerAdapter$DeployCallable.invoke(CargoContainerAdapter.java:136)01:01:54 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3052)01:01:54 at hudson.remoting.UserRequest.perform(UserRequest.java:212)01:01:54 at hudson.remoting.UserRequest.perform(UserRequest.java:54)01:01:54 at hudson.remoting.Request$2.run(Request.java:369)01:01:54 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)01:01:54 at java.util.concurrent.FutureTask.run(FutureTask.java:266)01:01:54 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)01:01:54 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)01:01:54 at java.lang.Thread.run(Thread.java:748)01:01:54 Caused: java.io.IOException: Remote call on sst-j-trunk failed*01:01:54* at hudson.remoting.Channel.call(Channel.java:963)01:01:54 at hudson.FilePath.act(FilePath.java:1072)01:01:54 at hudson.FilePath.act(FilePath.java:1061)01:01:54 at hudson.plugins.deploy.CargoContainerAdapter.redeployFile(CargoContainerAdapter.java:133)01:01:54 at hudson.plugins.deploy.PasswordProtectedAdapterCargo.redeployFile(PasswordProtectedAdapterCargo.java:95)01:01:54 at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:113)01:01:54 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:79)01:01:54 at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)01:01:54 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:741)01:01:54 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)01:01:54 at hudson.model.Build$BuildExecution.post2(Build.java:186)01:01:54 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)01:01:54 at hudson.model.Run.execute(Run.java:1840)01:01:54 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)01:01:54 at hudson.model.ResourceController.execute(ResourceController.java:97)01:01:54 at hudson.model.Executor.run(Executor.java:429)01:01:54 Collecting metadata...01:01:54 Metadata collection done.

      I rolled back to version 1.13 of the plugin and everything went fine again.

        Attachments

          Activity

          Hide
          jansohn Robin Jansohn added a comment -

          Please provide your configuration so I can try to reproduce the problem.

          Show
          jansohn Robin Jansohn added a comment - Please provide your configuration so I can try to reproduce the problem.
          Hide
          rw250155 Reiner Wirtz added a comment -

          The error happens in all of my different test agents.
          That means: I have a jenkins master and at leat 17 slaves with different test environments.
          Every slave has two webapplication servers, one at port 8080 (jboss, wildfly) and one at port 28080 (apache-tomcat).
          The slaves are VMs with different operating systems (linux, windows, in different versions, different java versions, different wildfly versions, different tomcat versions).
          To deploy the needed applications to jboss or wildlfy, I use the commandline interface of the web application server.
          To deploy the needed application to apache-tomcat, I use the jenkins plugin "Deploy to container", which is used in a jenkins job,which will run locally on the slave machine. So the URL ist always the same "http://localhost:28080". In the definition of the jenkins job I selected the tomcat version "7.x" in the plugin for deploying.
          For authentification I have a user script inthe configuration of all the apache-tomcat activated.
          As long as I use plugin version 1.13 every thing went well.
          With plugin version 1.14 released on July, 24 I got the error listed in the description.

          Please, don't hesitate to conact me if I can give you more information.

          Show
          rw250155 Reiner Wirtz added a comment - The error happens in all of my different test agents. That means: I have a jenkins master and at leat 17 slaves with different test environments. Every slave has two webapplication servers, one at port 8080 (jboss, wildfly) and one at port 28080 (apache-tomcat). The slaves are VMs with different operating systems (linux, windows, in different versions, different java versions, different wildfly versions, different tomcat versions). To deploy the needed applications to jboss or wildlfy, I use the commandline interface of the web application server. To deploy the needed application to apache-tomcat, I use the jenkins plugin "Deploy to container", which is used in a jenkins job,which will run locally on the slave machine. So the URL ist always the same "http://localhost:28080". In the definition of the jenkins job I selected the tomcat version "7.x" in the plugin for deploying. For authentification I have a user script inthe configuration of all the apache-tomcat activated. As long as I use plugin version 1.13 every thing went well. With plugin version 1.14 released on July, 24 I got the error listed in the description. Please, don't hesitate to conact me if I can give you more information.
          Hide
          jansohn Robin Jansohn added a comment - - edited

          OK, I found out what is causing the problem. In freestyle jobs the configurations are not updated automatically and the newly introduced path variable is undefined and therefore null. As soon as the configuration is updated (it's enough to just press save without changes) the path variable is defined and everything works as expected.

          I just took over this plugin and I do not know if this kind of problem could have been prevented somehow. Oleg Nenashev Jesse Glick maybe you can tell us more about this?

          Show
          jansohn Robin Jansohn added a comment - - edited OK, I found out what is causing the problem. In freestyle jobs the configurations are not updated automatically and the newly introduced path variable is undefined and therefore null . As soon as the configuration is updated (it's enough to just press save without changes) the path variable is defined and everything works as expected. I just took over this plugin and I do not know if this kind of problem could have been prevented somehow. Oleg Nenashev Jesse Glick maybe you can tell us more about this?
          Hide
          jglick Jesse Glick added a comment -

          I am afraid I know very little about this plugin.

          Show
          jglick Jesse Glick added a comment - I am afraid I know very little about this plugin.
          Hide
          jansohn Robin Jansohn added a comment -

          Jesse Glick it's more of a general question regarding Jenkins plugins. Is there any best practice to introduce new plugin configuration variables (with a default value) without needing to manually refresh freestyle job configurations?

          Here's the actual commit and the line which caused the trouble because it was always null until the job configuration was updated to the new plugin version:
          https://github.com/jenkinsci/deploy-plugin/commit/db254d7c8c70214c7da91308c50bedb25fbf4eb8#diff-b2a541c8af2e6626b795634cc9d7143dR48

          Show
          jansohn Robin Jansohn added a comment - Jesse Glick it's more of a general question regarding Jenkins plugins. Is there any best practice to introduce new plugin configuration variables (with a default value) without needing to manually refresh freestyle job configurations? Here's the actual commit and the line which caused the trouble because it was always null until the job configuration was updated to the new plugin version: https://github.com/jenkinsci/deploy-plugin/commit/db254d7c8c70214c7da91308c50bedb25fbf4eb8#diff-b2a541c8af2e6626b795634cc9d7143dR48
          Hide
          rw250155 Reiner Wirtz added a comment -

          I did the update to version 1.14 again and followed the hints given by Robin Jansohn.
          I saved the job, which used the plugin without any changes.
          Now the deploy worked again.
          Thanks for the help!

          Show
          rw250155 Reiner Wirtz added a comment - I did the update to version 1.14 again and followed the hints given by Robin Jansohn. I saved the job, which used the plugin without any changes. Now the deploy worked again. Thanks for the help!
          Hide
          rw250155 Reiner Wirtz added a comment -

          If there is a new version available, please let me know.

          Show
          rw250155 Reiner Wirtz added a comment - If there is a new version available, please let me know.
          Hide
          jglick Jesse Glick added a comment -

          Is there any best practice to introduce new plugin configuration variables (with a default value) without needing to manually refresh freestyle job configurations?

          Yes. https://jenkins.io/doc/developer/persistence/

          Show
          jglick Jesse Glick added a comment - Is there any best practice to introduce new plugin configuration variables (with a default value) without needing to manually refresh freestyle job configurations? Yes. https://jenkins.io/doc/developer/persistence/
          Hide
          jansohn Robin Jansohn added a comment -

          Not sure I can follow. The introduced variable is a string and should be automatically serializable? Do you have an example where a new configuration option was introduced and did not require a manual refresh?

          Show
          jansohn Robin Jansohn added a comment - Not sure I can follow. The introduced variable is a string and should be automatically serializable? Do you have an example where a new configuration option was introduced and did not require a manual refresh?
          Hide
          jglick Jesse Glick added a comment -

          I probably do not know what you are really asking here. Best to ask on the dev list with a concrete example.

          Show
          jglick Jesse Glick added a comment - I probably do not know what you are really asking here. Best to ask on the dev list with a concrete example.
          Hide
          jansohn Robin Jansohn added a comment -

          I just released v1.15 which should solve this kind of problem. It will be available in Jenkins in the next few hours.

          Show
          jansohn Robin Jansohn added a comment - I just released v1.15 which should solve this kind of problem. It will be available in Jenkins in the next few hours.

            People

            Assignee:
            jansohn Robin Jansohn
            Reporter:
            rw250155 Reiner Wirtz
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: