Tomcat deployment failure
jenkins, maven, tomcat
Solution
I see that Hoaz suggested moving the deployment out of `C:\Program Files\` because of the space character. I wonder if it's rather a permissions issue than the space in the name?
Can you please also try these (without uninstalling the Tomcat from `C:\Program Files\`):
Configure the location of the temp directory to be outside `C:\Program Files\`
Reference : SO question How is the Tomcat temp directory location defined?
Change the location of `docBase` and/or `appBase`
Reference :Apache documentation http://tomcat.apache.org/tomcat-6.0-doc/config/host.html
Also, forcing the installation outside "C:\Program Files" would work fine unless / until someone insists that "That's where the Program Files should live, you know". :-)
Problem
The Issue I'm Having I've implemented a mild change to my application, and I checked it into the subversion repository. Once that was checked in, I ran a Jenkins build. Jenkins is currently running on a Windows server. The error I am receiving is the following: ``` org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:tomcat-maven-plugin:1.1:deploy (deploy) on project sd-rest-servlet: Cannot invoke Tomcat manager: FAIL - Deployed application at context path /sd but context failed to start ``` I investigated further into this error message, so I checked out the Tomcat logs on the Jenkins server, and I found an underlying issue: ``` SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base C:\Program Files\Apache Software Foundation\Tomcat 6.0\temp\28-sd does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4320) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4489) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:675) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:601) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:306) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1389) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1653) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1662) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1642) at java.lang.Thread.run(Unknown Source) ``` Now, as I understand it, the `temp` folder is only ever used in this way when I set `antiJarLocking` or `antiResourceLocking` to `true` in the `context` file. However, as you can see, I have not included this in the `Context` element: ``` <Context unpackWAR="false"> ``` Other Behaviour Unable to Undeploy After some close inspection, I've found that Jenkins isn't able to undeploy the application. In the logs, I see this message. ``` [INFO] Undeploying application at http://localhost:8082/sd [INFO] OK - Undeployed application at context path /sd ``` However, the build fails when it attempts to deploy, with the following error: ``` Cannot invoke Tomcat manager: FAIL - Application already exists at path /sd ``` Erratic access to the Temp directory I've also noticed that it throws the same `IllegalArgumentException` whenever it attempts to access any file inside the `temp` directory. This tells me there is something wrong with the `temp` directory, however I've set the permissions, and earlier on in the application, Jenkins actually puts a file in the `temp` directory. No Problems Depoying Jenkins actually deploys the application without a problem. I've watched the directories change when the files are added to them, including the `temp` directory. This tells me that Jenkins is randomly deciding it can't read the contents of the directory, despite the fact that it is added a file to it. It appears that it has write permissions, but not read permissions, which really doesn't make much sense! Attempts to Solve the problem Ensured the file exists I first attempted to look inside `C:\Program Files\Apache Software Foundation\Tomcat 6.0\temp\28-sd` to see if the file existed. Sure enough, it existed. Altered Permissions I've set permissions to allow for full access from every user on the server, as a precaution. Researched the use of the Temp directory I've attempted to configure my context file to avoid all use of the `temp` directory, so I don't have a clue why it's still attempting to read from it. I am inexperienced with the ins and outs of this technology, so I may still have some settings that require the `temp` folder. Edits Expanded Tomcat Logs ``` 18-Dec-2013 12:14:19 org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [/sd] 18-Dec-2013 12:16:06 org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor sd.xml 18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext resourcesStart <!-- Above stacktrace goes here --> 18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext start SEVERE: Error in resourceStart() 18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext start SEVERE: Error getConfigured 18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext start SEVERE: Context [/sd] startup failed due to previous errors 18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext stop INFO: Container org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/sd] has not been started ``` Some more information on the issue After reading through the logs for the thousandth time, I reread this line: `...Tomcat 6.0\temp\28-sd does not exist or is *not a readable directory*` So when I looked inside the `temp` directory again, I realized that the files being generated aren't `directories`. They are these weird file objects with no extension, and they look like this: For me, this indicates that something has gone wrong with the way Tomcat manipulates files and this is the core of the issue. I hope this extra information helps someone with the answer!