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

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.

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 commit address several related issues regarding the upgrader CLI: - After discussing the previously noninteractive option with Brian, I changed the CLI options somewhat. The new CLI design is to specify an interactive option (if interactivity is desired) rather than to have to specify non-interactivity. Additionally interactivity is only supposed to apply to gathering of required information and not whether or not and application is allowed to prompt for such things as continuation following an error. To suppress these sort of prompts you should specify the silent option. So the common plumbing (currently not used by setup or uninstall) now operates as described above and the upgrader now has a both silent and interactive options as described. - Make BuildExtractor a Launcher. BuildExtractor is a simple program used by the CLI for unzipping an OpenDS .zip file. Previously is was not very smart, relying on the Upgrader to report status and make sure the unzipping went OK. This had the unfortunate side-effect of making the scripts overly complicated resulting in issue 1772, and made it difficult to support interactivity. So the BuildExtractor has been made smarter so that it is capable of parsing the complete command line invocation, printing usage, and performing verification that it performed properly. - Addresses issue 1772 by simplifying and correcting the upgrade and upgrade.bat scripts.

mproves the amount of logging that is done in quicksetup applications. Much of what was simply relayed to the user as progress messages is not logged also. - Make the output of progress messages from various operations optional for applications. This is done to allow the upgrader to use the new abbreviated form of output while maintaining the other QuickSetup applications as the are currently. - Progress page now produces percentage completed messages for the build download step. - Disables parental loggers when setting up QuickSetup logs to prevent polution of the console by the root console logger.

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.

- There are 3 new classes for describing an instance of OpenDS: Installation which describes the filesystem, Status which can answer questions like 'is the server running' and Configuration which represents an instance of config.ldif. Part of the implementations of these classes were pulled from CurrentInstallStatus, Installer and Utils with some new methods to support upgrader needs. There is still some overlap in functionality that I don't like but my attempt at converting the exiting applications to use the new classes ran into problems so I leave that for a future exercise. - ServerController now holds the functionality for starting/stopping a server. - FileManager supports file management operations for copy and delete while handling event notification for applications. - Most of the functionality for the upgrader's file management tasks are here. Still left to do are functions related to configuration and schema migration.

These refactorings are essential in anticipation of a new quicksetup application for the upgrader feature (issue 598). These changes were reviewed by Josu. 1. Establish the concept of an Application (Install, Uninstall, Upgrade, Revert etc.) so that common drudgery (progress notification, message formatting, look and feel, user input, file management etc.) can be handled by a common base class (newly created AbstractApplication). 2. Establish clearly defined interface between the framework (QuickSetup) and the applications. 3. Replace classes currently defined in each application's package having lots of commonality with common classes (see new classes in org.opends.quicksetup). 4. Miscellaneous cleanup mostly handled by my IDE (fix Javadoc problems, optimize import statements etc.) This commit also: - made ProgressSteps an interface that the application specific enums implement. - moved the uninstaller specific user data back into a UninstallUserData object. For now I've left the installer's UserData to be more of a default since it has lots of properties I imagine would be useful for the upgrader. - added a new system property org.opends.quickstart.Application.class for specifying the application class of the Application to be instantiated. I've done this to remove some of the logic involved in determining which application to create in QuickSetup (if (isWebStart())..., if (isInstaller())...). The create-webstart-standalone script now generates this property as do the *Launcher classes. Applications are now created in the Application.create() method. - QuickSetup now creates the application during the init phase rather than waiting until the launch*. This so that the application can supply the user data necessary (specialized user data if necessary as is done by the uninstaller application).