wrapper.conf has "wrapper.working.dir" value to specify a working directory. It can have a relative or absolute value.
wrapper.working.dir=../bin
wrapper.working.dir=c:/tomcat6/bin
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:
catalina.base=C:\tomcat6
catalina.home=C:\tomcat6
java.home=C:\jre
java.io.tmpdir=C:\tomcat6\temp
user.dir=C:\tomcat6\bin
This is what Tomcat dispayes when run as service wrapper and "wrapper.working.dir=../bin" value:
java.io.tmpdir=..\temp
user.dir=..\bin
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:
c:/jre/bin/java.exe
c:/tomcat6/bin/startup.bat
c:/tomcat6/webapps/*
c:/tomcat6/temp/*
c:/tomcat6/NTService/ApacheTomcat.exe
c:/tomcat6/NTService/wrapper.dll
c:/tomcat6/NTService/wrapper.conf
Here is link to an original wrapper.working.dir request document and documentation:
https://sourceforge.net/tracker/index.php?func=detail&aid=738160&group_id=39428&atid=425190
http://wrapper.tanukisoftware.org/doc/english/prop-working-dir.html
I agree that this is a good idea. We will try to get it in in the near term.