 |
 |
By default, NT 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 run 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 an NT 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 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 to reference
the drive directly rather than using the mapped drive letter.
|
 |
 |
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 hitting 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 docs first.
|
 |
 |
Some users have reported problems when attempting to get their COMM
applications working with the Wrapper. The application will work fine
standalone, 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 COMM 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:
// Give Wrapper classes full permissions
grant codeBase "file:../lib/wrapper.jar" {
permission java.security.AllPermission;
};
|
This usually fixes this kind of problem.
|
 |
 |
Some Java Service application have a problem with the Java process exiting whenever a
user logs out under Windows. Several people have asked about whether or not the
Wrapper handles this. The answer is that the Wrapper has handled this correctly since
its first release.
The Java side of the Wrapper requires a native library to make this work. (Wrapper.DLL
on Windows and libwrapper.so on Unix systems.) 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 provided with the Wrapper distribution 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 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 dir
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.dir to a location
other than the default. This is done by setting the
wrapper.working.dir property.
Important - Make sure that you have read over the documentation for the
working dir 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 Wrpaper 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.
|
|