06491301493f728fbf77ce1935549c11edab2247 8878 |
|
17-May-2013 |
JnRouvignac |
OPENDJ-842 (CR-1699) On Windows, the setup command hangs when the length of the install path is too long
In order to avoid getting errors like "The input line is too long" on windows, a common way to fix this is to provide a "bootstrap" empty jar which contains only a MANIFEST.MF file listing all the application's jars in the "Class-Path" attribute.
This URL describes well enough the problem: http://ant.apache.org/manual/Tasks/manifestclasspath.html
build.xml:
In "prepackage" target, build bootstrap.jar.
_script-util.bat, _script-util.sh:
Replaced appending all the jars under libs with just the bootstrap jar.
Utilities.java, Utils.java, UpgradeUtils.java:
In getInstallPathFromClasspath(), extracted getInstallPath() and simplified its code a lot.
Installation.java, Installation.java:
Changed OPEN_DS_JAR_RELATIVE_PATHS into OPEN_DJ_BOOTSTRAP_JAR_RELATIVE_PATH. |
3095c6edab2372a46114aa8c54b273aab72641b7 8872 |
|
15-May-2013 |
JnRouvignac |
OPENDJ-842 On Windows, the setup command hangs when the length of the install path is too long
Code review: csovant
Jars now appear only once in the classpath (they were appearing twice).
INSTALL_ROOT and INSTANCE_ROOT represented the same absolute paths despite having different relative paths, resulting in the jars appended twice to the classpath.
After this change, the paths are using the absolute paths instead of the relative paths.
_script-util.bat:
Fixed jars appearing twice in the classpath |
b2c9e73be97c2f02bf35f28230901597d27963fe 5323 |
|
07-May-2009 |
jvergara |
Fix for issue 3971 (windows: setup should detect Java automatically)
The fix will improve the user experience in Windows when installing from a ZIP file. When the JVM is installed, the java.exe is contained in the PATH environment variable. The fix consists on trying to see if java.exe is on the PATH by calling java.exe -version if no OPENDS_JAVA_HOME nor JAVA_HOME environment variables are defined..
Note that even though this is an expensive operation in term of resources, this will only be called when the setup is launched for the first time. The setup will update the environment of execution of OpenDS and this call will no longer be made. The exception to this is the case where the user removes all the environment by deleting the files generated by the setup (or dsjavaproperties), this is done usually when the java environment has changed and the user has been told to do so (and also told to call dsjavaproperties). Once dsjavaproperties is called again (the normal procedure to configure the execution environment) this 'extra' call to java.exe will not be made in the scripts.
In other words, the fix will only have a performance penalty when the user calls 'setup' for the first time (and no OPENDS_JAVA_HOME or JAVA_HOME env variables are defined) and when the user resets the execution environment (and so is supposed to call dsjavaproperties). This small penalty (some extra tenths of a second) is acceptable because with the fix in most of the cases the user will not have to set OPENDS_JAVA_HOME (dealing with environment variables is a rare procedure for Windows users). As a result of this the user experience will be much smoother than what is today. |