I've got a Java Service Wrapper application that accesses registry entries. (Yeah, I know, weird, huh? In case you're wondering, I'm using David's solution to this question to read from the registry using Java.)
Everything works just fine on 32-bit versions of Windows. I can run my application from both the console (using the Java Service Wrapper's .bat file) and as a service installed from the bat file. I can see the various things I need from the Windows registry.
However, on a 64-bit Windows system, I can no longer see the registry entries I need when I run the application as a service; the entries all appear to be null. However, it still works in the console!
My hypothesis is that when run from the console (as an administrative user, in case it's relevant) the Java Service Wrapper starts a 64-bit JVM and is able to access the regular 64-bit registry. Then, when run as a service (via the LOCALSYSTEM user) it starts a 32-bit JVM (which would then try to access the oh-so-special 32-bit registry in the Wow6432bit node. The entries I'm looking for are absent from this node, which would then explain why I get null values for them in this case.
This leads to my question: why on Earth would the Java Service Wrapper start a 32-bit JVM when started via the services list, and why would it start a 64-bit JVM when started from the console?
NOTE: I'm using Java Service Wrapper 3.5.14 and in my config file I have
wrapper.java.additional.auto_bits=TRUE
Ideally, I'd like to keep the JVM selection automatic, so I can use one installer to deploy my software on both 32-bit and 64-bit systems. (This is one reason I chose to use JSW over Tomcat, in fact.)
Thanks so much for reading.