By default, Windows Services run as the SYSTEM user. The problem is that the SYSTEM user does not have access to network resources. If your application is working fine when it runs as a service. Then the first thing to try is running your service as the user you were logged in as when running it as a console application.

To do this, first uninstall your application if it is currently installed as a Windows Service. Then edit the wrapper.conf file, setting the wrapper.ntservice.account and wrapper.ntservice.password properties. Next reinstall and start your service.

The service will now be running under the same environment as it was being run as a console application, so everything should now be working correctly. This issue is explained a bit in the following document: Accessing Network Drives Created in Services Under Windows NT

Depending on your security requirements, you may wish to create and configure a new user especially for the service.

I have found that on some systems, drives mapped to a drive letter (alphabet indicating a drive) are not always accessable on system restart until a real user actually logs on and connects to the drive. The workaround is to use the UNC syntax (full path including a machine name) to reference the drive directly rather than using the mapped drive letter.

//host/share/path

The Wrapper does not directly support executable jar files. But this is easily worked around.

The first step is to find out what class is actually being executed when the JVM runs the jar. To do this, you will need to expand the contents of the jar into a temp directory. A jar file is nothing more than a fancy ZIP file, so you can either use your favorite ZIP utility or the jar utility that comes with Java.

Inside the jar file, you will find the file, meta-inf/Manifest.mf. Opening this into an editor, reveals something like the following:

Manifest-Version: 1.0
Main-Class: com.myco.myapp.Main

Passing the -jar parameter and a jar file to Java simply causes it to read the above main class name and use it to run the application. So to get the Wrapper to launch the same application, all that needs to be done is to include the executable jar on the Wrapper classpath along with any other jars, and then follow the normal integration steps using the Main-Class as the application's main class.

When I request a thread dump by pressing CTRL-BREAK, CTRL-\, or via the API, I get the following message in the log and the JVM is restarted:

wrapper  | JVM exited unexpectedly.

Please make sure that you have not specified the -Xrs flag when launching the JVM. This flag is useful in some environments when using Java without the Wrapper. But it compromises the Wrapper's ability to respond to the the various system signals.

To tell the Wrapper and thus it's JVM to ignore system signals, use the wrapper.ignore_signals instead. Make sure you have read the document first.

Some users have reported problems when attempting to get their COM applications working with the Wrapper. The application will work fine as a standalone independently, but when run under the Wrapper errors like the following are thrown:

Caught java.lang.NullPointerException: name can't be null while loading driver com.sun.comm.Win32Driver

The COM API requires two files to be available: The win32com.dll file on the library path, and a javax.comm.properties file located in a lib subdirectory of the directory returned by System.getProperty("java.home").

Problems are caused if your wrapper.conf has configured that you use a different JVM than is specified by your JAVA_HOME environment variable. You can make sure you are using the correct JVM by specifying the following in your wrapper.conf file.

wrapper.java.command=%JAVA_HOME%/bin/java

The only difference between the way your application is running under the Wrapper and the way is was running before being integrated is that before your application's main method was being called directly by the JVM on startup. Now, assuming that you are using the WrapperSimpleApp or WrapperStartStopApp helper classes, the JVM first calls that class's main method, then after the Wrapper has initialized, it calls your application's main method.

This can cause some problems when a security manager is in use. The reason is that the Java security manager searches up the call stack to make sure that every class and method is authorized to call the protected code before granting access. If the Wrapper's classes exist in your call stack and they are not given privileges then you will get a security exception.

Try giving wrapper.jar permissions by adding the following to your policy file. This usually fixes this kind of problem.:

// Give Wrapper classes full permissions
grant codeBase "file:../lib/wrapper.jar" {
    permission java.security.AllPermission;
};

Some Java Service application have a problem with the Java process exiting whenever a user logs out under Windows. Wrapper has handled this correctly since its first release.

The Java side of the Wrapper requires a native library (wrapper.dll on Windows and libwrapper.so on Unix systems) to make this work. The native library is responsible for trapping all system signals sent to the JVM process and handling them correctly. A Java Application may handle these signals by implementing the controlEvent method in the WrapperListener interface.

If you are experiencing any problems with your JVM being restarted by the Wrapper when a user logs out, please verify that the library is being loaded. If it is not, then a warning message will be displayed in the JVM output during the WrapperManager initialization.

You can find examples of what happens the user logs out while Wrapper is being run as a console application and as a service in the Examples section of the documentation.

On Windows systems, the priority can be set by setting the wrapper.ntservice.process_priority property in the wrapper.conf file. Please the Configuration Overview for more details.

On Unix systems, the suggested method for setting the priority is to use the nice command in your shell scripts when launching the Wrapper. The example scripts shipped with the Wrapper show how to do this. See man nice or info nice for details about how to use nice.

By default, the Wrapper sets the JVM's user directory to the location of either the wrapper.exe file on Windows or Wrapper shell script on Unix systems. This is done to make it possible to reliably make use of relative paths within your application. Normally this would not be possible because the user directory would depend on where the JVM was launched from.

Relative paths make it extremely easy to install an application as it can usually be unzipped into any directory and run reliably.

There are some cases where it is necessary to set the user directory to a location other than the default. This is done by setting the wrapper.working.dir property.

NOTE

Important - Make sure that you have read over the documentation for the working directory property before playing with it. You will safe yourself some headaches.

When running several copies of the Wrapper under Windows, it is not easy to tell which application is which in the Task Manager because they all show up as wrapper.exe and java.exe.

If is not possible for the Wrapper to implement a feature to change this name because Windows does not allow that for security reasons.

The workaround is a bit of a hack. But it works great. Rename the wrapper.exe file to wrapper-myapp.exe. Then modify the batch files so they use this new wrapper-myapp.exe. For the Java process, you have to do the same thing. Go into the %JAVA_HOME%/bin directory and simply copy java.exe to java-myapp.exe. Then modify the wrapper.conf file so that new java-myapp.exe is used.

Now when you look at your Windows Task Manager, it will be easy to tell which exe is which.

Note, you can also set the wrapper.pidfile and wrapper.java.pidfile properties in the wrapper.conf file. These will create files containing the pids. These pids can then be compared with those shown in the Task Manager. Note that you need to configure the Task Manager to display process pids.

Just thought this will be helpful for those who want to get wrapper services to work with java comm api.

Apart from using the above configuration given in the FAQ related to comm api issues, i had to add the 'libSolarisSerialParallel.so' to the java libarary path given below property in wrapper.conf file.

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../jswrapper/lib

Now it works like charm.Please not that 'jswrapper/lib' is something that is in my project but you can set it to what you want it to be.

Thanks