Re: [Wrapper-user] wrapper.on_exit seems not to work in 3.2.0

[Leif M. <le...@ta...>]

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.