Trouble with Java Service Wrapper when run from console vs. run as a service

Question

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.

Answer 1

It turns out that my installer (which I was using to install and start the service) is a 32-bit application, which causes the Java Service Wrapper .bat files to run in a 32-bit environment during the install process. Since there's no 32-bit Java on the 64-bit system, this means that the wrapper can't find Java.

The trick (which I learned from the helpful folks at Tanuki Software's support) is to tell the .bat file to run the 64-bit wrapper if it's known that we're running in a 32-bit environment on a 64-bit system.

Basically, in the .bat file, find these lines and insert the indicated line. If I encounter further problems, I'll update my answer. But for now, this solution seems to work well for me quite nicely.

rem
rem Decide on the specific Wrapper binary to use (See delta-pack)
rem
if "%PROCESSOR_ARCHITEW6432%"=="AMD64" goto amd64 (<---- insert this line)
if "%PROCESSOR_ARCHITECTURE%"=="AMD64" goto amd64
if "%PROCESSOR_ARCHITECTURE%"=="IA64" goto ia64