I'm deploying an instance into Tomcat that has a third-level context path. Specifically, instead of something like /elda, the webapp is accessible at /third/level/elda. The quickest way to achieve this in Tomcat is to copy in the webapp not as elda.war, but as third#level#elda.war. To determine the context path, Tomcat replaces every hash with a slash.
Deploying this way breaks the Velocity error templates. Turning on debugging (adding log4j.logger.com.epimorphics.lda.renderers.velocity=DEBUG to log4j.properties) showed that the app looks for templates in:
file:/usr/share/tomcat/webapps/third%23level%23elda/_error_pages/velocity/
So %23 instead of each hash.
There are workarounds available:
- Create a symbolic link, e.g., /usr/share/tomcat/elda_error_pages pointing to the _error_path directory, and add a _velocityPath variable (set to /usr/share/tomcat/elda_error_pages/velocity) to every spec file.
- Don't deploy by relying on the naming convention of WAR files. Move the webapp out of Tomcat's webapp directory, rename it to something without hashes, and create a separate Tomcat context file conf/Catalina/localhost/third#level#elda.xml with docBase set to the renamed directory.
I have confirmed that both workarounds do work.
I'm deploying an instance into Tomcat that has a third-level context path. Specifically, instead of something like /elda, the webapp is accessible at /third/level/elda. The quickest way to achieve this in Tomcat is to copy in the webapp not as elda.war, but as third#level#elda.war. To determine the context path, Tomcat replaces every hash with a slash.
Deploying this way breaks the Velocity error templates. Turning on debugging (adding log4j.logger.com.epimorphics.lda.renderers.velocity=DEBUG to log4j.properties) showed that the app looks for templates in:
file:/usr/share/tomcat/webapps/third%23level%23elda/_error_pages/velocity/
So %23 instead of each hash.
There are workarounds available:
I have confirmed that both workarounds do work.