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.

Fix for issue 2642 (ldif-diff doesn't detect differences in encoded values) The fix has three parts. 1. Currently the code of ldif-diff does not take into account the syntax of the attributes. Basically the comparison of values is a non-case sensitive String comparison. In order to be able to take into account the syntax of the attributes a config file must be provided to LDIFDiff. This is fixed by invoking _server_script instead of _client_script on the command-line scripts (ldif-diff and ldif-diff.bat). 2. There is a problem with the normalization in the org.opends.server.schema.UserPasswordExactEqualityMatchingRule class. Currently the normalized value in the case of an encoded password is the lower-case version of the value. For instance: value: {SSHA}cJNE9kjr52rZmttLaIrl4bOelWfvlM3Luk4Q7g== normalizedValue: {ssha}cjne9kjr52rzmttlairl4boelwfvlm3luk4q7g== The fix consists on only normalizing the encoding tag: value: {SSHA}cJNE9kjr52rZmttLaIrl4bOelWfvlM3Luk4Q7g== normalizedValue: {ssha}cJNE9kjr52rZmttLaIrl4bOelWfvlM3Luk4Q7g== 3. If we load the configuration and we always use the schema check when reading the provided LDIF files, if those files are not compatible with the schema on the installation where they are being run, the ldif-diff will not work. In order to keep the current behavior (and thus accept LDIF files that are not compatible with the schema of the installation) a new argument has been added to the ldif-diff command-line (checkSchema). The user must provide this argument if a strict comparison of the values must be made. Adding this attribute allows to keep the current 'tolerant' behavior of ldif-diff, however it makes the use of the command-line a bit more complex. I personally think that having the possibility of running ldif-diff regardless of the schema overweights the problematic added complexity, but maybe someone disagrees (or has a better alternative than adding this argument). The changes in LDIFDiff correspond to the new argument.

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

2730: New - The setup command should perform some basic memory tuning Note: this issue is not fully covered by the proposed modifications but all that is missing in order to fix it is to figure out which are the default memory values that we want to propose in the setup. 2620: Server should be started as server JRE and clients should be started as client JREs The proposed solution goes beyond fixing the two issues and proposes a manner for the user to set specific java arguments (and use a specific JVM) for every command-line. Today the user can specify the JVM to be used using the OPENDS_JAVA_HOME environment variable and the java arguments by using the OPENDS_JAVA_ARGS environment variable. In the case of the JVM this covers most of the use cases (in general we will use the same JVM for all the command-lines). However this is quite limiting in the case of the java arguments we pass. For instance in general we want to run the server (start-ds command-line) using the server mode of the JVM but other command-lines using the -client mode of the JVM. In the same manner we might want to have a bigger heap when running the server than when we are running a "lightweight" utility as dsconfig. The proposed solution is to have a properties file called java.properties where the user specifies the different JVM and java arguments to be used for every command-line. Once the user has edited this properties file, (s)he must run a command-line called dsjavaproperties that will update all the scripts to use the arguments specified in that properties file. NOTE: there are a number of command-lines (import-ldif, export-ldif, backup, restore) where the user will be able to specify different java arguments (and different JVM) to use depending on whether the command-line is run in online or offline modes. You can see the comments on java.properties to get more information about this and in general about the different properties that can be set. The modification in the setup basically try to check if the JVM that is being used to run the setup (the one that will be used by default) supports the -client and -server options. Depending on the results of these checks the setup will update the java.properties file and then run dsjavaproperties to update the scripts.

Complete fix for 1252 restrict installed bin files to relevant platform. The bat files are only under 'bat' directory and some function scripts that are not targetted to be used by the user (_server-script, _client-script, etc.) have been moved now to lib.

Update all CDDL headers in source files to remove a typo.

Make a number of changes to administrative tools provided with OpenDS. These are all made under the umbrella of issue #994, but there are individual issues for each change. - Issue #979 -- Re-order LDAP tool arguments When displaying usage information for many of the LDAP tools (e.g., ldapsearch, ldapmodify, etc.), the arguments were not provided in any kind of logical grouping. This has been corrected so that the arguments are listed in a more logical ordering. - Issue #983 -- Add tool description to argument parser When displaying usage information for administrative tools, it now includes a small summary of what the tool does at the top of the argument list. - Issue #984 -- Make tool usage more compact Previously, the tool usage included a blank line between each argument, which made the usage information seem too verbose, especially for tools like ldapsearch with a lot of arguments. This extra space has been removed. Also, many of the argument descriptions have been rewritten in an attempt to avoid requiring multiple lines. - Issue #985 -- Wrap long output in administrative tools when appropriate Update most of the output for the administrative tools so that it is easier to read on 80-column displays. This primarily impacts error message, and cases in which the format of the output is important (e.g., LDIF output from ldapsearch) no changes were made. - Issue #986 -- Eliminate hard-coded strings in tools Some of the tools had hard-coded strings used for error and warning messages. They have been replaced with localizeable output from the messages files. - Issue #990 -- LDAP tools don't use trust store password The LDAP tools didn't provide any mechanism for specifying the PIN needed to access the contents of an SSL trust store. Some types of trust stores may require a PIN to access them, so it is now possible to either directly specify the PIN or to provide the path to a PIN file. - Issue #991 -- Disconnect when running stop-ds shouldn't be an error When using the stop-ds script, if the server began shutting down before it returned a response to the client, the client would provide an error message making it sound like something went wrong. The output has now been updated to indicate that the server is likely in the course of shutting down. - Issue #992 -- Tool usage should include the tool name rather than the class When displaying usage information for the administrative tools, the fully-qualified class name for the Java class was displayed, where the name of the shell script or batch file would have been more useful.

added extensionless shell scripts