What's new in Java Service Wrapper Professional Edition 3.5.25

Jun 16, 2014
  • Improve the wrapper.timer..interval property so it is now possible to specify ranges and lists of values as well as offsets for interval values to more precisely control when timers are fired.
  • Fix a problem with the wrapper.timer..interval property where timers would not fire during an interval the system time was set back. Also fixed a problem where timers would stop firing permanently if the system time was set forward by more than the value of the wrapper.timer.max_catchup property and a timer had been scheduled to be fired during that interval. Both of these issues were most likely during daylight savings time.
  • Fix a problem where signals received by the JVM were not being logged in debug output correctly if the wrapper.ignore_signals property is set to true. We now also log debug output even if a user event listener consumes the signal event.
  • Fix a problem on Gentoo Linux where the shell script was not correctly detecting the system architecture. This may also be a problem on other distributions whose 'uname -p' returns a detailed architecture.
  • In the shell script, when the flag to use systemd (USE_SYSTEMD) is set, the shell script generates a ".service" file in /etc/systemd/system/ when installing the Wrapper as a daemon.
  • In the shell script, add a function to validate the size of APP_NAME when installing or removing the daemon on AIX.
  • It was possible to disable the logging of the Java command line even when debug output was enabled by setting the wrapper.java.command.loglevel property to NONE. This made it difficult to debug problems and is no longer possible.
  • When the wrapper.java.version.output property is set to true, add debug log output to show the actual command line used.
  • Fix a problem on Windows when the wrapper.java.version.output property is true where it was possible that java executable being run to get the version could be different than that used to run the application if the java executable was being located on the default system PATH as well as the PATH defined in the environment. The Wrapper now looks once and uses the same fully resolved path in both places. For clarity, both java command lines are now included in debug log output when the version is requested. (Bug #288)
  • Change the timing of the logging of the Java command line on UNIX so it is consistent with Windows.
  • Improve the error message text thrown when a native feature is not available from Java to be more clear about whether the problem is that the native library could not be loaded versus the wrong edition being used.
  • On Windows, detect when the Wrapper is running under Cygwin and set the default value for wrapper.console.flush to TRUE. On other platforms, the script will display a message and stop running.
  • Add support for WRAPPER_EVENT_TIME_* and WRAPPER_EVENT_RAND_* variable references so event times can be used when events are fired.
  • Fix a buffer overflow problem on AIX which caused crashes or deadlocks on startup for some users. This had been an issue since 3.5.0 but only reported recently.
  • Remove output debug messages on UNIX when the wrapper.port.address property was set.
  • Clean up code when converting multibyte characters to wide characters. Some error checks were not implemented correctly. Found during a code review and is not known to have actually caused any problems.

New in Java Service Wrapper Professional Edition 3.5.24 (Jan 9, 2014)

  • Fix a problem where the message source of remote syslog messages from the JVM were being logged as "jvm %d" rather than "jvm 1".
  • Add a new wrapper.syslog.split_messages property which controls whether or not multi-line messages will be logged as is or first split into individual lines.
  • Fix a problem on Windows Vista and above where the wrapper.single_invocation property was not correctly identifying Wrapper instances running in different sessions under some circumstances.

New in Java Service Wrapper Professional Edition 3.5.20 Testing (Jul 4, 2013)

  • Further improvements to the memory footprint of the Wrapper to minimize the memory required when logging JVM output consisting of very long lines.
  • Fix a minor potential buffer overflow, which could occur if the path of the first classpath element is larger than 1024 characters. This overflow was detected during a code review and we have no reports that it actually ever caused any problems.
  • Improve the error message displayed when the Wrapper's configuration file could not be loaded so that it now includes the name of the file.
  • Work around a libc system library bug on some HPUX platforms in which calls to vswprintf can cause a crash if the expanded string does not fit into the buffer. Worked around the problem with the help of HP support by making sure the buffer length followed a rule so that its length was 1+N where N is a multiple of 8.
  • Fix a problem on HPUX platforms where the JVM would sometimes get stuck on shutdown, when the shutdown was initiated within the JVM, leading to the Wrapper having to forcibly kill it. This was caused by the Wrapper attempting to close the backend socket when another read was blocking attempting to read from the same socket. This was introduced in version 3.5.8.
  • Fix a potential log corruption when queued log messages were larger than the internal buffer size. Found during a code review and is not known to have actually caused any problems.
  • Fix a typo in the shell script which was breaking the 'install' command on Solaris platforms.
  • Fix a potential crash on HPUX platforms if the value of the wrapper.port.address property had an encoding problem.

New in Java Service Wrapper Professional Edition 3.5.18 Testing (Apr 19, 2013)

  • Fix a problem, where an unclosed percentage character '%' was opening the chance of a dangling pointer in the additional java parameters. The '%' character is a special character, specifying an environment variable.
  • Added variable _WRAPPER_DIR the batch files to make it possible to specify any other directory where the Wrapper binary file is located. Until now the batch file and exe file had to be in the same location.
  • Added property wrapper.port.address, which makes it possible to specify a different address to bind the socket to when using the socket backend connection between the Wrapper and the JVM. Until now, the socket was always bound to the localhost loopback interface.
  • Whenever the Wrapper is causing the JVM to be forcibly terminated, the Wrapper will make sure the JVM has actually been terminated. If it wasn't after wrapper.jvm_terminate.timeout seconds, a pending restart will be canceled and the Wrapper exit.
  • Reworked the way the Wrapper is processing output from the JVM, in order to increase performance on huge output on a single line and also reduce memory usage.

New in Java Service Wrapper Professional Edition 3.5.17 (Apr 19, 2013)

  • Add a new wrapper.java.additional.default.stripquotes property to make it possible to specify the default value of the wrapper.java.additional..stripquotes property.
  • Fix a bug where the timer failed to calculate the fire time when that time was more than one week in the future. This was possible for weekly timers which spanned a daylight savings time change which rolled the time back by an hour in the fall.
  • Fix problem in the shell script, where it might fail to remove an installed daemon after the location of the script has been changed. Thanks to Leo.
  • Add additional advice messages when a Windows service fails to be started due to file access problems involving the Wrapper binary, configuration, or log files.
  • Fix a problem where the dynamic library on MacOSX was not able to load it's functions. Affected version were all MacOSX versions of the 3.5.16 series.
  • Added wrapper.app.parameter_file property, which works similar to the wrapper.java.additional_file property
  • Reduce CPU-consuption of WrapperProcess.waitFor() function.

New in Java Service Wrapper Professional Edition 3.5.16 Testing (Nov 28, 2012)

  • Include information about the base configuration file in the debug output when debugging of cascading configuration files has been enabled.
  • Add a check in the UNIX script to output a more descriptive error message, when the user specified in the RUN_AS_USER variable doesn't exist.
  • Modify the way the the wrapper.ntservice.generate_console property works so it is now easier to disable the generation of the console using just this property.
  • Improve the message logged when the the Wrapper attempts to perform a thread dump without a valid console being available.
  • Add new wrapper.ping.alert.threshold and wrapper.ping.alert.loglevel properties which make it much easier to debug ping timeout issues by asking the Wrapper to log messages about ping responses which were shorter than the registered wrapper.ping.timeout, but longer than the threshold.
  • Add a new WrapperManager.appearSlow method which makes it easier to test how the Wrapper behaves when the JVM is being slow to respond to commands.
  • Add a new wrapper.disable_tests property which can be used to disable all of the testing methods of the WrapperManager class. It has always been possible to control their access with a SecurityManager, but this is simpler for most applications.
  • Update the default wrapper configuration file template so a restart due to a matched OutOfMemoryError filter will no longer be triggered by default if the user enables -verbose:class output.
  • Rework the internal flags governing the generation and hiding of the backend console on Windows so we are able to almost always obtain the console's window handle.
  • Cleanup some startup code to reduce duplication and make sure that more debug and warning messages are logged after the "Wrapper Started" message.
  • Add a new wrapper.java.additional_file property to make it possible to specify JVM parameters in a file.
  • Re-Enabled the forced reloading of the SYSTEM (and if set to a specific account, the user) registry before launching the Wrapper as a service on Windows XP and 2003. This has been originally disabled for Windows XP and 2003 since version 3.5.5.
  • Fix a problem where the source code values returned by the WrapperServiceActionEvent.getSourceCode() method were incorrect. The constant values were incorrect and have been corrected from this release.
  • Add new WrapperServiceActionEvent.getSourceCodeName() and WrapperServiceActionEvent.getSourceCodeName(int actionSourceCode) methods which returns a localized name of the source where the event originated.
  • Fix a minor problem where a couple uncommon backend packet codes were not being correctly identified by name in the debug log output. Functionally they were all working correctly.
  • Added property wrapper.ping.timeout.action , which will let you specify an action in case the timeout triggers. So far the only action was to restart the JVM.
  • Retry failed share mappings if the target host or network is unreachable as that may be a temporary problem.
  • There was a problem where the IO-redirection of a child process which got created with the WrapperManager.exec API and used the feature to run the child process in the logged on users desktop was only allowing to create a process once per second.
  • Fix a problem where console log output was not being displayed correctly when running with the WrapperW.exe binary with the wrapper.ntservice.console property was set to true.
  • Implement the wrapper.ntservice.generate_console property when using the WrapperW.exe binary so it is now possible to disable the creation of the hidden console.
  • Fix a problem where the instance class names logged when a deadlock involving ReentrantLock instances were corrupted. The actual deadlock detection was working correctly, but this could have lead to other problems caused by the corruption. A workaround was to set the wrapper.check.deadlock.output property to SIMPLE.
  • Make it possible to completely disable the details of a deadlock by setting the wrapper.check.deadlock.output property to NONE.
  • Object Ids in thread dump reports were not correctly being logged as 64-bit ids on 64-bit JVMs in some cases.

New in Java Service Wrapper Professional Edition 3.5.15 (Jul 18, 2012)

  • Add a new _WRAPPER_CONF_OVERRIDE setting to the Wrapper dedicated command batch files on Windows so it is now possible to control whether or not the first parameter is the configuration file name. The ability to specify an alternate configuration file is now disabled by default as it was confusing for users who tried to pass other parameters to the JVM.
  • Correct a couple log messages in the WrapperManager class which were missing the correct prefix identifying where they originated.
  • Remove some old reflection code needed for Java 1.2.x support as we have required Java 1.4 since version 3.4.0.
  • Remove some code to try to reconnect the backend socket from Java. It has never been possible to do so without restarting the JVM, and the related messages were confusing.
  • Add a new wrapper.disable_forced_shutdown property to make it possible to disable the feature to forcibly kill the JVM on shutdown if CTRL-C was pressed twice.
  • Reduce the number of times thread priorities are changed within the WrapperManager class to simplify the startup and shutdown process.
  • Fixed a dangling pointer problem, which could cause undefined behaviour whenever a property contained an unset environment variable.
  • Fix a race condition in the timer thread, which could cause a sigkill being propagated through the whole process group rather than the timer thread. This can only happen during the shutdown of the Wrapper.
  • When a child process, which got launched by WrapperManager.exec() failed to start due to a runtime-error (such as missing privileges), the forked heap persisted and the child process never finished until shutdown/restart of the JVM. The error only appears on UNIX platforms when using the FORK_EXEC start-type.
  • Change log level and message if a certificate check returned a problem, which is not directly caused by the signature of the Wrapper, but the signature chain.
  • Fix a problem when the silent query command wasn't returning the correct exit code on Windows Vista (and later) when the command was run from an unelevated console. Thanks to Darren for pointing this out.
  • The Java system property wrapper.backend.so_timeout was ignored if it was set to 0 (zero), making it not possible to explicitly set the timeout to be indefinitely.
  • Added the properties wrapper.jvm.additional.auto_bits. to individually turn on/off the feature for the supported platforms.
  • Fix a problem where the script was trying to use the 64-bit binaries on Mac OSX even if the CPU was only a 32-bit architecture. This only affected versions of Mac OSX greater 10.5.0, the vast majority of those machines are already 64-bit CPU's. Thanks to Robin and Irina for pointing this out.
  • If the console is going to be displayed when running as service, the console output wasn't displayed and the console only showed a blank window. Fixed this, so the console shows now all output.
  • The Wrapper when reloading the configuration file, was trying to access data from the call stack of a function which was actually outside of the memory range of the stack. This access violation might yield a segmentation fault. This issue was introduced in 3.5.5. Thanks to Lincoln for helping finding this problem.

New in Java Service Wrapper Professional Edition 3.5.14 Testing (Feb 14, 2012)

  • Fix a problem in the AppCommand.bat.in file where a parenthesis in the file name of the Wrapper binary would have caused a "PATH was unexpected at this time" error.
  • (Standard / Professional Edition)
  • Fix a problem when using a localized version of the Wrapper on Windows 64-bit platforms where the Wrapper would continue to use the default system language even wrapper.lang was used to specify a different language. Introduced in 3.5.12.
  • Fix a problem in the Windows AppCommand.bat.in command based batch file where the 'status' command was incorrectly being reported as 'query' in the usage output. The 'status' command had always worked correctly if used.
  • Fix a problem on UNIX platforms where some asynchronous messages were causing a warning message "Coding Error..." to be logged in place of the intended message. This could be seen if the configured log file did not have write permissions. Other than the incorrect log message, the Wrapper worked correctly. Introduced in 3.5.2.
  • Fix a problem in the UNIX script where running with upstart wasn't working correctly when RUN_AS_USER was set.
  • Relax security checks when running the 'status' command against the UNIX shell script so it now allows any user running the script to perform the read-only check of the pid file.
  • Fix a problem with the UNIX script where the 'remove' command was trying to stop a running application even when the application had not been installed.
  • Fix a buffer overflow which could potentially cause a crash during the installation of a Windows Service when wrapper.ntservice.account was specified. This was introduced in 3.5.12.
  • Fix a heap corruption which could occur on startup and potentially cause a crash. Only Windows systems, which use the System Event logs, were affected. Discovered from a code review, there had never been any reports of this causing problems for users. This could happen if the configured wrapper.log could not be written to as the Wrapper always tries to write to the Event Log in such cases. Introduced in 3.5.12.
  • Add a new version comparison between the UNIX shell script and Wrapper to start showing a warning in case of a version mismatch. The check will only work if the shell script and Wrapper are each of at least version 3.5.14.
  • Added a new wrapper.pidfile.strict property which will tell the Wrapper not to start if the pid file already existed. Defaults to false for backwards compatibility.
  • Make the Java side of the backend socket more resilient in case of a read or write timeout. The backend socket does not have a timeout set by default so this should not have been an issue. A couple users reported problems on specific systems however which led to this fix.
  • To aid in the testing of the backend socket timeout, a new wrapper.backend.so_timeout system property was added to make it possible to configure the backend socket to use a timeout. See the Javadocs of the WrapperManager.exec() class for details.

New in Java Service Wrapper Professional Edition 3.5.13 Testing (Nov 4, 2011)

  • Fix a typo in the script where the environment variable 'TR_BIN' should actually be 'TREXE'. This was causing the "install" command on UNIX platforms to fail. Introduced in 3.5.12.
  • Fix a heap corruption which could lead to a crash that would occur the second time an internal buffer used for logging was expanded. The buffer would be expanded the first time a log line over 2048 characters in length was encountered. Then the second expansion would happen when a line at least 1024 characters longer was encountered. Introduced in 3.5.11.

New in Java Service Wrapper Professional Edition 3.5.12 (Nov 4, 2011)

  • Put more descriptive Text in case the Wrapper is using integration method 4, but the jar file is not specifying the Main-Class correctly in its meta information.
  • Fix a bug when failing to grant the LogOnAsService permission to a domain user.
  • Fix a bug where the ident for the syslog on Unix platforms was broken since 3.5.0. This was because when opening the syslog, the Wrapper was freeing the memory for pointing to ident. However the string pointer ident will be retained internally by the Syslog routines. And must not free the memory that ident points to. Bug #3404978.
  • Add a check on the script to make sure the 'tr' command exists on Unix platforms.
  • Improve the parsing of log formats so that format tokens are recocognized even if they are lower case. This affects the wrapper.console.format, wrapper.event.default.email.maillog.format, wrapper.logdialog.format, and wrapper.logfile.format properties.
  • The Wrapper parses log formats by looking for known tokens, any invalid tokens are simply ignored. If the entire format is made up of invalid tokens then this resulted in the Wrapper logging an empty line, which was not very useful and caused confusion when encountered. The Wrapper now reverts to the default log format in such cases. This affects the wrapper.console.format, wrapper.event.default.email.maillog.format, wrapper.logdialog.format, and wrapper.logfile.format properties.
  • Improve the debug output while loading native libraries to avoid confusion about the meaning of the warning logged about attempts to load alternately named native library files.
  • Fix a problem on Unix platforms where the default umask was being set to 0000 rather than inheriting it from the parent process when running as a daemon process. This can be a security problem as log and other files have global read/write access. Introduced in 3.5.8. Can be worked around by setting the wrapper.umask property to a safe value.

New in Java Service Wrapper Professional Edition 3.5.11 Testing (Aug 18, 2011)

  • Fix a potential crash on Windows caused by a buffer overflow. This has been a problem since version 3.5.0 and affects configurations which define more than one wrapper.ntservice.dependency.. Depending on what was in memory, this did not always result in a crash. It has very reproducible behavior for a given configuration file.
  • Fix a problem on Windows where the Wrapper was taking 15 seconds or longer to startup on some systems because the WinVerifyTrust system call was having problems updating the CRL. This had been a problem since the Wrapper binaries started being signed in version 3.5.7. If the WinVerifyTrust call takes longer than the configured wrapper.startup_thread.timeout then the Wrapper will continue to startup without further delay.
  • Fix a potential crash on Windows caused by a buffer overflow. This has been a problem since version 3.5.0 and affects configurations which define more than one wrapper.ntservice.dependency.. Depending on what was in memory, this did not always result in a crash. It has very reproducible behavior for a given configuration file.
  • Fix a problem on Windows where the Wrapper was taking 15 seconds or longer to startup on some systems because the WinVerifyTrust system call was having problems updating the CRL. This had been a problem since the Wrapper binaries started being signed in version 3.5.7. If the WinVerifyTrust call takes longer than the configured wrapper.startup_thread.timeout then the Wrapper will continue to startup without further delay.
  • Standard / Professional Edition)
  • Explicitly remove the certificate of the customized binary during customization. There were problems resigning the binary with another certificate otherwise.
  • If the Wrapper is unable to write to the configured wrapper.logfile for any reason then we always fall back to a default log file and then log a message about the failure. If the default also fails then that is also logged but the messages would only be logged to the console in most cases. Modify the Wrapper so we now always send both messages to the syslog or EventLog regardless of what the wrapper.syslog.loglevel is set to. This is important to help track down the cause of logfile access problems.
  • Starting with version 3.5.0, it was internally possible to print out multi-line log messages so that all of the lines would always be grouped together in the log file. This version modifies the logging code slightly so that such multi-line log output is now logged as a single message in the UNIX sylog or Windows EventLog.
  • Fix a problem where very long lines of output from the JVM would cause the Wrapper to appear to hang for a while. The first time a single line of output containing several hundred thousand characters was logged, an internal buffer was being incrementally increased by 100 characters per cycle. The Wrapper now increases the size based on last known size to greatly reduce the number of cycles needed to choose a new buffer size.
  • Modify the PAUSE_THREAD command so it is now possible to wait indefinitely. Only useful for testing the Wrapper.
  • Add a new PAUSE_LOGGER command to make it possible to pause the next log entry. Only useful for testing the Wrapper.
  • On UNIX, the stdout/stderr pipe between the JVM and Wrapper was not being cleaned up correctly. This resulted in a small leak but was otherwise harmless. The pipes are now cleaned up and initialized for each JVM instance.
  • Fix a problem where the Wrapper could fail to restart the JVM when the restart request originated in the JVM if the system was experiencing very heavy IO resulting in long disk IO queues. This was causing the Wrapper's main loop to block on the write and miss the restart request, causing the Wrapper to shutdown rather than restart. This could affect all platforms. On Windows, it could also be reproduced by making a selection in the console to freeze output and then making a request from within the JVM to restart.
  • Add a new WrapperPropertyUtil helper class to make it easer to access Wrapper property values from within the JVM.
  • Fix a bug on some platforms where java log output could get corrupted due to misuse of a strncpy system function. This function warns that some implementations do not support overlapping memory copies. The problem could only be reproduced on a single Linux test machine in lines following an empty line of output. This problem has existed since 3.4.0.

