Softpedia >Linux >Utilities >Java Service Wrapper Community Edition >  Changelog

Java Service Wrapper Community Edition Changelog

What's new in Java Service Wrapper Community Edition 3.5.26

Feb 3, 2015
  • Improve the log messages when a JVM restart is requested when the Wrapper is in a state that it will be ignored.(Standard / Professional Edition)
  • Add an additional debug message when a deadlock sweep completes. No functional change but this was added to make it easy to tell how long the sweep takes on a given application.
  • Clean up the internal tracking of where environment variables were set. No functional changes.
  • When detecting Cygwin with 'uname -o' in the script file, some OS's (Solaris, MacOS, etc.) show an error message because '-o' is not a valid parameter. Now we hide this error message to avoid confusion and we can guess that Cygwin is not running.
  • Add the ability to control running the service with systemd using the script file.
  • On Mac OS X, fix a typo, add another alternative way to find Java to set the JAVA_HOME environment variable, and use the full path to execute sysctl in case it's not in the path. Thanks to Dannes Wessels for pointing this out.
  • Fix a problem on newer versions of Windows when customizing the Wrapper. The certificate was not removed when creating the target. This was leading to an error when trying to sign the target with a new certificate.
  • Add missing support in the shell script for restarting/stopping the Wrapper service with launchctl on Mac OS X.
  • Add missing support in the shell script for restarting/stopping the Wrapper service with Upstart.
  • Add the ability to set the path of the 'su' command as well as the ability to specify additional arguments in the Wrapper shell script using new SU_BIN and SU_OPTS variables.
  • Fix a problem in the WrapperSimpleApp, WrapperStartStopApp, and WrapperJarApp helper classes where command line problems that resulted in the JVM exiting on startup looked like unexpected exits. This meant that the Wrapper would try to relaunch the JVM again rather than giving up on the first attempt.
  • Modified the WrapperSimpleApp, WrapperStartStopApp, and WrapperJarApp helper classes so that their usage banners will only now be shown for command line related problems. Issues with the specified classes, methods, or jar files are still logged as errors, but showing the user the usage in these cases was confusing.
  • Correct the WrapperResources.getString() method that has no replacement arguments so that its processing of the raw string is handled the same as methods which have replacement arguments. Now all strings are processed by the MessageFormat class before being returned. Previous versions were not consistent about the need to escape single quotes.
  • Added optional key validation to make sure that strings passed in to the WrapperResources.getString() method are formatted correctly. See the WrapperResources class for information how to enable.
  • Add new options for property wrapper.backend.type: AUTO, SOCKET, SOCKET_IPv4, SOCKET_IPv6, PIPE. When set to AUTO, the Wrapper will try to open a socket ipv4 and fallback to ipv6 and to pipe in case of error.
  • Fix bug when converting from multibyte to wide char without setting the locale at startup (Unix only). Thanks to Bert.
  • Add a 'CLOSE_BACKEND' alias to 'CLOSE_SOCKET' as a test command for the wrapper.commandfile property. This is because there have been multiple options for the backend connection for some time and the name is more portable.
  • Fix a problem on Mac when running OS X Yosemite where the script was failing to correctly compare versions '10.10' to '10.5.0'. This was leading to the script thinking that only 32-bit binaries could be run. This was only an issue if the delta pack naming of the wrapper binaries was being used.
  • Add a new wrapper.java.classpath.missing.loglevel property which makes it possible to control how the Wrapper logs warnings about missing classpath elements. Previously this was always logged as debug output and could not be disabled.
  • If there are any low level problems launching the Java process that are not related to configuration or the JVM itself, the Wrapper will no longer try again as such retries were meaningless.
  • Windows system APIs have a problem that cause a process to crash if it attempts to set an environment variable over 32767 characters in length. The Wrapper now checks for this and logs an error rather than setting the variable. This was a problem if very large classpaths were used when the wrapper.java.classpath.use_environment property was TRUE.
  • Windows does not allow a command line to be longer than 32766 characters in length. Different versions of Windows handle it differently when such a long command is provided. The Wrapper now does its own check and shows an error in a consistent way.
  • Improve the error message on UNIX platforms when the command line is longer than the system maximum. This maximum varies greatly by platform and environment and is difficult to calculate reliably, so the maximum length is not currently shown in the message.
  • Fix a problem on UNIX platforms where a very large configuration file could cause the WrapperManager to fail to startup. This was caused by the partial transfer of the configuration file to the WrapperManager via the backend connection. This would happen regardless of the backend type used. The size of the configuration file that would cause a problem varied greatly based on the specific system.
  • Fix a problem on Windows platforms where a very large configuration file would fail to be sent to the WrapperManager on startup when the wrapper.backend.type property was set to PIPE. The only problem was that the WrapperManager.getProperties() method would be empty.(Professional Edition)
  • Add checks to the WrapperManager.exec() methods on Windows for the maximum command line length of 32766, and maximum environment variable name-value pair length of 32767.(Professional Edition)
  • Fix a problem where a free of a NULL pointer was being done as part of the cleanup process of a WrapperManager.exec() call. This is not known to have caused any issues.
  • Added getStdOut(), getStdErr(), and getStdIn() methods to the WrapperProcess class as aliases to the getInputStream(), getErrorStream(), and getOutputStream() methods to help avoid confusion.
  • Fix a problem on Windows 7 where long log lines got corrupted after 31397 characters when wrapper.console.direct was true. This seems to be a problem with the underlying Windows API and was only a display issue. Reduced the maximum number of characters that can be written with a single API call to 30000 to work around the issue. This change is internal and there is still no limit on the length of logged lines.
  • Fix a deadlock if the Wrapper failed to write to the backend when the wrapper.backend.type property was PIPE. Found by code review and is not known to have actually happened.
  • From Mac OSX 10.5.0, the script file will use the key 'KeepAlive' in the launchctl configuration file. Prior versions of Mac OSX will continue to use the same key 'OnDemand'. Thanks to Robin for pointing this out.(Standard / Professional Edition)
  • Disallow the use of hostids tied to Apple Bluetooth devices when running on a virtualized Windows system hosted on an OS X system.
  • Fix a problem where WrapperManager.log() was not working correctly when multi-byte messages were logged.
  • In the debug output the full configuration properties packet is suppressed from the log output because it is huge and can contain sensitive data. Add a size to the abbreviated output to assist with debugging.
  • Fix a memory leak on UNIX platforms whenever an error message was reported. This was only a problem if the message was logged repeatedly.
  • Correct a couple other potential memory leaks found through code review. Not known to have been causing any actual problems.

