wrapper.conf has "wrapper.working.dir" value to specify a working directory. It can have a relative or absolute value.
I have found one use-case where relative path gives a side effect. One webapp was expecting to see JVM folder system variable (user.dir, java.home etc...) as an absolute value which is a default if JVM is run java.exe user-level program.
This is tomcat6/bin/startup.bat user-level process settings JVM is using:
This is what Tomcat dispayes when run as service wrapper and "wrapper.working.dir=../bin" value:
Problem is some webapps expect to see an absolute filepath JVM system variables but may fail if value is a relative one. Apps should use File.getAbsolute() java methods but some does not expect to get relative value anyway so entirely skip it. These apps most like fails to IOExceptions.
Would be nice to have "wrapper.working.dir.normalize=true" attribute, then wrapper.exe normalized value to an absolute path and even better normalized ".." steps from the full path. All problems solved user-level and ntservice mode would see identical system variables.
../bin -> c:/tomcat6/bin
This is my folder structure where previous examples point to:
Here is link to an original wrapper.working.dir request document and documentation:
Log in to post a comment.