New Tomcat 4 installer nightly

[Remy Maucherat <re...@apache.org>]

Hi,

I did lots of updates to the installer script, and the result is available
here :
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/jakarta-tomcat-4
.0-20010716.exe

Changes from the first installer include :
- The JAVA_HOME env variable is no longer needed (instead, it looks in the
registry to get the JDK path).
- Includes the latest security fix.
- Added links to edit the config files.
- Won't delete the configuration and logs when uninstalling (unless you ask
the uninstaller to do so).
- Won't overwrite the configuration files if some are present. That makes
upgrading to a new build easier (but more work will be done in that area).
- Fix the minimum installation.

I think it's solid enough so that we can release the upcoming 4.0b6 packaged
with it.

Remy

Re: New Tomcat 4 installer nightly

[Christopher Cain <cc...@mhsoftware.com>]

Kevin Jones wrote:
> 
> > - The JAVA_HOME env variable is no longer needed (instead, it looks in the
> > registry to get the JDK path).
> 
> The problem with this is that when you install the JDK you end up with two
> JREs. So Java developers may have JAVA_HOME pointed at c:\jdk1.3.1 (say) and
> the registry is pointing at c:\program files\JavaSoft\JRE\1.3.1 (or
> similar). This means that adding jars to c:\jdk1.3.1\jre\lib\ext would not
> work if tomcat is looking for the JRE through the registry.
> 
> I would prefer to see a check for JAVA_HOME and if that's not set then look
> in the registry. Or, if both the registry and JAVA_HOME is set, offer the
> user the choice. If you've already done this then ignore my ramblings!

Yep. On my Win9x boxes, I usually end up setting JAVA_HOME it in my
autoexec.bat; so yes, my registry is probably wrong. And yes, I know
there is probably a better way of setting env variables, but most of us
non-Windoze types stick to what we know and don't poke around any
further than absolutely necessary. On my NT boxes, I set it in
Settings/Control Panel/Environment, and I have no idea where that goes
(probably registry, but who knows).

Anyway, I agree it probably would be best to give an env variable
precedence over the registry setting. I, personally, would go so far as
to say that it would be  expected behavior to simple use the env var
value (if present) without even checking the registry, as anyone who
manually sets that variable would presumably know what he/she is doing.
But I suppose that giving the user a choice would be another valid way
to go.

Just my $.02

- Christopher

RE: New Tomcat 4 installer nightly

[Kevin Jones <ke...@develop.com>]

> - The JAVA_HOME env variable is no longer needed (instead, it looks in the
> registry to get the JDK path).

The problem with this is that when you install the JDK you end up with two
JREs. So Java developers may have JAVA_HOME pointed at c:\jdk1.3.1 (say) and
the registry is pointing at c:\program files\JavaSoft\JRE\1.3.1 (or
similar). This means that adding jars to c:\jdk1.3.1\jre\lib\ext would not
work if tomcat is looking for the JRE through the registry.

I would prefer to see a check for JAVA_HOME and if that's not set then look
in the registry. Or, if both the registry and JAVA_HOME is set, offer the
user the choice. If you've already done this then ignore my ramblings!

Kevin Jones
DevelopMentor
www.develop.com

> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: 17 July 2001 06:10
> To: tomcat-dev@jakarta.apache.org
> Subject: New Tomcat 4 installer nightly
>
>
> Hi,
>
> I did lots of updates to the installer script, and the result is available
> here :
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/jakart
> a-tomcat-4
> .0-20010716.exe
>
> Changes from the first installer include :
> - The JAVA_HOME env variable is no longer needed (instead, it looks in the
> registry to get the JDK path).
> - Includes the latest security fix.
> - Added links to edit the config files.
> - Won't delete the configuration and logs when uninstalling
> (unless you ask
> the uninstaller to do so).
> - Won't overwrite the configuration files if some are present. That makes
> upgrading to a new build easier (but more work will be done in that area).
> - Fix the minimum installation.
>
> I think it's solid enough so that we can release the upcoming
> 4.0b6 packaged
> with it.
>
> Remy
>