-
Bug
-
Resolution: Fixed
-
Minor
-
None
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.
[JENKINS-58667] NumberFormatException when parsing deploy url
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 jglick maybe you can tell us more about this?
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 jglick maybe you can tell us more about this? Robin Jansohn
added a comment - jglick 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
Robin Jansohn
added a comment - jglick 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 
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!
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! Reiner Wirtz
added a comment - If there is a new version available, please let me know. Is there any best practice to introduce new plugin configuration variables (with a default value) without needing to manually refresh freestyle job configurations?
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?
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? I probably do not know what you are really asking here. Best to ask on the dev list with a concrete example.
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.
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. 
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.