svn merge https://svn.forgerock.org/opendj/trunk/opends@8851 https://svn.forgerock.org/opendj/branches/native-packaging@8851 .

Fix minor optimization proposed by FindBugs.

Fix for OPENDJ-222 : Renamed environment variables to OPENDJ_... Updated scripts so that if OPENDJ_JAVA_HOME and OPENDJ_JAVA_ARGS are not defined, we look at the legacy OPENDS_... ones.

Batch of changes that : - Update BDB JE to version 4.0.95 - Remove BDB logging configuration and definitely fix issue 4367 - Resolve issue 4523 - ACI and sub-entry caches not updated on replicas - Update the build factory to warn about generated messages on precommit - Resolve some issues in the Control Panel - Fix an issue with java.properties being ignored by some CLI

Fix a bunch of warnings mentioned by the IDE (most of them related to the non-use of generics).

fix incorrect svn revision and add svn url in start-ds -F

Fix for issue 3349 (fail to downgrade from build 16 to build 15) Even if the error code we get from the process is not 0 (this can be caused because it got blocked or interrupted through the space return we send to the terminal) check that we have the build information before reporting an error.

Fix for issues: 3238: On Windows, start-ds closes the Command Prompt window at exit 3240: Cannot revert after upgrade Use an environment variable to return the exit code in start-ds.bat without the parameter /B. By default it returns with the /B option so that the command prompt window is not closed. Appart from that update start-ds.bat so that we explicitly exit an error code.

Fix for issue 3131 (Windows: upgrade using the webinstaller should not hang) On windows write a carriage return in the output of the process to be sure that the process is not blocked.

Fix for issue 2919 (translation of version related properties causes error) The issue comes because we are parsing the output of a command-line and this output is localized. Since the option we are using is not part of the public interface. This information can be used not only by the BuildInformation class but also by the support team so it is better not to localize it. The fix consists of removing these properties from the properties file and define some String constants in SetupUtils so that can be shared by BuildInformation and DirectoryServer classes.

Updated the copyright statement to reflect that Sun owns the full copyright on the project files.

There was a flag day when the new security framework was added in build 1.0.0 build 6. The following changes address the issue. The main thing that has been updated are the changes at the end of VersionCompatibilityIssue. The problem is that the code relied only on the fact that a flag day was known (we register the flag days). However it can happen (as it is the case) that a flag day is registered in the code way after the changes occurred. So when we registered a flag day, systematically we could not upgrade from previous builds. For instance: a flag day corresponding to build 6 is registered now (candidate build 11). Without these modifications this would prevent to upgrade from build 7 or build 8 to the current build. That is why the new code actually checks the revision corresponding to the flag day and the revision of the new build. If the new build is newer than the revision of the flag day then we consider that there is no problem and we continue with the upgrade.

Fix for issue 1618 unable to install to folder with DN syntax. There is a problem in windows when we launch scripts using Runtime.exec if the script path contains a '=' character. The fix consists on quoting the script paths on windows when we launch them using Runtime.exec.

Fix for issue 2035 (Use OpenDS specific environment variables to determine the JVM to be used.) Use two environment variables to know which is the JVM to be used by the scripts: OPENDS_JAVA_BIN and OPENDS_JAVA_HOME. When the setup creates the file lib/set-java-home it writes the contents of OPENDS_JAVA_HOME to it (instead of JAVA_HOME which was the previous behavior). Before these changes, the scripts used to look for JAVA_BIN, then JAVA_HOME and finally for the contents of the set-java-home file. The problem with this approach is that if the user required to specify JAVA_HOME or JAVA_BIN to an unsupported version of the JDK (because some other program in the machine had this requirement) the scripts of OpenDS could not run. Now the checks that we do to figure out the JVM are done in the following order: 1. Check if OPENDS_JAVA_BIN is defined in the environment. 2. Check if OPENDS_JAVA_HOME is defined in the environment. 3. Check if OPENDS_JAVA_HOME is defined in the lib/set-java-home file. 4. Check if JAVA_BIN is defined in the environment. 5. Check if JAVA_HOME is defined in the environment. 6. Check if we can figure out the java installation by executing "type java" (in UNIX environments). If any of the above checks is positive, we will try to use the JVM found. Extras: the uninstall script on UNIX now checks that we are using a JDK compatible with 1.5 and displays a user friendly message if it does not.