New in Java Service Wrapper Professional Edition 3.5.10 (Aug 18, 2011)

  • Setting wrapper.jvm.port to '0' (zero) will make the JVM to assign an available port for the backend socket by itself.
  • Add warnings in the log file if an integer configuration property value contains a non-numerical value. Previously, the Wrapper would silently ignore the problem and use the value of 0 if the number started with an invalid character, it will now return the default value. If the property value started with valid numerical characters then those were, and still will be, used to generate a value, but the invalid characters will be trimmed. The later is being kept this way to avoid breaking old configurations.
  • Add warnings in the log file if a boolean configuration property has any value other than TRUE or FALSE. It will still return a value of FALSE for other values to avoid breaking old configurations.
  • Add a warning if an invalid value is specified for the wrapper.on_exit. property.
  • Add a new wrapper.log.lf_delay.threshold property which makes it possible to control how long a partial line of Java log output will be allowed to be buffered until it is completed with a line feed. If the threshold is exceeded then the partial line will be logged as a full line resulting in an extra line feed in the log output. All previous versions would do this within 1-2 ms. The default is now 500ms.
  • Make it possible to customize the manufacturer through the customize options.
  • Fix a problem where the Wrapper was sending a CTRL-BREAK rather than a CTRL-C signal to child processes launched with WrapperManager.exec() when destroying them on Windows. For most child processes this was not a problem, but if the direct child process was a JVM then the CTRL-BREAK was triggering a thread dump rather than asking the JVM to exit. The Wrapper was then timing out and forcibly killing the JVM child process.
  • Fixed a bug, where the timezone ICT when set by the wrapper.timezone property got misinterpreted as IST.

