Siram,
thank you very much for your reply. I think I wasn't specific enough. To put
my critique in a nutshell: if I set JAVA_HOME in the environment, there
oughtn't be a need to copy tools.jar in a /lib directory of tomcat.
There should neither be a classpath (which you explained are ignored by
tomcat) nor should there be any script settings necessary. The setting in
JAVA_HOME should simply be sufficient to make the jdk's jars available to
tomcat.
But that is not the case. Without copying tools.jar to
{tomcat_root}/common/lib and/or {tomcat_root}/server/lib it's not recognized
by tomcat and an exception is thrown. Was I clear?
Sincerely
Michael Kastner
----- Original Message -----
From: "Sriram N" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Sunday, January 27, 2002 4:52 PM
Subject: Re: Solution to sun/tools/javac/Main - Problem and some Critique
about classpath
> Hello,
> for anybody who has been running into this exception when trying to
> execute
> JSPs:
> javax.servlet.ServletException: sun/tools/javac/Main
> Heres the solution:
> tools.jar is not recognized when it's in classpath
> thus it must be copied to
> {tomcat_root}/common/lib
> and/or
> {tomcat_root}/server/lib
>
> The Tomcat startup scripts start up Tomcat in such a way that the existing
> CLASSPATH is ignored completely.
> They do this by creating another environment variable called _CLASSPATH,
which
> contains the default CLASSPATH variable's values, if any. The startup
scripts
> then proceed to assemble together a CLASSPATH which is used to start and
run
> Tomcat. This CLASSPATH contains only those Jars that are present in the
Tomcat
> sub-directory.
> Once this tomcat specific CLASSPATH is created, it is used to startup
Tomcat.
> Now, the ony other places from where jars/clases might be loaded is the
> %JAVA_HOME%/jre/lib/ext folder. The extensions Classloader, which is one
of the
> three Classloaders that work when the JVM comes up, loads all classes and
Jars
> that are present in this folder.
>
> If you next use the supplied shutdown scripts, then the default CLASSPATH
is
> restored, using the values fromthe _CLASSPATH environment variable.
>
> >My opinion:
> >I've been chasing down this problem for three days now, and all I could
> >find
> >in the respective mailing list databases was: put tools.jar in the
> >classpath. But that didn't work. Eventually I found the solution
> >mentioned
> >above - as I wrote - after three days.
>
> If the JAVA_HOME environment variable is correctly defined, then the
startup
> scripts correctly construct a Tomcat specific CLASSPATH environment
varialbe
> that includes %JAVA_HOME%/lib/tools.jar. If you have such an environment
> variable, and yet you have to copy tools.jar to a Tomcat subfolder, then
please
> check the value of this environment variable. For e.g. I have installed
JDK
> 1.3.1 at e:\jdk1.3.1 on my WinNT 4.0 system, and the value of the
JAVA_HOME
> environment variable on my system is e:\jdk1.3.1\ (with the trailing
> backslash). This constructs the correct CLASPATH for me, which includes
the
> tools.jar.
>
>
> >Ever since I started working with java and that was four years ago, the
> >classpath has been a problem in java. I would expect that in the
> >meantime
> >the directory structures would be sufficiently standardized and thus
> >make
> >_any_ classpath settings unnecassary. Once JAVA_HOME and/or JAVA_PATH
> >are
> >set the environment should be defined.
> >But that's not the case. To make things worse, sometimes like in this
> >case,
> >the classpath settings are ignored. Who would have expected that
> >tools.jar
> >needs to be _copied_ to some other location? I wouldn't.
>
> While it might be frustrating to those who do not know that their
carefully
> constructed CLASSPATH is actually ignored by the startup scripts, this can
be a
> book actually. Quite a few Tomcat users have big unmanageable CLASSPATHs
and
> jars scattered all over the place, and supporting such setups via this
> mailinglist can be a real nightmare.
>
> >Because I wouldn't
> >expect _any_ developer of java and escecially java server applications
> >to
> >propose a configuration, where system jars are located in more than one
> >location. Thus maintenance of the system becomes a nightmare when a
> >system
> >update is due.
> >I just hate when that happens.
>
> The firm that I work for is soon going to deliver a some 6 web apps, all
of
> which will be running on Tomcat 4.0.1
> Because of the way Tomcat's startup scripts work, we are not particularly
> concerned with other jars etc that might be added to the system on a later
> date. And then what if the customer were to change the CLASSPATH
variable's
> values ? The way the startup scripts work right now, we are at least sure
that
> if there are any new Jar files, we know where to place them. And if there
are
> any conflicts in the future, either there's some foreign jar files in our
> Tomcat folder, or in %JAVA_HOME%/jre/lib/ext And no more worries about the
> CLASSPATH being changed, etc.
>
> If you'd indeed like the Tomcat startup scripts to refer to your system
jars,
> then you could customize the file catalina.bat (catalina.sh for unix
users) The
> place to do your customization is in the section titled
> "rem ----- Set Up The Runtime Classpath
> ----------------------------------------"
> You'll see here that the tools.jar is referred by the line
> set CP=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar
> If you'd like to support additional System libraries, say something
product
> called XYZ which is available at e:\XYZ\lib\xyz.jar,
>
> then you could add a line like this,
> set CP=%CP%;e:\XYZ\lib\xyz.jar
>
> >Sincerely
> >Michael Kastner
>
> Sriram
>
> __________________________________________________
> Do You Yahoo!?
> Great stuff seeking new owners in Yahoo! Auctions!
> http://auctions.yahoo.com
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
