| Summary: | Tomcat auto deployer not working for ROOT applications | ||
|---|---|---|---|
| Product: | Tomcat 7 | Reporter: | Jesse Barnum <jsb_apache> |
| Component: | Manager | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | ||
| Priority: | P2 | ||
| Version: | 7.0.47 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: | catalina and localhost logs | ||
> When I do exactly the same thing as #1 (tomcat auto deploy) > but just change the 'path' variable from /360Store to /ROOT "ROOT" is base file name for the default webapp. Its context path is "" (an empty string), it is not "/ROOT", see [1]. What if you specify path="" or path="/" ? [1] http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming [2] http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Deploy_A_New_Application_Remotely Thank you Konstantin, this did fix the problem! One request - could the error reporting be improved? Maybe in the log file it could have a line stating something like 'ROOT is not a valid contact path'? Using the name /ROOT did work in Tomcat 6 - which is what I was migrating from. I expect that others who are moving from Tomcat 6 to a later version might make the same mistake. This has been fixed in 8.0.x for 8.0.0 onwards. Note that in Tomcat 8, attempting to deploy to /ROOT deploys the WAR as the ROOT web application but reports that the deployment has failed. After this fix the deployment is still to the ROOT web application but the deployer now reports a successful deployment to "/". Also note that the automatic deployment improvements back-ported to 7.0.x for 7.0.50 may have changed the behaviour for 7.0.x. The behaviour had indeed changed in 7.0.50. I have applied the fix from 8.0.x to 7.0.x and this will be included in 7.0.51 onwards. Thank you Mark!! |
Created attachment 31162 [details] catalina and localhost logs I am trying to deploy a web app as the ROOT application for Tomcat 7, running on Ubuntu 12 with Amazon EC2. I experienced the problem with 7.0.35, 7.0.42, and 7.0.49. 1) When I use auto-deploy using the Tomcat Deployer 'deploy' ant task to a non-ROOT context name, such as /360Site, everything works as expected - war file is uploaded, decompressed to directory, and is immediately available. 2) When I use the manager HTML interface to upload the ROOT.war file by clicking the 'Select WAR file to upload' and then clicking 'deploy', everything works as expected. However, 3) When I do exactly the same thing as #1 (tomcat auto deploy) but just change the 'path' variable from /360Store to /ROOT, here is what happens: * WAR file appears in the webapps directory, but does not get expanded. * The webapp is not running (I get a blank page when I go to the URL in the browser) * I see these entries in the catalina.<date>.log (after doing the auto-deploy: Dec 27, 2013 3:34:03 PM org.apache.catalina.startup.HostConfig deleteRedeployResources INFO: Undeploying context [] Dec 27, 2013 3:34:03 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. Dec 27, 2013 3:34:03 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war Dec 27, 2013 3:34:04 PM org.apache.catalina.startup.ContextConfig init SEVERE: Exception fixing docBase for context [] java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:215) at java.util.zip.ZipFile.<init>(ZipFile.java:145) at java.util.jar.JarFile.<init>(JarFile.java:153) at java.util.jar.JarFile.<init>(JarFile.java:90) at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:88) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:113) at org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:722) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:843) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:387) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:983) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1660) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Dec 27, 2013 3:34:04 PM org.apache.catalina.core.StandardContext resourcesStart SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:138) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:5055) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5235) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:983) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1660) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Dec 27, 2013 3:34:04 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error in resourceStart() Dec 27, 2013 3:34:04 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error getConfigured Dec 27, 2013 3:34:04 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [] startup failed due to previous errors Dec 27, 2013 3:34:14 PM org.apache.catalina.startup.HostConfig deleteRedeployResources INFO: Undeploying context [] Dec 27, 2013 3:34:14 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war Dec 27, 2013 3:34:14 PM org.apache.catalina.startup.ContextConfig init SEVERE: Exception fixing docBase for context [] java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:215) at java.util.zip.ZipFile.<init>(ZipFile.java:145) at java.util.jar.JarFile.<init>(JarFile.java:153) at java.util.jar.JarFile.<init>(JarFile.java:90) at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:88) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:113) at org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:722) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:843) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:387) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:983) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1660) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Dec 27, 2013 3:34:14 PM org.apache.catalina.core.StandardContext resourcesStart SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:138) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:5055) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5235) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:983) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1660) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Dec 27, 2013 3:34:14 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error in resourceStart() Dec 27, 2013 3:34:14 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error getConfigured Dec 27, 2013 3:34:14 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [] startup failed due to previous errors Dec 27, 2013 3:34:21 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war Dec 27, 2013 3:34:21 PM org.apache.catalina.startup.HostConfig deployWAR SEVERE: Error deploying web application archive /var/lib/tomcat7/webapps/ROOT.war java.lang.IllegalArgumentException: addChild: Child name '' is not unique at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:887) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:983) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:548) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1468) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1447) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:679) at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:437) at javax.servlet.http.HttpServlet.service(HttpServlet.java:650) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) * After the auto-deploy fails, I can go into the HTML manager page and click the 'start' button, and the webapp does successfully start (tested the URL in the browser), but the WAR file still does not get unpacked into a directory. Doing the exact same thing to a different server running Tomcat 6.0.24 works correctly as expected. Any ideas here? Here is what I've ruled out so far: * I don't think it's a file permission issue (tomcat7 is the owner of the webapps directory, and everything works fine when run through the manager HTML interface). * The "Child name '' is not unique" sounded promising, but I could not find any duplicate ROOT webapps - there is no ROOT.war file or directory in the webapps directory prior to running the auto-deploy; there is no ROOT.xml file in the conf/Catalina/localhost directory, nor are there any context elements defined in the server.xml file. * I don't think that the .war file is corrupt - I can manually unzip the .war file in the webapps from the command line using the 'unzip' command, and as I pointed out in #2 above, everything works fine when it is uploaded using the manager HTML interface. If it would help to spin up a temporary new Ubuntu deployment and provide credentials to reproduce the problem, I'd be happy to do that.