With this checkin I'm trying to lessen the occurences of ticket #474:
If a user installs I2P on top of an already existing I2P installation with the service
enabled, the installer will hang. The Quit button cannot be clicked. Clicking
the X in the corner seems to roll back the installation.
Also #472: service is not removed when I2P is uninstalled
for use with a 32 bit JRE.
Rationale:
On an x64 system using a 32 bit jvm Without the 32 bit libwrapper, messages
like this will be shown in wrapper.log with the wrapper in MTN & I2P >= 0.8.7:
-----------------------
Launching a JVM...
WrapperManager: Initializing...
WrapperManager:
WrapperManager: WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
WrapperManager: The file is located on the path at the following location but
WrapperManager: could not be loaded:
WrapperManager: $I2P/lib/libwrapper.so
WrapperManager: Please verify that the file is both readable and executable by the
WrapperManager: current user and that the file has not been corrupted in any way.
WrapperManager: One common cause of this problem is running a 32-bit version
WrapperManager: of the Wrapper with a 64-bit version of Java, or vica versa.
WrapperManager: This is a 32-bit JVM.
WrapperManager: Reported cause:
WrapperManager: $I2P/lib/libwrapper.so: $I2P/lib/libwrapper.so:
wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
WrapperManager: System signals will not be handled correctly.
-----------------------
With libwrapper.so removed, one sees the following:
WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the
WrapperManager: following files:
WrapperManager: libwrapper-linux-x86-32.so
WrapperManager: libwrapper.so
WrapperManager: could be located on the following java.library.path:
WrapperManager: $I2P
WrapperManager: $I2P/lib
WrapperManager: Please see the documentation for the wrapper.java.library.path
WrapperManager: configuration property.
WrapperManager: System signals will not be handled correctly.
-----------------------
The 32 bit lib names, when installed on an x64 system, will match the alternate
names that the wrapper looks for.
The Tanuki Software website states "64-bit Windows versions of the Java Service Wrapper
are not currently being made available in the Community Edition." The Makefile
for x86_64 is missing from the upstream tarball as well.
Well...included in this checkin is a diff against
$WRAPPER-3.5.9-SRC/src/c/Makefile-windows-x86-32.nmake (see the README in
installer/libs/wrapper/win64.
- removing from /build.xml
- moving recent changes from installer/resources/postinstall.bat to installer/install.xml
- dropping installer/resources/postinstall.bat
* Remove the last reference to my eepsite as a "news.xml" source,
and likewise stop my public key from being included
among valid release signing keys.
- Don't cd to script location, no longer required
* RouterLaunch:
- If no wrapper, put wrapper.log in system temp dir
unless specified with -Dwrapper.logfile=/path/to/wrapper.log
or it already exists in CWD (for backward compatibility)
- Append rather than replace wrapper.log
- Pass wrapper log location to router as a property, so that logs.jsp can find it
* logs.jsp:
- Get wrapper log location from a property too
* runplain.sh:
- Add path substitution to runplain.sh on install
- Pass I2P base dir to the router as a property
* wrapper.config:
- Put wrapper.log in system temp dir for new installs
- Pass I2P base dir to the router as a property
* WorkingDir:
- Don't migrate an existing install by default
- Never migrate the data (too hard)
- Change the wrapper.config classpath to one line: lib/*.jar
This means we lose control of classpath load order, so move the windows installer
jars copy.jar, delete.jar, and exec.jar to a new installer/ directory so
these jars won't be in the classpath or potentially conflict, since
copy.jar and delete.jar include FileUtil.class, and we don't want to have
to remember to add them to the updater if we ever change FileUtil.class.
Delete the installer/ directory in postinstall.sh since it is windows-only.
(previous izpack was 3.7.2 from 2005-04-22)
izpack 4.3.0 from :
http://dist.codehaus.org/izpack/releases/4.3.0/IzPack-install-4.3.0.jar
SHA1 f06da6b26ac2c68fed64ab38980352989b8d8841
(no signatures or sha1sums found on website, and the jar is unsigned)
License: Apache 2.0
upack izpack:
java -jar IzPack-install-4.3.0.jar
or
java -jar IzPack-install-4.3.0.jar -console
get the standalone-compiler.jar from the installation lib/ directory:
SHA1 6d2b4a5657bfb864a333b1c4b1c0f8223aa57d80
(no signatures or sha1sums found on website, and the jar is unsigned)
This fixes the bug with the install windows centered in all the
workspaces, not the current workspace. And who knows what other
bugs in the last 4 years.
To fix Vista (and presumably Windows 7) permissiom problems,
add a run-privileged flag for those, and run the new fixperms.bat
which calls icacls to add the privileges to the install directory.
Add support for 6 more language packs found in the new release.
Change from ISO3 codes to native language names.
Disable creation of the i2p.tar.bz2 file in build.xml
(distributed as i2pheadless-0.7.x.tar.bz2), as izpack 4.3.0 now
supports headless installation with java -jar i2pinstall.exe -console.
Update INSTALL.txt and INSTALL-headless.txt accordingly.