Exposes the reversion functionality of the upgrader (issue 2169). Originally it was intended to be exposed as a new script but in order to avoid the negativity of having a command devoted to undoing the upgrade and to avoid more scripts in the top-level directory, I've exposed the functionality as 2 new options in the existing upgrade script. I will update the Wiki with documentation for these new options soon. In order to support custom return codes for quicksetup applications I've overhauled the class formerly called ApplicationReturnCode, converting the inner enum to static instances of a new class ReturnCode. This change touched lots of file in a minor way. Also addressed here: - Interactivity for both the upgrade and reversion operations - Additional work needed to tie the reverter into the version issue (flag day) notification framework. - issue 2170 - upgrader emits NoClassDefFoundError following usage

This commit is a step toward getting OpenDS internationalized. There are still issues to be resolved before we can declare that we are internationalized but this commit covers the bulk of changes needed at this time. In general this commit converts any string values that might potentially be shown to an end user (client or administrator) to a new class called Message. This includes exception messages, error log messages, alert and email text, labels, and CLI output. Message's main interface includes methods for rendering itself as a string in the default locale using toString() or a specified locale toString(Locale). In addition to addressing localization, this would allow us to potentially support controls allowing clients to set a preferred locale for server communication or output log messages in different languages. Message extends CharSequence so it can be used in some places where strings are currently used with not code change (e.g. writing to a buffer) as well as allowing messages to be composed of one another. In order to create localized messages, instead of adding them to the *Messages.java class, you define them in the corresponding properties files. In general the property file keys are used to derive the new messages severity, category, and ordinal. There are directives that can be used in the properties file in order to avoid doing this however. For instance all the properties files used internally include the 'global.category' directive at the top of the file that instructs the generator to make all the following message belong to a single category. So for internal messages the property value key will be as follows: [SEVERITY]_[DESCRIPTION]_[ORDINAL] See the properties files themselves for more information. Once your messages are in the properties file you can use the ant target 'generatemessages' to create create MessageDescriptor objects that are referred to in the Java code. In the code you might think of these objects as replacing the int-valued message IDs. To create messages you call MessageDescriptor.get() which replaces MessageHandler.getMessage(). It might be helpful then to try to define your messages before referring to them in your code since until you run 'generatemessages' you won't have any Java-code with with to create your message objects. In order to support non-localizable text in messages (host names, DN's, etc.) Message's can be created from String values by calling Message.raw(String). In this way it is also possible to circumvent the intention of changing the APIs to use Message objects instead of Strings which is to support writing of localizable messages. This method is currently used in the code as a crutch for areas of the code that need internationalization (tagged with a 'TODO: i18n' comment). It might also be used by 3rd party developers that don't intend to localize their products. However for internal use we should not be using this method to create Messages for text that is locale sensitive. Additionally this code includes a MessageBuilder that can be used in much the same way that a StringBuilder can be used. It has a method toMessage() that can be used to generate a message object when needed. At this time this method just converts the buffer contents to a raw, unlocalizable message so this will need to addressed in the future. Some other issues: - While all of the unit tests pass after this commit, there may be issues in the code where we have no or minimal test coverage. This includes much of the setup and GUI tools packages for which I have not done any testing but will begin after this commit. - The new message related Java sources are contained in package org.opends.messages and organized in a new module src/module modeled somewhat after the admin module: src/messages/src (non-generated Java source files) src/messages/generated (generated source files) src/messages/messages (properties files for messages) If you run the code from within your IDE you will have to mark all messages/src, messages/generated and messages as source directories. - To generated the MessageDescriptor files you invoke the 'generatemessages' target. - If you run the code from within your IDE you will probably ne - This commit would change the plugin API. Here are the changes caught by DirectoryServerPluginTestCase: doShutdown(String)->doShutdown(Message) doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,int,String) -> doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,Message); - This commit aligns the entire code-base behind the new Formatter class (printf style formattings like %s) as opposed to the older MessageFormat style (using curly braces for message arguments). This allows us to provide more type safety for message arguments. So for instance you can include a %c argument specifier in your format string and the MessageDescriptor will enforce specification of a Character as message creation time. - Not all of the config framework has not been converted to use Messages. Perhaps as some point we might have a 'message' syntax for locale-sensitive textural data. I'm sure Matt will have ideas about this. - In addition to Message, MessageDescriptor and MessageBuilder, the org.opends.server.message package includes enums for Category and Severity that replace the definitions formerly found in MessageHandler. - The interface for the ErrorLogger has been simplified to allow logging of messages using a single Message parameter. The severity and category of the message will be derived from the Message itself instead of specified as arguments when a message is logged. - I will provide more documentation about this plumbing on the Wiki shortly. - I will expand on the included tests soon.

Partial fix for Issue 2026: installer should ensure 1.5 or later JAVA_HOME setting. Force the processes launched by the installer and the upgrader to use the same JVM as the tools (th is is done by setting the JAVA_HOME environment variable when creating the processes).

modifications to fix issue #2022. These modifications also include a new ReturnCode definition: QuickSetupCli return code and ApplicationExceptionType have been grouped into a new class: ApplicationErrorCode. Return code are now handled as emun. In order to fix issue #2022, CANCELLED value is 0 (SUCCESSFUL).

This initial implementation lays most of the groundwork necessary for signaling information and actions to the user during upgrade and reversion. However the only public effect this code has on the current upgrade tool is an informational dialog dialog if an upgrade is attempted from a build prior to one of the issues (2049, 1582, 890). With this commit: - start-ds -F now advertises 'Upgrade Event IDs' which are the IDs of issues defined in VersionCompatibilityIssues that theoretically would have been encountered up to the current build. - As mentioned above VersionCompatibilityIssue defines an issue and serves as the repository for issues. I tried to provide as many comments as possible to make it apparent how to define issues in the future. - The upgrader's VersionOracle is responsible for correlating the version issues with actions to be taken by the upgrader or yet-to-be implemented reversion tools and presenting them to the user during the operation.

The commit insures that in all cases instantiation of ApplicationException is done with a localized message since this the message contained in this exception is exposed to end users. - A few instances of ApplicationException in Application.create() were converted to throw RuntimeException since the formerly thrown ApplicationExceptions were caught and converted to RuntimeExceptions anyway. End users will never see these exceptions unless there is something seriously wrong. - All other instances of hard-coded messages were put in the messages properties file.

The upgrader writes a log in the history directory that contains information about attempts to upgrade and contains references to the current and upgrade build. Formerly these were SVN revision numbers which is not very informative to humans. This commit writes the build's major, minor, point and revision numbers in the historical log.

This commit removes the Web Start version of the upgrader's ability to download arbitrary builds to be used for upgrading. Instead, the Web Start version of upgrade will be tied to the build version of upgrader. This is necessary after discovering that attemping to perform internal communication with the directory server when the DS bit and the upgraders bits are of different versions is problematic. - The Web Start upgrader will now need to be invoked by clicking an 'upgrade to this build' link presumably on the OpenDS website. We will need to think about how to present this to users. I've removed the ability of the 'upgrade' script to invoke the WebStart version of the upgrader. So at least for the time being, the upgrader scripts are CLI only. At some point it might be possible to have a command execute a GUI version. - Removed the Choose Version step of the upgrader although I have kept the UI classes for downloading the build in place since I presume this is something we will want to pursue at some point. It is now easy to determine the current future version of the build (since it matches the upgrader's version) and so the upgrader's Review Page has been fixed to always show the correct version of the build to which the upgrade will be performed. - InProcessServerController now throws an exception if the current version of OpenDS does not match the version of the installation parameter. - I have removed the initial pre-flight test that the upgrader was performing on the server before the upgrade. If you did not know, the upgrader would perform a check and refuse to upgrade a server that spit out error messages when started. Technically the check would need to be performed external to the JVM and I am not sure that our method for gathering log message spit out by the server is gauranteed to work on all platforms (Windows) and in all cases. At any rate, Brian though the check was unnecessary so I have disabled it. The upgrade still cancels if there are errors starting the server after the upgrade has been performed. - I have re-enabled adding of the upgrade scripts to the build. - I've updated the usage message for the CLI removing references to the GUI version of the tool as well as suggest visiting opends.org to use the web start version of the tool. - Externalized the exectution of the backup databases process.

This commit addresses several issues that Brian brought up regarding the upgrader. - Lots of label, dialog wording and layout changes. - The user is now warned if they try to close the upgrader window before it is finished. If the user indicates they want to cancel the operation the upgrader cleans up any filesystem changes that had been made to that point. - Added ability for progress panel to display HTML pre-formatted error messages as is currently possible for success messages.

added revision number to build info toString since it is used in messages to the user regarding build versions

This commit is mainly intended to prevent the sort of false positives that occur when the upgrader assumes the server has been upgraded properly but leaves the server in a corrupt state (see issues 1546 and 1559). The following changes are introduced: - An additional stipulation is put on successful completion of the upgrade process: early on in the process the server is started to see if it logs and severe messages upon startup. If there are any severe messages the upgrade tool won't run. Later when the upgraded server is being verified, the messages are checked again to see if there are any severe messages. If so the upgrade is aborted and any changes are backed out. The error message are returned from startServer methods in a new class OperationOutput. - The upgrade tool no longer allows a reversion to an older version and now checks to make sure the current version is older than the proposed version by comparing the major, minor, point, and SVN revision numbers obtained by running start-ds -F and storing the values in a new class BuildInformation. - The choose version screen now takes web proxy host and port from that standard system properties if they are set.