Bug 50140 - Silent installation into wrong target directory
Summary: Silent installation into wrong target directory
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Native:Packaging (show other bugs)
Version: 6.0.29
Hardware: PC All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-21 12:54 UTC by Michael Hopf
Modified: 2014-02-17 13:47 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hopf 2010-10-21 12:54:47 UTC
Incorrect silent installation on Windows 2008 Enterprise:

Command: apachetomcat-6.0.26.exe /S /D=c:\tomcat

Tomcat files are copied to "c:\Program Files" instead of "c:\tomcat"
The installation works fine on Windows XP and Windows 2003 Server systems.
Comment 1 Mark Thomas 2010-10-21 14:01:47 UTC
That feature is provided directly by the NSIS installer.

I checked the NSIS bug tracker but couldn't find anything that looked like this issue.

You might want to test with 6.0.29 since that uses a slightly later version of the installer.
Comment 2 Michael Hopf 2010-10-22 03:20:39 UTC
Version 6.0.29 has the same problem. We are using a 64bit Windows 2008 Enterprise system. If you are sure that the problem is NSIS related, we can close this bug report. I will open a new bug report on NSIS side.
Comment 3 Konstantin Kolinko 2010-10-24 20:58:37 UTC
Reopening.

As Anders noted in a comment to bug 3092765 at Sourceforge [1], it is an issue with .onInit function in our tomcat.nsi.

[1] http://sourceforge.net/tracker/?func=detail&aid=3092765&group_id=22049&atid=373085


The problem is that when Tomcat is installed on 64-bit platforms, .onInit resets the value of $INSTDIR, thus effectively ignoring the value passed with /D commandline option. There is a patch suggested in [1].
Comment 4 Mark Thomas 2010-10-25 16:31:27 UTC
Thanks to the NSIS folks for pointing out our (probably "my" but I haven't check the history) error.

I'm currently looking into a patch for this that will also allow the 32-bit service wrapper to be installed on 64-bit windows if a 32-bit JVM is selected.

I should hopefully have finished testing this tomorrow.
Comment 5 Mark Thomas 2010-10-26 08:31:25 UTC
I have fixed this in trunk and proposed the fix for 6.0.x
Comment 6 Mark Thomas 2011-01-07 13:01:02 UTC
This (and a whole bunch of other improvements) has been applied to 6.0.x and will be included in 6.0.30 onwards.
Comment 7 Konstantin Kolinko 2011-02-02 12:58:00 UTC
This (and a whole bunch of other improvements) has been applied to 5.5.x in r1066549 and will be in 5.5.33.
Comment 8 Chris LeCompte 2011-08-11 18:30:44 UTC
This issue does not seem to address the case when the JRE is provided by a JDK installation.  In that case the HKLM "SOFTWARE\JavaSoft\Java Runtime Environment" key is not present, only a Java Development Environment key.  I found this whilst trying to perform a silent install using a 64-bit JDK (1.5.0_14) on windows 2008 server.  

A manual install is still possible but it does not auto detect the location there as well. The other work around is to install a JRE but that doesn't quite mesh well with the app I'm installing.