New in Java Service Wrapper Professional Edition 3.5.9 (Aug 18, 2011)

  • Fix a problem on Windows where network adapters whose names contained "PRO/1000" were being removed from the list of hostids displayed when "wrapper.exe -h" was run. This did not affect existing server license key files generated for hostIds reported by 3.5.7 or earlier, or development license keys. But it did cause the Wrapper to report that no valid hostIds could be found when the Wrapper was started without a license file. This was caused by some test code added in 3.5.8 that we failed to remove.
  • Fix a problem where the Wrapper was not correctly yielding control back to its main loop when very large amounts of continuous output was being logged from the JVM. Introduced in version 3.4.0. In versions prior to 3.5.8, this could have caused the JVM to timeout and restart itself. That particular issue was resolved but the Wrapper process in 3.5.8 would still have been unresponsive when this was happening. The Wrapper will now always yeild back to its main loop after 250 milliseconds of continuous logging.
  • Fix a problem where the WrapperManager could block trying write debug output if the current user application was writing very large amounts of output to the console as well. In extreme circumstances this led to the Wrapper thinking that the JVM was frozen. This was only an issue if debug output was enabled.
  • Restructured the shell script so all editions now use the same script again.
  • Take out the warning about unset LANG environment variable on Linux and AIX systems, an unset LANG envirionment variable is uncommon but in fact not a problem and the warning was misleading.