New in Java Service Wrapper Community Edition 3.5.23 (Jan 10, 2014)

  • Standard / Professional Edition:
  • When an unknown license type is encountered, include the unknown type in the error message to help with debugging.
  • Fix a memory corruption problem on z/OS when the language was set to a double byte locale like Japanese.
  • Go through and make the Wrapper much more durable when badly encoded double byte characters are encountered.
  • Preofessional Edition:
  • Modify the exception thrown when WrapperManager.exec() is called while the Wrapper is shutdown so it now says that rather than saying that the native library is not loaded.
  • The Wrapper is now more careful to make sure that the backend is never closed while a child process is being launched to ensure that the Wrapper knows about all child processes launched.
  • Add a warning message in case the Wrapper is not notified of a launched child process due to the backend connection being closed.
  • Fix a potential NPE that could be thrown while reading stdout or stderr output from a child process while the Wrapper was shutting down and after the child process exited.
  • Fix a problem on UNIX platforms where we were getting stuck trying to cleanup after a process which was currently blocking on a read from stdout or stderr.
  • Fix a problem on UNIX platforms where a timeout attempting to obtain an internal lock of the child process list was causing an internal counter to get out of sync, leading to a other terminated child processes being left as defunct zombies until the Java process terminated.
  • Fix a problem on UNIX platforms where pipe file descriptions used to communicate with child processes were being incorrectly passed to all child processes. They were not growing over time.
  • Fix a problem on FreeBSD systems where the wrapper.lang.encoding was not resolving to UTF-8 correctly when the LANG environment variable was not set.
  • Fix a potential synchronization problem calling WrapperProcess.waitFor() or WrapperProcess.exitValue().
  • Add additional debug log output showing the various timeout values to help with debugging user issues.
  • Fix a problem where the shell script was not correctly detecting the OS version with Mac OSX Maverick.
  • Add warnings about undefined environment variables in include file references in the configuration file.
  • Add support for environment variable expansion in files specified with the wrapper.java.additional_file and wrapper.app.parameter_file properties.
  • Correct the integer formatting in the WrapperUNIXGroup.toString() method so it is consistent with the rest of the Wrapper.
  • Fix a problem where the iconv library requirement couldn't be satisfied in FreeBSD 10. We now locate the library dynamically by looking for /usr/local/lib/libiconv.so, /usr/local/lib/libbiconv.so, or /lib/libkiconv.so.4 in that order.
  • Fix a the WrapperPrintStream.println() method so strings containing linefeeds will correctly have each line prepended with the configured header.

