|
From: Leif M. <le...@ta...> - 2006-06-19 07:25:15
|
Andreas,
Sorry. That is a known bug in 3.2.0 that has been fixed in CVS. It
will be in the 3.2.1
release. I need to hurry up and get that out the door.
Here is the current list of changes for the 3.2.1 release:
Cheers,
Leif
Java Service Wrapper Revision History.
--------------------------------------
3.2.1
* Fix a problem with the solaris-sparc-64 makefile.
* Add a solaris-x86-64 makefile.
* Merge in a patch by Hugo Weber to make it possible to configure the
Wrapper
to pull the JRE from the system registry on windows.
* Fix a batch file bug added in 3.2.0 where the scripts would not function
correctly if the full path to the batch file contained spaces.
Bug #1450601.
* Modify the message shown when a native library fails to load so the
exception message text is now shown in the log without having to enable
debug log output.
* Modify the UNIX shell script to be more informative if the script is
unable
to locate a wrapper binary due to a executable bit permission problem.
* Fix a minor permission problem with the build for the delta-pack.
* Commit a patch by Juergen Hermann to make the error shown when realpath
fails clearer.
* Add the ability to use a default wrapper.conf file that is in the same
directory as the wrapper binary. The file will be named based on the
name of the wrapper binary.
* Synchronize the command line so that both the Windows and UNIX versions
are now the same. The old command line syntaxes are now supported
everywhere so there will be no compatibility problems.
* It is no longer possible to specify arguments using the '/c' syntax.
This was undocumented so hopefully it is not being used. The documented
'-c' syntax must now be used. The change was necessary to synchronize
the command line between UNIX and windows platforms.
* The 32-bit HP-UX 3.2.0 build was generating a libwrapper.so file rather
than libwrapper.sl.
* Make the WrapperManager.setConsoleTitle, getWrapperPID, and getJavaPID
methods available through JMX.
* Fix a state engine problem introduced in 3.2.0 which was causing the
wrapper.on_exit.<n> properties to be ignored in most cases.
* Fix a potential problem that could have caused crashes when debug logging
was enabled.
* Fix a problem where signals were not being handled correctly on some UNIX
platforms, including AIX. This was making it impossible to shutdown the
wrapper cleanly with the TERM signal. Bug #1477619.
* Add new default environment variables which can be referenced in a
configuration file to configure platform specific directories and file
names. WRAPPER_OS, WRAPPER_ARCH, and WRAPPER_BITS.
* Add a -v argument to make it possible to request the version from a
wrapper
binary.
* Add support for registering the WrapperManager MBean with the
PlatformMBeanServer when run on a 1.5+ JVM. See the JMX section in the
documentation for details.
* Rework the way timeout properties are handled. Values of 0 now actually
disable the timeouts rather than setting them to a large value. To avoid
overflow problems when converting to internal timer ticks, timeouts
are now
restricted to a maximum of 20 days, or 1728000 seconds. Change
affects the
wrapper.cpu.timeout, wrapper.startup.timeout, wrapper.ping.timeout,
wrapper.shutdown.timeout, and wrapper.jvm_exit.timeout properties. For
values less than 20 days, there should be no change in functionality.
* Add support for debuggers. The Wrapper will now show a warning on startup
and then again the first time a timeout occurs. But all timeouts will be
ignored. This is to avoid problems with the Wrapper restarting a
suspended
JVM in the middle of a debugging session. The wrapper enters this mode if
the wrapper.java.command ends with the string "jdb" or "jdb.exe", or the
"-Xdebug" parameter is passed to the JVM.
* Add 'athlon' to the list of supported architectures.
* Fix a problem where the environment variables loaded when a service was
started were always the system environment even if the service was running
as a specific account. The environment of a specific account will now be
loaded on top of the system environment if the USERNAME environment
variable is set by the system. Bug #1491138.
|