On the risk to miss something,

if we run 2 tomcats, 
we have two JVM's running, 
AND
each is listening on a set of exactly defined ports 
this as per tomcat xml files used to configure each tomcat.

How about that?
On which port do you intend 
to talk to tomcat-6.0.26 and on which port do you intend 
to talk to tomcat-7.0.32

AND
CATALINA_HOME needs to be defined properly for each tomcat latest before 
you start the shell script. And what is about CATALINA_BASE? Do you run
your Tomcat launched in the context of you as user or i.e. in the context 
of the SYSTEM i.e. launched automatically when the system starts? Maybe
in a production environment tomcat-6.0.26 is launched automatically and
gets its setup parameters from CATALINA_HOME/..., while tomcat-7.0.32
is launched individually on a per user base taking its parameters from 
CATALINA_BASE/...

Please see catalian.sh and tomcat documentation for that

Josef

-----Ursprüngliche Nachricht-----
Von: André Warnier [mailto:a...@ice-sa.com] 
Gesendet: Donnerstag, 22. November 2012 09:06
An: Tomcat Users List
Betreff: Re: Running two different version of tomcat on the same server

Kent Cole wrote:
> I did exactly that.  I have tomcat 6.0.26 as my current production.  I 
> installed tomcat 7.0.32 to test my app on before migrating it.  I have 
> the following environmental variable in both .bash_profile and .bashrc
> 
> CATALINA_HOME=/var/apache-tomcat-6.0.26
> 
> When I run ./startup.sh from tomcat 7.0.32 bin, it cannot locate the 
> instance of tomcat 7.0.32.  What is the trick to get around this?  
> Should
> CATALINA_HOME=/var/apache-tomcat-6.0.26 reside in one of the startup 
> scripts?
> 
Hi.

This is more about running shell scripts under Linux, as about Tomcat itself.

First, I presume that you know that by running ./startup.sh from the 
command-line, in your own login session, you will be running Tomcat within your 
own shell environment and under your own user-id.  That is likely to be 
different from the way your other installed Tomcat is currently running.  There 
is nothing fundamentally wrong with this, just that you should be aware of the 
differences.

Second, what is missing above is probably an "export" of the shell environment 
variables which you set, like

export CATALINA_HOME=/var/apache-tomcat-6.0.26
  or
CATALINA_HOME=/var/apache-tomcat-6.0.26; export CATALINA_HOME

If you do not do that, then the value of the CATALINA_HOME environment variable 
(in your current shell session), is not "passed on" to the shell instance 
running the ./startup.sh script.  The startup.sh script thus starts with an 
empty or undefined CATALINA_HOME environment value, and in such a case it tries 
to determine one by itself, and may get the wrong value.

Thirdly : if you follow what the startup.sh script is doing, you'll see that it 
ends up running the catalina.sh script.  And this script runs the bin/setenv.sh 
script if it exists.  That is the "best" place to define variables such as 
CATALINA_HOME and CATALINA_BASE, because this script will be run no matter who 
runs the startup.sh script.
(In other words, if these variables are set in the setenv.sh script, then they 
do not depend on a value set in any specific user's login shell script.  Which 
of course may be what you want or not; but generally it is).

And fourthly : if you are installing Tomcat via your Linux distribution's 
packages and package manager, then all bets are off, because these packages 
redistribute Tomcat's files according to their own logic, and include their own 
startup/shutdown scripts which may or may not run the standard Tomcat 
startup/shotdown scripts, and may or may not set their own set of environment 
variables and have their own conditional logic.
Not that these packages do not work. They generally do, and they simplify the 
work immensely when it comes to install and maintain production systems.  But 
each Linux distribution has its own logic for this, and it is difficult for 
people on this list to know exactly how each of these packages works and 
provide help for them in a case like yours.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to