http://wrapper.tanukisoftware.org/doc/english/props-envvars.html
"When the Wrapper is run as a service, environment variables will be loaded from the system registry rather than from the environment. This was necessary because Windows loads the environment variables which are available to services when the machine is booted. Any changes to the system environment variables in the registry (set directly or through the system control panel) are not made available to the services until the machine is once again rebooted. By loading the environment variables from the registry, the reboot can be avoided while providing the same functionality."
I appreciate your trying to save us a reboot. But I'd rather have the environment that my service gets be consistent with the environment that other services get.
As bug 1702274 reports, there are issues with the PATH environment variable. Another problem is the TMP or TEMP environment variable. It seems that if obtained in the "traditional" way, the TEMP variable will use DOS 8.3 filenames:
TEMP=C:\DOCUME~1\sirianni\LOCALS~1\Temp
But the environment I get via java service wrapper has spaces:
TEMP=C:\Documents and Settings\sirianni\Local Settings\Temp
This is causing my application to break when run as a service.
I really just think you should go back to the standard way of letting windows pass the environment to the service process and not trying to do this registry workaround. It's just too dangerous to have different semantics and values for environment variables due to you loading them yourself instead of letting windows do it.
Logged In: YES
user_id=870348
Originator: NO
Hi,
I feel very strongly about this issue too. We've got a situation where important windows user profile environment variables like APPDATA keep getting lost on reboot which is causing lots of problems with our build scripts controller by the Pulse build server from Zutubi.
I don't want to have to worry about weird environment variable differences. I completely agree with the other poster.
James