New in Java Service Wrapper Professional Edition 3.5.8 (Aug 18, 2011)

  • Starting with version 3.5.5, we invalidated the use of all 00ff* hostids on Windows to avoid problems with changing hostids when users have a Juniper Network Connect network adapter on their system. This turned out to be too restrictive as Guest OSs running under Parallels also make use of this hostid range. The Wrapper is now more careful to only invalidate actual Juniper Network Connect hostids.
  • Improve the message shown to the user when the Wrapper is unable to locate any hostids for a system.
  • Fixed a problem with the Wrapper script on Solaris, where the option -F was not available for grep.
  • Added Windows version information on the Wrapper debug output.
  • Added a wrapper.log.warning.threshold property which makes the Wrapper show a warning whenever it detects that the Wrapper took a long time to record a log message. This was added to test a reported issue caused by slow IO on very heavily loaded systems.
  • Fix a problem where a filter that requested the JVM to restart would be ignored if the JVM exited on its own immediately. The Wrapper is now more consistent so that restart requests from within the JVM or filters will always take priority over such exit requests. External shutdown requests, or those from other actions will still behave as they did in the past and continue to shutdown the Wrapper. The Wrapper also logs messages in debug output if an outstanding restart request is being preserved or ignored.
  • Fixed a problem in the AppCommand.bat batch file which could occur on some Windows platforms with certain multi-byte system encodings. The script has been rewritten and questionable parts have been simplified. The functionality of the script has been preserved.
  • Added the environment variable WRAPPER_CONF_DIR, which can be used for the configuration properties. (Feature Request 3160644)
  • Made the script exit with the right exit code received when running the script as different user, specified in RUN_AS_USER. (Bug Report 3185281)
  • Fix an access violation which could happen when the code signing certificate has failed to been verified.
  • Log an error if the backend socket is forcibly closed externally. It had been getting logged at a debug log level. The message is "An existing connection was forcibly closed by the remote host. (0x2746)". Because the message was only logged if debug output was enabled, the JVM would be restarted with no clear explanation as to what happened. The source of the socket closure is under investigation.
  • Added the Java call fireUserEvent to the WrapperManager API. This enables to fire user event mails, actions without the filter trigger. Please also find more details about the security model for this call at the security page.
  • Fix a warning on Mac versions if the configured java command was not a universal binary. A check was added in 3.4.0 to make sure that the wrapper.java.command pointed directly to an executable to avoid unexpected behavior when running a script. The message is only a warning and the Wrapper continues regardless. Standard ppc, ppc_64, x86_64, i386, as well as the universal binaries will now all work correctly without a warning.
  • The default value of the wrapper.*.umask properties is using the current umask the process has. Before the default value was always 0022.
  • Add a new wrapper.backend.type property that is used to control whether the Wrapper communicates with the JVM using the traditional "SOCKET" or new experimental "PIPE". This was added as a workaround to a rare problem where some Windows machines are closing the socket at an OS level. This was only ever seen on Windows 2003, but could exist on other Windows versions as well.
  • Add a new experimental wrapper.use_javaio_thread property which causes the Wrapper to handle all java console output in a dedicated thread.
  • Add a new WrapperManager.isNativeLibraryOk() method which lets user code easily test whether or not the native library was loaded and initialized on startup.
  • Add a new PAUSE_THREAD command to the wrapper.commandfile property which makes it possible to test how the Wrapper behaves when various threads block or freeze. This was used to simulate and reproduce issues on heavily IO bound servers.
  • Improve the way the Java side of the Wrapper behaves when the Wrapper fails to ping the JVM for an extended period of time. The JVM used to exit to let itself resync itself with the JVM. This was causing problems on systems which were heavily IO bound because the Wrapper could block for a while while trying to write to the log file and the JVM was exiting. The JVM will now never exit under such circumstances. The JVM will never become orphaned because it will still exit almost immediately if the backend socket or pipe with the Wrapper is ever closed.
  • Deprecate the WrapperManager.appearOrphan() method as it is used to simulate a failure mode which is no longer possible with the Wrapper.
  • Changed the way the Wrapper is handling certificate errors regarding the code signing/timestamping certificate. The Wrapper will now only shutdown itself if the signature of the binary was not successfully verified because the binary or signature has been malformed but not if any problem with the counter-signer has been found. Starting with 3.5.7, the Windows Wrapper binaries are signed. Some users with locked down Windows 2008 systems had problems with the Wrapper refusing to start because the Comodo certificate had been disabled on their system.
  • Add a new wrapper.java.detach_started property which makes it possible to use the Wrapper as a simple tool to launch Java applications. When enabled, the Wrapper terminates immediately and the JVM is left to run on its own.
  • When running the Wrapper as a specified User Account, through the wrapper.ntservice.account property, the Wrapper will add permission for the account to log on as service automatically upon install. (Feature Request #3286491)
  • Fixed a problem binding the backend socket on Windows. If another process bound a port inside the wrapper.port.min and wrapper.port.max range using the SO_EXCLUSIVEADDRUSE option, the Wrapper would stop at this port report an Access Permission problem and omits binding any further port in the range. This problem existed ever since the Wrapper was released.

New in Java Service Wrapper Professional Edition 3.5.7 (Aug 18, 2011)

  • Changed the way the script is installing the daemon on an AIX system. The script now uses inittab & SRC.
  • Fix a problem in the shell script that was preventing the script from starting the Wrapper correctly if a file or directory existed in the current working directory which was one character in length. This was only a problem when the delta-pack naming of the Wrapper was used. This was easy to reproduce on AIX systems on system restart because a "u" directory exists in the root directory by default. This had been a problem since 3.4.0 when it was introduced as a fix to a Solaris problem. The root cause was a missing set of quotes in the tr command.
  • Fix a problem in the shell script that was preventing the script from finding the running Wrapper process when it was started when the working directory was in the same directory as the Wrapper binary, but queried later from another location. It would also fail if it was started from another location, but then queried from the location of the Wrapper. This was introduced in 3.5.6 when the script stopped changing the working directory in the script.
  • Add a new GC action that will cause the JVM to immediately perform a full garbage collection sweep. See the wrapper.commandfile, wrapper.filter.action., wrapper.check.deadlock.action, and wrapper.timer..action properties for details.
  • Modify the wrapper.event..command.block.action property slightly so it will now correctly warn if an unknown action is encountered. It had been defaulting to CONTINUE silently.
  • Modify the timing of the message shown when an #encoding directive is missing from the top of a configuration file. It was only being logged if debug output was enabled. It will now also be logged if the #include.debug directive is specified.
  • Fix the indentation of warning messages about encoding or include problems in configuration files.
  • Fix a problem where include file problems could cause the shell script to have errors due to invalid translated output from the Wrapper.
  • Add a warning when the maximum include depth is reached and include debugging is enabled. The Wrapper had always just silently skipped the include.
  • Fix a problem where #include.required directive was not correctly preventing startup if the include file was missing but the required include was in a nested include.
  • Fix a problem where the cause of some fatal include problems were not being logged correctly, resulting in a simple, non-informative message only that the configuration file failed to be loaded. This was a problem since 3.5.5.
  • Fix a Windows problem where the Wrapper could fail to start as a service if a defined environment variable would expand to a length larger than the 32k limit specified in the ExpandEnvironmentStrings system function. This was a problem on all Windows platforms prior to 3.5.5, but only on Windows 2000 since then, when the code used to reload the environment from the registry was disabled for newer versions of Windows. We now simply skip the expansion of the problem variable and continue with a warning. Bug #3103776.
  • Add a set of optional system properties that the WrapperSimpleApp, WrapperStartStopApp, and WrapperJarApp helper classes are aware of to tell them to ignore uncaught exceptions thrown within the main methods of the user application. The exceptions will still be logged, but they can now be configured so that the main method is just allowed to end without causing the Wrapper to shutdown in an error state. Java on its own will stay running in such a case as long as it has launched at least one non-daemon thread prior to the uncaught exception being thrown. This does not affect most users, but an application was found that was having problems because of this difference in behavior. See the javadocs of the helper classes for details.
  • Fix a problem when looking for the correct exit code to use for the wrapper.event..command.on_exit. property. The Wrapper now searches for a value as follows: wrapper.event..command.on_exit., wrapper.event..command.on_exit.default, wrapper.event.default.command.on_exit., then wrapper.event.default.command.on_exit.default. The third pattern had been getting skipped in previous versions since it was added in 3.3.0.
  • Add logic to report a warning if an unexpected value is specified for the wrapper.event..command.on_exit. property.
  • Clean up the message log levels so the output is as expected when using the wrapper.event..command.loglevel property.
  • Improve the wrapper.event..command.on_exit. property so the configured action will now work even if the command exits after the block time out has expired. In previous versions, there was no way to make the Wrapper do anything other than continue.
  • Fix a problem where the Wrapper was failing to detect a JVM exit correctly if an event command had been fired first. The only problem was that the Wrapper was always reporting a JVM exit code of 0 rather than the actual exit code.
  • Fix a buffer overflow on Windows when either installing as a service, or updating an existing service. The problem only occurred when properties containing spaces, or Java passthrough arguments containing spaces were specified on the command line. The running service did not have any problems. This was introduced in 3.5.0.
  • Improve the error message logged when an unlicensed version of the Wrapper's native library is used.
  • Fix a buffer overflow problem on Windows when creating a customized Wrapper binary if the target binary name did not include the ".exe" extension. This problem existed since its intruduction in 3.3.7.
  • The wrapper.exe, wrapperW.exe and wrapper.dll binaries are now being signed on Windows making it possible to verify that valid Tanuki Software binaries are being used.
  • Implemented a way to install, remove, start, stop, etc., the Wrapper as a Windows service from a non-elevated (UAC) console. The Wrapper is elevated transparently using a child process. This is needed starting with Windows Vista and 2008 for smooth interaction with the Windows Service Manager.
  • Fix a problem where the wrapperjni_*.mo localized files were not being loaded correctly. These messages are only shown when debug output is enabled. Application and Wrapper localization was working fine. Introduced in 3.5.5.
  • Enhanced the ability to run with localizations other than the system language on Windows. The Wrapper process locale was not being set correctly. So Japanese text was not always showing correctly if the wrapper.lang property was set when the OS was English or German. The Java process still has an issue where it will always start with the system default value for the file.encoding system property. This can still cause problems writing Japanese text when the file.encoding is German for example.
  • Added support in the shell script for starting/installing the Wrapper on system boot with upstart.
  • Fix a problem in the shell script where it would fail to recognize a running Wrapper if the Wrapper command line or path contained a square bracket.
  • Modify the way we test for the existance of the temp directory so we now generate our own file name rather than using File.createTempFile. On some systems createTempFile was taking a long time because it requires that Java initialize its internal entropy. We discovered that large numbers of files in the java.tmpdir directory makes Java's entropy initialization code very slow. This has been a potential issue since 3.5.0.
  • Fixed a problem on Windows where passthrough arguments after a "--" which contained spaces were not being passed through to the JVM intact, they were being split at the spaces into multiple arguments.
  • Fix a problem on Windows where the Wrapper could sometimes crash on shutdown if more than one thread got into the cleanup code at the same time. This did not affect running applications and was only an issue on shutdown. It was more likely if a language pack was loaded. Introduced in 3.5.3.

New in Java Service Wrapper Professional Edition 3.5.6 (Aug 18, 2011)

  • Fix a problem on Windows platforms where the Wrapper would crash if it could not access the directory of the configured wrapper.logfile. Introduced in 3.5.5. Bug #3087424.
  • Improve the way warnings are logged when there are problems writing to the configured wrapper.logfile so that the message will now be logged into the log file that the Wrapper ends up using in case it is successful in falling back to a default log file.
  • Fix a problem on Windows platforms where wrapper.java.additional. properties that were specified on the command line, and contained spaces, were not being requoted correctly when building up the Java command line. Introduced in 3.3.6.
  • Fix a problem where the warning message logged for invalid values of the wrapper.java.additional. property, contained corrupted text. Introduced in 3.3.6.
  • Fix a problem on UNIX platforms where an invalid value for the wrapper.java.additional. property was correctly being reported and then skipped, but the resulting command line to launch the JVM had a blank value that was causing the JVM to fail to launch. An invalid value is any value that does not begin with a "-" character.
  • Add a new WRAPPER_INIT_DIR environment variable which can be used to reference the working directory from which the Wrapper was launched. This is needed for certain applications because the Wrapper always changes its working directory to the location of the Wrapper binary.
  • Modify the UNIX shell script so it no longer changes the current working directory to the location of the script. This is no longer needed because the Wrapper has been changing the working directory to its own location since 3.2.0.
  • Add a new wrapper.request_thread_dump_on_failed_jvm_exit.delay property to control how long the Wrapper will wait after doing a thread dump before killing the Java process. This delay has always been hardcoded to 5 seconds.
  • Clean up the text of several warning messages about invalid configuration values to make them more consistent.
  • Add a new wrapper.jvm_kill.delay property which makes it possible to control the amount of time to allow between the jvm_kill event being fired and the JVM actually being killed. Useful if an external event command is fired that needs to do something with the JVM process first.
  • Fix a problem on Windows when multiple threads were creating Childobjects, Handles could have been unintendedly get inherited by another Child Process, causing problems on reading/writing to the Input/Output/Errorstream.
  • Fix a problem on solaris and AIX when errno calls were not thread safe due to a compiler switch.
  • Fix a problem where debug level warning output while loading the Wrapper configuration was being displayed on startup. This could be fixed because the Wrapper actually loads the configuration twice, and such output is now only logged on the second call.
  • Remove the undocumented ability to define a single file share mapping without the index. This would cause confusion if used, and complicated the code.
  • Fix a byte alignment problem caused by a bad compiler directive on Windows platforms. It was known to cause a crash when defining mapped drives on 64-bit Windows versions. The problem was in the source since 3.3.7, but is not known to cause any other issues.
  • Modify the messages displayed when network shares are mapped or fail for some reason. Also add messages about them being unmapped on shutdown.
  • On some Windows platforms, a failure to delete a rolled log file was not being reported correctly. The system function to delete a file was returning success even if it had failed. We now double check.
  • Fix a deadlock in the code that is used to send data to the Java process. It was only possible if debug level output was enabled and log file rolling was enabled. Introduced in 3.3.7.
  • Fix a problem where the Wrapper was not notifying the JVM whenever the log file was rolled and the new name was the same as the previous one, as it is when wrapper.logfile.rollmode is anything other than NONE or DATE.
  • Fix a problem where the WrapperManager.getWrapperLogFile() was not returning the accurate log file name until the first time the log file was rolled after each JVM invocation. This was only noticeable if the wrapper.logfile contained either the "ROLLNUM" or "YYYYMMDD" tokens.
  • Correct an error message that was displayed on UNIX platforms when the configured java binary could not be accessed. The message referenced a buffer whose contents were undefined on some platforms.
  • Fix a problem on z/OS where due a difference in the API used to lock a mutex compared to all other UNIX platforms, the mutex's locking and unlocking code were effectively being ignored. This means that multiple threads were able to access code which was not thread safe and could lead to a crash of the Wrapper. This is a problem that has been in the code since the first z/OS release and is not known to have actually caused any problems. Starting with 3.5.1, this was only an issue if debug output was enabled. 3.3.9 through 3.5.0 could have also had problems whenever the Wrapper received a system signal.

New in Java Service Wrapper Professional Edition 3.5.5 (Aug 18, 2011)

  • Add a new action "SUCCESS" in wrapper.filter.action. property. If this gets triggered, then the Wrapper will treat the current JVM invocation as a success, and reset its internal failed invocation counter. This is useful for applications that need to be restarted frequently.
  • Ignore Juniper Network Connect hostIds as they change on each reboot and are thus unreliable as hostIds.
  • Added a PASS_THROUGH setting to the UNIX shell script and Windows AppCommand.bat.in files which tells them to pass any extra arguments directly on to the JVM when it is launched.
  • Added a FIXED_COMMAND setting to the UNIX shell script and Windows AppCommand.bat.in files to make it possible to run either without specifying a command. Mainly useful in conjunction with PASS_THROUGH.
  • Added a --passthrough option to the exe customization, in order to tell the Wrapper to precede the whole command line through to the application in the JVM.
  • Added a --conf option to change the default configuration file, the Wrapper tries opening when no configuration file was explicitly specified.
  • Added the wrapper.ntservice.account.prompt property. If set to TRUE the Wrapper will prompt for all account details (domain, account name, password) before installing the app as service.
  • Fix a minor issue in #include file declarations where a leading space was not required.
  • Add a new #include.required directive which works the same as the #include directive except that it will output an error and prevent the loading of the configuration if the included file does not exist. Normally include files are optional by design.
  • Modify the error messages displayed when configuration files fail to load so they now provide more information about where specifically the problem was.
  • Disabled the forced reloading of the SYSTEM (and if set to a specific account, the user) registry before launching the Wrapper as a service on Windows. This was done originally in Windows NT because changes to the configured environment were not being reflected when running a service unless the system was first rebooted. Microsoft appears to have solved this problem in Windows XP and 2003. In Windows 7 and 2008, this was actually causing a problem because the SYSTEM registry contains a setting "USERNAME=SYSTEM" by default that was overwriting the USERNAME when run as specific user. It was decided to disable this registry loading for Windows versions starting with XP and 2003. On the supported versions, only 2000 is now reloading its environment. The only difference from 3.5.4 and earlier that could be found is that when running as the SYSTEM user on Windows 7 or 2008, the USERNAME environment variable will now be set to the host name followed by a dollar sign rather than SYSTEM. This is actually how all other services work. But just in case this is a problem, it can we resolved by adding a "set.USERNAME=SYSTEM" property into the Wrapper configuration file. Bug #3061490.
  • Fix a problem for Solaris and HP-UX where the "send" timeout and "receive" timeout properties for the email notifications were ignored.
  • Added wrapper.ntservice.recovery. properties to define system level actions in the event that the Wrapper process itself has a failure.
  • Fixed a problem in the WrapperProcess.waitFor() and WrapperProcess.returnValue() call, where it would fail to return when called after the Wrapper had initiated the shutdown of the JVM.
  • Add WrapperProcessConfig.setSoftShutdownTimeout(int) method to tell the Wrapper how long to wait after nicely asking the child process to shutdown cleanly when calling WrapperProcess.destroy(). Once the timeout has ellapsed, the child process will be forcibly terminated. This timeout had been hard coded to 5 seconds in earlier versions.
  • Add more detailed usage output to the UNIX shell script.
  • Make it possible to 'pause' and 'resume' the JVM from the UNIX shell and Windows batch scripts.
  • Fix a minor memory leak while initializing timers.
  • Fix a memory leak which could happen if there were any invalid strings in localization resources.
  • Fix a bug where the wrapper.event..command.argv. properties were not correctly parsed on Windows. This issue was introduced in 3.5.0.
  • Add the ability to define wrapper.event.default.command.argv. properties that will be used if the event specific commands are not defined. Mainly useful for testing.
  • Fix a problem occuring when the Wrapper failed to roll the log file causing to write to the Wrapper's default log file (wrapper.log) rather than continuing to write to the current logfile.
  • Fix a put problem in the internal hash map implemenation used for localization where values could be lost. This was not a visible issue because of the data used.
  • Add new wrapper.filter.allow_wildcards. property and make it possible to specify wrapper.filter.trigger. patterns which contain '*' and '?' wildcards.
  • Add a commented alternative in the default OutOfMemoryError filter configuration to make it more specific to only trigger on uncaught exception stack traces. This is to avoid output like that from the -XX:+PrintClassHistogram JVM argument from causing the JVM to restart with a false out of memory warning. See wrapper.filter.trigger. OutOfMemoryError example for more details.
  • Localize the default filter message.
  • Added ISO-8859-* encoding support and a few other encodings. For a full overview, please refer to the Internationalization / Localization page.
  • Fix a problem on Windows when a service received several service control codes in rapid succession. Since 3.5.1, the Wrapper was only to process a single control code in each cycle of its main loop. This was resulting in messages like "Previous control code (4) was still in queue, overwriting with (4)." in the logs. The Wrapper can now handle up to 25 control codes per 10ms cycle.
  • Fix a problem where it was not possible to send passthrough arguments to the JVM when installing or updating a Windows Service. Passthrough using the "--" argument was added in 3.5.2.
  • Add a new wrapper.pause_on_startup property which makes it possible to tell the Wrapper to go directly into a paused state without ever launching a JVM.
  • Fix a problem where the STOP command set in a command file was being ignored if the Wrapper was currently in a paused state.
  • Make it possible to specify DEFAULT for the configuration file encoding. This will cause the file to be loaded using the default system encoding. We added this by request, but recommend using a portable encoding like UTF-8 to ensure that the configuration file will load correctly on all systems.
  • Added a WRAPPER_LANG environment variable which makes it possible to reference the current locale language code in the configuration file. One common use is to do localization using inclues. (e.g. #include ../conf/wrapper-%WRAPPER_LANG%.conf to load #include ../conf/wrapper-en.conf or #include ../conf/wrapper-de.conf)

New in Java Service Wrapper Professional Edition 3.5.4 (Aug 18, 2011)

  • Add optional support for custom public static methods in the WrapperSimpleApp and WrapperStartStopApp helper classes. Feature Request #2812276.
  • Add a new special configuration file directive "#properties.debug" which enables debug output about the properties as they are loaded by the configuration file. This can be useful to tell if and why certain properties are being overwritten. Feature Request #3042959.
  • Fix a minor problem where the "#include.debug" configuration file directive was sticky so it would be enabled when the configuration file was reloaded even if the reloaded configuration file no longer had the directive set. This was only an issue if the wrapper.restart.reload_configuration property was set.
  • Messages about missing included configuration files that were output when the "#include.debug" configuration file directive was active were being logged at the ERROR level even though they were not problems.
  • Fix a minor problem where the WRAPPER_JAVA_HOME environment variable was not correctly being set to final when it was set internally by Wrapper. This could lead to unexected results if the user overwrote it later in their configuration file.
  • Fix a problem on AIX and z/OS, when running the Wrapper without any arguments. The Wrapper was attempting to use the default wrapper.conf file but the check for the file was failing causing the Wrapper to continue even though the file did not exist. This caused a confusing error message to be displayed, but was otherwise harmless.
  • Clean up some debug code associated with sleeping where log output was being queued when it did not need to be.
  • Fix a problem in the email feature of the Wrapper where a subject of more than 27 bytes in length when encoded as UTF-8. This was caused by a miscalculation in the Base64 conversion of the subject.
  • Fix a problem when the WrapperManager.exec method which takes an array of command elements was called on Windows. The command elements need to be combined into a single command line, but if any of the elements contained spaces, the resulting command line was not being correctly quoted.
  • Add a new wrapper.java.command.resolve property to control whether or not the Wrapper tries to resolve any symbolic links in the Java command, specified with the wrapper.java.command property. Historically, it has always done so, but some jvm started applications like run-java-tool on Gentoo will fail if it is run directly as they have a check to make sure it is launched via a symbolic link.
  • Fix a problem on Windows versions where a path to the Wrapper binary, including the Wrapper binary itself, which was more than 100 characters would cause a buffer overflow when installing the service. A second similar problem would happen if the same path was more than 128 characters, whenever the Wrapper was launched. These were both very old issues and only happened on 32-bit versions of Windows XP and 2000. Microsoft documentation says that the issue should also exist on the 64-bit versions, but we were unable to reproduce it there. Newer versions of Windows are all fine.

New in Java Service Wrapper Professional Edition 3.5.3 (Aug 18, 2011)

  • Fix a typo in the UNIX shell scripts that was causing "command not found" errors to be shown when running the Community Edition.
  • Add new wrapper.console.fatal_to_stderr, wrapper.console.error_to_stderr, and wrapper.console.warn_to_stderr properties to control whether the output at the FATAL, ERROR, and WARN log levels go to stdout or stderr. In the past they all went to stdout. With this change, FATAL and ERROR log levels now default to stderr output.
  • Fix a problem where the shell script would produce unexpected results if the Standard or Professional Edition shell scripts were used with the Community Edition Wrapper. Fix was in Wrapper binary by changing the default ERROR and FATAL log level console output to stderr rather than stdout.
  • Fix a problem where script error message output was not being shown if the wrapper.conf file specified in the script did not exist.
  • Fix a problem where errors from failed forks on Windows were always being flushed immediately rather than honoring the value of the wrapper.console.flush property.
  • Fix a problem on Windows 2000 systems where a new feature added in 3.5.2 was preventing the Wrapper from running because the API used was too new.
  • Change the font of the wrapperw dialog in order to have prettier output of multibyte characters
  • Add a line feed after the first message when starting the Wrapper from the UNIX script
  • Add a note in the debug output so the configured java temporary directory is always logged to help with debugging
  • Add a workaround for a bug in both Sun and IBM JVMs which cause an invalid exception to be thrown when a socket is already bound. It had been causing the Wrapper to report: "Unexpected exception opening backend socket: java.net.SocketException: Unrecognized Windows Sockets error: 0: JVM_Bind": Bug #6965962
  • Change the encoding of the subjects in the event mails to be always UTF-8 Base-64 encoded
  • Add new wrapper.event..email.smtp.auth.type, wrapper.event..email.smtp.auth.userid, and wrapper.event..email.smtp.auth.password properties which make it possible to do LOGIN and PLAIN connection authorizations. Currently SSL (STARTTLS) connections to the mail are server are not yet supported.
  • Fix a buffer overflow while loading the configuration file on Mac OSX versions. Introduced in 3.5.0.
  • Fix a several memory leaks on UNIX versions that were added in 3.5.0, as well as a few others on all platforms, some from quite early versions.
  • Fix some places where a resolved path of exactly MAX_PATH characters in length could have resulted in a buffer overflow.
  • Fix a memory leak disposing language packs.
  • Go through and increase the consistency of text strings.
  • Fix a problem on HP-UX where the Wrapper was logging a warning that the configured JVM was invalid if it was a PA-RISC 2.0 binary. Bug #3037317.
  • Fix a problem where the WrapperManager was failing to trap and hide errors initializing the MBean server on some JVMs that did not support it.

New in Java Service Wrapper Professional Edition 3.5.2 (Aug 18, 2011)

  • Added new command line argument "--" . All arguments following will be preceded and passed to the java application. The arguments are attached after the arguments used in wrapper.app.parameter.
  • Fixed a problem in the shell script which could lead to report failed starts of a daemon incorrectly on the command line.
  • Implemented some small logic in the Wrapper script which tries to change the permissions of the Wrapper binary to executable if it wasn't set.
  • The Demo Application had problems locating the right configuration file on UNIX platforms and failed to launch the internal demonstration Wrapper process.
  • Improved the error message logged if the Windows version of the Wrapper exits with an internal error. It now logs more information about the internal state of the Wrapper as well as saving a mini dump file which can be sent to support to make it easier to diagnose the cause of the problem.
  • Fix a problem where the names and displayNames in WrapperWin32Service instances were corrupted. List affected the WrapperManager.listServices(), WrapperManager.sendServiceControlCode(), and WrapperManager.setConsoleTitle(), methods. Introduced in 3.5.0.
  • Fix a problem on Windows where wildcards would sometimes fail to be resolved or cause the Wrapper to crash. This affected the generation of classpaths and logfile rolling. Introduced in 3.5.0.
  • Fix a problem where invalid characters in configuration files that did not declare an encoding could cause the Wrapper to crash on startup. This could be issue for users upgrading from versions prior to 3.5.0 as older versions did not do any character set translations and would not have had a problem.
  • Fix a problem in code to check whether a drive was a mapped network drive or not was failing. This would sometimes lead to a false warning that the drive could not be identified. Introduced in 3.5.0.