New in Java Service Wrapper Community Edition 3.5.14 (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 Community Edition 3.5.11 (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.
  • (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 Community Edition 3.5.9 (May 11, 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.

New in Java Service Wrapper Community Edition 3.5.8 (May 4, 2011)

  • (Standard / Professional Edition)
  • 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.
  • (Standard / Professional Edition)
  • 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.
  • (Professional Edition)
  • 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)

New in Java Service Wrapper Community Edition 3.5.6 (Oct 18, 2010)

  • Fix a problem on UNIX platforms where the log file path was being calculated incorrectly if an absolute path was specified for wrapper.logfile, and the file did not already exist. A warning message was being displayed but the Wrapper would continue using the default log file. There was a problem in the message displayed which caused a crash on some platforms include Mac OSX. Introduced in version 3.5.5.
  • 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 version 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 version 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 version 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 dir 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 version 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.
  • (Professional Edition)
  • 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.
  • (Professional Edition)
  • Fix a problem where the output of the wrapper.event.< event_name >.message and wrapper.event.< event_name >.loglevel properties were not displaying correctly on UNIX platforms.
  • (Professional Edition)
  • Fix a problem on UNIX platforms where the Java side of the Wrapper was not being correctly notified if a large number of child processes that had been launched with WrapperManager.exec(), exited at the same instant. Some of them were going into a defunct state until the next child exited, at which point they would be cleaned up. This was mainly an issue on JVM shutdown if the user code was calling WrapperProcess.waitFor() as part of its shutdown process. WaitFor calls at any point were getting stuck and would remain so until another child exited. As part of this fix, there were also several changes to the Windows implementation to bring the two code bases into sync.
  • (Professional Edition)
  • 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.
  • (Professional Edition)
  • 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.
  • (Standard / Professional Edition)
  • Remove the undocumented ability to define a single file share mapping without the index. This would cause confusion if used, and complicated the code.
  • (Standard / Professional Edition)
  • 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 version 3.3.7, but is not known to cause any other issues.
  • (Standard / Professional Edition)
  • 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 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.

New in Java Service Wrapper Community Edition 3.5.5 (Oct 5, 2010)

  • This version includes a number of important new features, including filter wildcards, support for Windows Service Manager recovery features, argument pass through to JVM, and much more.
  • This version also include a few important fixes.

New in Java Service Wrapper Community Edition 3.5.4 (Aug 31, 2010)

  • 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.

New in Java Service Wrapper Community Edition 3.5.3 (Aug 4, 2010)

  • Starting with version 3.5.0, the Wrapper has been switched internally to use Unicode. This has the benefit of making it possible, for the first time, to offer fully localized versions of the Wrapper, and to use any language when defining property values. There was very little of the code which was not affected by this change, so we are still working all the issues out.

New in Java Service Wrapper Community Edition 3.5.2 (Jul 21, 2010)

  • This release includes several important features, including automatic dead lock detection, internal Unicode and localization, JVM pause and resume, customer user events, and much more.
  • Several important bugs were fixed.
  • There is now a full-featured 15-minute trial license that lets you run quick tests without the need to register for a trial or purchase a license.

New in Java Service Wrapper Community Edition 3.3.6 (Aug 31, 2009)

  • This version includes the ability to use non-sequential numbered configuration properties, to set time zones for logging, to invoke triggered thread dumps, and much more.
  • There were also a few bugfixes and other minor features added.

New in Java Service Wrapper Community Edition 3.3.3 (Mar 8, 2009)

  • This version contains a few bugfixes as well as several new features, including the ability to integrate effortlessly with applications packaged as executable jars.