tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jäkel, Guido <G.Jae...@dnb.de>
Subject Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
Date Fri, 08 Mar 2019 09:06:18 GMT
Dear Mark Thomas, other developers and list members, 

caused by the requirement of an external software product, I currently have to upgrade a Tomcat-8.5
installation from Tomcat-8.5.23 to >=8.5.32 and therefore I concretely choose 8.5.38. As
I expect from a minor update, in the first moment this is a smooth thing. But surprisingly
I run in a very strange issue: There is -- at least for me -- a remarkable change in the behavior
of the handling of WAR deployments: If the deployment unit is a symbolic link, the new version
will not use anymore the "extension" of the name of the symbolic link to determine the "kind
of application" but will "resolve" the link(s) and use the tail of the name of the final destination
instead:

* If I a deployment is a file named 'foo.war', all works well as before and expected. 
* If it an symbolic link named 'foo.war' pointing to '[<anypath>/]bar.war', also all
works as before and expected (i.e. the root context name is 'foo')
* But now and in contrast to before: if the link destination don't have the extension '.war',
the deployment process will fail. 

From this, after establishing the link

	foo.war -> /some/fill/path/to/destination/bar.an_extension

for deployment, with the newer Tomcat version I get the error

	20190308-092433.557 ERROR [catalina-exec-38] [] [[/manager]] FAIL - Application at context
path [/foo] could not be started
	org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/foo]]
	        at org.apache.catalina.util.LifecycleBase.start(Unknown Source)
	        at org.apache.catalina.manager.ManagerServlet.start(Unknown Source)
	        at org.apache.catalina.manager.HTMLManagerServlet.start(Unknown Source)
	        at org.apache.catalina.manager.HTMLManagerServlet.doPost(Unknown Source)
	        at javax.servlet.http.HttpServlet.service(Unknown Source)
	        at javax.servlet.http.HttpServlet.service(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
	        at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
	        at org.apache.tomcat.websocket.server.WsFilter.doFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
	        at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
	        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
	        at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source)
	        at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source)
	        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown Source)
	        at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source)
	        at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source)
	        at org.apache.catalina.valves.RequestFilterValve.process(Unknown Source)
	        at org.apache.catalina.valves.RemoteAddrValve.invoke(Unknown Source)
	        at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Unknown Source)
	        at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source)
	        at org.apache.catalina.connector.CoyoteAdapter.service(Unknown Source)
	        at org.apache.coyote.http11.Http11Processor.service(Unknown Source)
	        at org.apache.coyote.AbstractProcessorLight.process(Unknown Source)
	        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(Unknown Source)
	        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(Unknown Source)
	        at org.apache.tomcat.util.net.SocketProcessorBase.run(Unknown Source)
	        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Unknown Source)
	        at java.lang.Thread.run(Thread.java:748)
	Caused by: org.apache.catalina.LifecycleException: Failed to start component [org.apache.catalina.webresources.StandardRoot@23279aae]
	        at org.apache.catalina.util.LifecycleBase.start(Unknown Source)
	        at org.apache.catalina.core.StandardContext.resourcesStart(Unknown Source)
	        at org.apache.catalina.core.StandardContext.startInternal(Unknown Source)
	        ... 36 more
	Caused by: java.lang.IllegalArgumentException: The main resource set specified [/some/fill/path/to/destination/bar.an_extension]
is not valid
	        at org.apache.catalina.webresources.StandardRoot.createMainResourceSet(Unknown Source)
	        at org.apache.catalina.webresources.StandardRoot.startInternal(Unknown Source)
	        ... 39 more
	
At this state, the Context is listed as '/foo' in the Tomcat Manager (with running=false)
and if I start it here, the Message is equivalent:

	FAIL - Application at context path [/foo] could not be started
	FAIL - Encountered exception [org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/foo]]]



Background: For more than ten years I'm using this mechanism of linking for deployments. I
have a shared filesystem resource with a "repository" holding all our application deployment
artefacts, structured by projects and named by internal names and versions. There's a Tomcat
farm with a couple of Tomcats in different stages. For deployment of a concrete version, this
is just linked on the webapp directory of a concrete virtual host on a concrete tomcat (in
fact: mostly two for failover redundancy) on a concrete stage and the link name is used to
define the context path (i.e. the visible URL) of the application.


With the new Tomcat version, this breaks because the names in the "repository" don't end with
'.war' and I don't want to change the whole internal deployment process including agreements
and script framework. Instead, please point me to the change in the source code that have
changed since 8.5.23 and is the root cause for this new behavior. Because I'm using Gentoo
and will build the Tomcat from the source, it's no big deal for me to patch the sources. But
I'm not familiar with the source code at all.

Thank you for support in advance

Guido
Mime
View raw message