Changes in upgrade http://src.iws.cs.ovgu.de/source/rss/forgerock/opendj2/resource/upgrade en Copyright 2005 Java svn merge https://svn.forgerock.org/opendj/trunk/opends@8851 https://svn.forgerock.org/opendj/branches/native-packaging@8851 . /forgerock/opendj2/resource/upgrade - a5b9f8fb834b1b2208e59a2fa76714bd91a5f147 violette 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. /forgerock/opendj2/resource/upgrade - 0f8553e2af5fc49a510ecfcfc93e66d06713f631 ludo Fix 3534: Provide native Solaris packages (fix also 3533: upgrade fails starting server adding entry ds-cfg-key-id) /forgerock/opendj2/resource/upgrade - d319724fed3be916a9f68676aac6eb203d44b551 chebrard These changes are separating the current delivery into an "Install Layout" (the binaries) and an "Instance Layout" (the user data). /forgerock/opendj2/resource/upgrade - 014019918f7e3844f558f6159b8d41517254edc2 lutoff Second part of fix for issue 3126 (Cannot run setup if unziped in directory with spaces in name). These changes allow to execute the scripts from different directories than the one the script is located at. /forgerock/opendj2/resource/upgrade - 3cedecd5ea21cca5d9709abf320a2082cd3694e5 jvergara Updated the copyright statement to reflect that Sun owns the full copyright on the project files. /forgerock/opendj2/resource/upgrade - a3d3ab94806056d2355afea6fe8daac41059b9fb ludovicp Fix for Issue 2782: New - Fail to launch upgrade CLI. Committed after validation of Q&A (Unai). /forgerock/opendj2/resource/upgrade - cf6c7da2cbe8b9c7704e00b37847b1363450ef3e jvergara 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. /forgerock/opendj2/resource/upgrade - 27f8adec83293fb8bd3bfa37175322b0ee3bb933 jvergara 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. /forgerock/opendj2/resource/upgrade - 37f9a536593b696e5a3dcec443e1475f22fb5afd jvergara 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 /forgerock/opendj2/resource/upgrade - bae806fb480fd70aa10de1cfdc7850ae6f95cb81 kenneth_suter fix for issue #1865 (upgrade -V error) In case on -V option, BuildExtractor will exit with a pre-defined return code defined in QuickSetupCli.java (let's say 50). Script will test this specific return value to check if the non-null return code is an error. In case of none null return code, the upgradeLauncher will not be called. /forgerock/opendj2/resource/upgrade - da7ab15aee42edf1c4ff33f66ca717f019b4a578 lutoff Revert the changes made in revision 2281 for issue #1865 because they have broken the graphical setup utility. With the changes committed in revision 2281, the setup dialog exits immediately with no error, most likely because of the introduction of a new System.exit calls. /forgerock/opendj2/resource/upgrade - 3e1849fdebc96bf4612c9f7b451e3665f7894dd8 neil_a_wilson fix for issue #1865 (upgrade -V error) In case on -V option, BuildExtractor will exit with a pre-defined return code defined in QuickSetupCli.java (let's say 50). Script will test this specific return value to check if the non-null return code is an error. In case of none null return code, the upgradeLauncher will not be called. /forgerock/opendj2/resource/upgrade - 72a934fcad7386d17694fe2b8eb7c73fe20e55f9 lutoff 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. /forgerock/opendj2/resource/upgrade - f5bbd7023cc96dccff382d0f7911d356fcd9769d kenneth_suter 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. /forgerock/opendj2/resource/upgrade - 358aa64445313154ce8f5e0acca0966f5a40fa0b kenneth_suter This update to the script fixes a problem where the script would try to invoke the webstart version of the tool if there were any problems with the command line invocation (incorrect arguments etc). Now the webstart version will be launched only if there are no arguments passes to the tool. Otherwise the command line version is used. /forgerock/opendj2/resource/upgrade - a68203de3c573de383ff57dc62a62ef102344985 kenneth_suter fixed bug where upgrade does not function if started outside current directory /forgerock/opendj2/resource/upgrade - d18ac24c35f0fd0cd2414730ebce9edcfea8b47e kenneth_suter Restore changes that appear to have been accidentally reverted by the previous commit. /forgerock/opendj2/resource/upgrade - 6d0c16bde6a94d4c607a709e8515862aa4f333b7 neil_a_wilson changed classpath so that only jars from either the install root or staging directory are present in order to prevent the potential for classes from different builds from being loaded; cleaned up script file /forgerock/opendj2/resource/upgrade - cd7d96df207f896cf6bada3fdabb58d994387ce1 kenneth_suter 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. /forgerock/opendj2/resource/upgrade - 9da44d3de0a7180285a77b7e8d2426a72aca249e jvergara