You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Herrick, Rick" <Ri...@documentum.com> on 2002/09/11 05:29:12 UTC
Tomcat shared libraries
I'm currently in the process of developing a web application with Tomcat as
the default reference platform. Although we'll support running with BEA,
JRun, etc., our installer app will install and modify settings only if
you're installing for Tomcat. I have to make a decision on how to proceed
with our installer and really need to understand this problem.
Now the problem is this: Tomcat doesn't use libraries from anywhere but
within its scope. That is, it ignores the system classpath in its default
configuration. I've read the class loader how-to (which isn't really a
how-to, but whatever), and also worked with it for quite some time, so I
understand pretty well how it works. Basically your classes and JARs need
to be placed somewhere within the context of Tomcat: WEB-INF\classes,
WEB-INF\lib, $CATALINA_HOME/common/classes,
$CATALINA_HOME/common/endorsed/*.jar, $CATALINA_HOME/common/lib/*.jar,
$CATALINA_HOME/shared/classes, and $CATALINA_HOME/shared/lib/*.jar.
The problem is that this is a strictly web app-centric view of the world.
In fact, many of the libraries that we need to use from within our web app
are standard class libraries that other non-web applications need to use,
such as our main server product, our non-web client applications,
development tools, and so on. This leaves me three choices:
* Replicate the libraries in two places, one for non-web apps and one for
web apps (this solution, BTW, has to be cross-platform capable, so using
links is out). This is less than desirable because of the maintenance
problem with controlling versions.
* Place the primary libraries within the Tomcat context and refer the other
applications to that location. This doesn't work both for legacy and
upgrade reasons (i.e. if you've already got a server installed, it expects
to find its support libraries in a particular place and not have them moved
over to another location) and because it's nonsensical for a non-web-based
application to refer to an app server's repository.
* Mung around with the batch files and add the required directories to the
classpath for Tomcat.
I do the third. This works just dandy: my required libraries remain in
their central product-centric location, everyone can find what they need,
and there's only one version of the libraries around (well, it's a
development machine, so of course there's about 10 versions of every library
around, but *I* know where they are :^).
I browsed through the archives of this list and found the following quote:
From
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg64144.html:
"How do I add an existing jar to a servlet's classpath, if that jar doesn't
want to live under WEB-INF/lib? (I ultimately asked this here, and got a
solid "you can't" response, so I'm satisfied. However, I've seen this asked
here often, so it'd make a great FAQ submission."--Paul Brinkley
My question is, why is this so? Why is it that "you can't"? Since I know
you can in practice (by setting the CLASSPATH sometime after
setclasspath.bat nukes the system classpath or by removing setclasspath.bat
altogether), the prohibition seems arbitrary. Is there a security issue
with Tomcat doing class loading outside of the Tomcat context? It seems to
me that it's mainly due to a provincial view of a web app as a
self-contained entity, but in reality most of the people I know writing web
apps nowadays are running into *exactly* this sort of issue again and again.
So to make our installer work, at this point I'm actually moving the
existing setclasspath.bat file to some tmp name and creating a new one that
sets the CLASSPATH to what we need. Is there any problem with this other
than it's not cool to monkey with another product's settings?
Thanks for getting through all this! Any help or explanation is greatly
appreciated.
Rick Herrick, senior software engineer
CIS/TM
(303) 362-4892
Re: Tomcat shared libraries
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 8 Dec 2002, Dave Ford wrote:
> Date: Sun, 8 Dec 2002 12:38:31 -0800
> From: Dave Ford <df...@smart-soft.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Cc: Rick.Herrick@documentum.com
> Subject: Re: Tomcat shared libraries
>
>
>
> > Now the problem is this: Tomcat doesn't use libraries from anywhere but
> > within its scope.
>
> Rick, I was reading your discussion with Craig McClanahan and I agree with
> you - that a web app should be able to access classes outside the tomcat
> folder. Copying class into catalina/shared for each build is a pain (even
> with ant). Symlinks won't work on windows. Why couldn't tomcat add an entry
> into server.xml, to point to extra class location? Orion has had this for a
> few years now.
>
Before Tomcat went to the current policy of ignoring the CLASSPATH
variable (i.e. Tomcat 3.2), class path editing and understanding problems
were the #2 most popular issue on TOMCAT-USER, because a very large
percentage of newbies had real problems with them. (What's #1? it
remains problems configuring the web server connector.)
The current policy is straightforward and easy to understand, and that
whole class of problems has basically vanished. That tells me the choice
to be hard nosed was a good one.
> > * Mung around with the batch files and add the required directories to the
> > classpath for Tomcat.
>
> How exactly did you do this? What batch file?
>
The standard startup script ($CATALINA_HOME/bin/catalina.sh or
$CATALINA_HOME/bin/catalina.bat) delegate to a separate script
(setclaspath.sh or setclasspath.bat) to set up the system CLASSPATh and
other related variables. You can customize this as needed, but you're on
your own for figuring out class loader hierarchy problems, as well as
things like running out of environment space on Win98.
> Dave Ford
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat shared libraries
Posted by Dave Ford <df...@smart-soft.com>.
> Now the problem is this: Tomcat doesn't use libraries from anywhere but
> within its scope.
Rick, I was reading your discussion with Craig McClanahan and I agree with
you - that a web app should be able to access classes outside the tomcat
folder. Copying class into catalina/shared for each build is a pain (even
with ant). Symlinks won't work on windows. Why couldn't tomcat add an entry
into server.xml, to point to extra class location? Orion has had this for a
few years now.
> * Mung around with the batch files and add the required directories to the
> classpath for Tomcat.
How exactly did you do this? What batch file?
Dave Ford
Smart Soft - The Developer Training Company
http://www.smart-soft.com
----- Original Message -----
From: "Herrick, Rick" <Ri...@documentum.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, September 10, 2002 7:29 PM
Subject: Tomcat shared libraries
> I'm currently in the process of developing a web application with Tomcat
as
> the default reference platform. Although we'll support running with BEA,
> JRun, etc., our installer app will install and modify settings only if
> you're installing for Tomcat. I have to make a decision on how to proceed
> with our installer and really need to understand this problem.
>
> Now the problem is this: Tomcat doesn't use libraries from anywhere but
> within its scope. That is, it ignores the system classpath in its default
> configuration. I've read the class loader how-to (which isn't really a
> how-to, but whatever), and also worked with it for quite some time, so I
> understand pretty well how it works. Basically your classes and JARs need
> to be placed somewhere within the context of Tomcat: WEB-INF\classes,
> WEB-INF\lib, $CATALINA_HOME/common/classes,
> $CATALINA_HOME/common/endorsed/*.jar, $CATALINA_HOME/common/lib/*.jar,
> $CATALINA_HOME/shared/classes, and $CATALINA_HOME/shared/lib/*.jar.
>
> The problem is that this is a strictly web app-centric view of the world.
> In fact, many of the libraries that we need to use from within our web app
> are standard class libraries that other non-web applications need to use,
> such as our main server product, our non-web client applications,
> development tools, and so on. This leaves me three choices:
>
> * Replicate the libraries in two places, one for non-web apps and one for
> web apps (this solution, BTW, has to be cross-platform capable, so using
> links is out). This is less than desirable because of the maintenance
> problem with controlling versions.
>
> * Place the primary libraries within the Tomcat context and refer the
other
> applications to that location. This doesn't work both for legacy and
> upgrade reasons (i.e. if you've already got a server installed, it expects
> to find its support libraries in a particular place and not have them
moved
> over to another location) and because it's nonsensical for a non-web-based
> application to refer to an app server's repository.
>
>
> I do the third. This works just dandy: my required libraries remain in
> their central product-centric location, everyone can find what they need,
> and there's only one version of the libraries around (well, it's a
> development machine, so of course there's about 10 versions of every
library
> around, but *I* know where they are :^).
>
> I browsed through the archives of this list and found the following quote:
>
> From
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg64144.html:
> "How do I add an existing jar to a servlet's classpath, if that jar
doesn't
> want to live under WEB-INF/lib? (I ultimately asked this here, and got a
> solid "you can't" response, so I'm satisfied. However, I've seen this
asked
> here often, so it'd make a great FAQ submission."--Paul Brinkley
>
> My question is, why is this so? Why is it that "you can't"? Since I know
> you can in practice (by setting the CLASSPATH sometime after
> setclasspath.bat nukes the system classpath or by removing
setclasspath.bat
> altogether), the prohibition seems arbitrary. Is there a security issue
> with Tomcat doing class loading outside of the Tomcat context? It seems
to
> me that it's mainly due to a provincial view of a web app as a
> self-contained entity, but in reality most of the people I know writing
web
> apps nowadays are running into *exactly* this sort of issue again and
again.
>
>
> So to make our installer work, at this point I'm actually moving the
> existing setclasspath.bat file to some tmp name and creating a new one
that
> sets the CLASSPATH to what we need. Is there any problem with this other
> than it's not cool to monkey with another product's settings?
>
> Thanks for getting through all this! Any help or explanation is greatly
> appreciated.
>
> Rick Herrick, senior software engineer
> CIS/TM
> (303) 362-4892
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat shared libraries
Posted by Glenn Nielsen <gl...@mail.more.net>.
Craig R. McClanahan wrote:
> Tomcat 3.2 used CLASSPATH the way you are asking for. It resulted in
> CLASSPATH problems being the second largest catecategory of user problems
> (behind configuring web connectors, but only barely).
>
>
> Tomcat 3.3 and 4.x ignore CLASSPATH, and this category of user problems
> has basically vanished. Sounds like a smart move to me (especially since
> that was my choice, and I've adamantly resisted the idea of regressing
> back ever since).
>
> By the way, symlinks are the right answer to your dilemma (from common/lib
> to wherever the legacy JAR files are.
>
There is one potential problem with using symlinks, they won't work with
the Java SecurityManager for setting a security policy.
Perhaps installing those jars in $JAVA_HOME/jre/lib/ext would work.
That would be common across all the platforms.
> Craig McClanahan
>
>
> On Wed, 11 Sep 2002, Herrick, Rick wrote:
>
>
>>Date: Wed, 11 Sep 2002 05:29:12 +0200
>>From: "Herrick, Rick" <Ri...@documentum.com>
>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>To: "'tomcat-user@jakarta.apache.org'" <to...@jakarta.apache.org>
>>Subject: Tomcat shared libraries
>>
>>I'm currently in the process of developing a web application with Tomcat as
>>the default reference platform. Although we'll support running with BEA,
>>JRun, etc., our installer app will install and modify settings only if
>>you're installing for Tomcat. I have to make a decision on how to proceed
>>with our installer and really need to understand this problem.
>>
>>Now the problem is this: Tomcat doesn't use libraries from anywhere but
>>within its scope. That is, it ignores the system classpath in its default
>>configuration. I've read the class loader how-to (which isn't really a
>>how-to, but whatever), and also worked with it for quite some time, so I
>>understand pretty well how it works. Basically your classes and JARs need
>>to be placed somewhere within the context of Tomcat: WEB-INF\classes,
>>WEB-INF\lib, $CATALINA_HOME/common/classes,
>>$CATALINA_HOME/common/endorsed/*.jar, $CATALINA_HOME/common/lib/*.jar,
>>$CATALINA_HOME/shared/classes, and $CATALINA_HOME/shared/lib/*.jar.
>>
>>The problem is that this is a strictly web app-centric view of the world.
>>In fact, many of the libraries that we need to use from within our web app
>>are standard class libraries that other non-web applications need to use,
>>such as our main server product, our non-web client applications,
>>development tools, and so on. This leaves me three choices:
>>
>>* Replicate the libraries in two places, one for non-web apps and one for
>>web apps (this solution, BTW, has to be cross-platform capable, so using
>>links is out). This is less than desirable because of the maintenance
>>problem with controlling versions.
>>
>>* Place the primary libraries within the Tomcat context and refer the other
>>applications to that location. This doesn't work both for legacy and
>>upgrade reasons (i.e. if you've already got a server installed, it expects
>>to find its support libraries in a particular place and not have them moved
>>over to another location) and because it's nonsensical for a non-web-based
>>application to refer to an app server's repository.
>>
>>* Mung around with the batch files and add the required directories to the
>>classpath for Tomcat.
>>
>>I do the third. This works just dandy: my required libraries remain in
>>their central product-centric location, everyone can find what they need,
>>and there's only one version of the libraries around (well, it's a
>>development machine, so of course there's about 10 versions of every library
>>around, but *I* know where they are :^).
>>
>>I browsed through the archives of this list and found the following quote:
>>
>>From
>>http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg64144.html:
>>"How do I add an existing jar to a servlet's classpath, if that jar doesn't
>>want to live under WEB-INF/lib? (I ultimately asked this here, and got a
>>solid "you can't" response, so I'm satisfied. However, I've seen this asked
>>here often, so it'd make a great FAQ submission."--Paul Brinkley
>>
>>My question is, why is this so? Why is it that "you can't"? Since I know
>>you can in practice (by setting the CLASSPATH sometime after
>>setclasspath.bat nukes the system classpath or by removing setclasspath.bat
>>altogether), the prohibition seems arbitrary. Is there a security issue
>>with Tomcat doing class loading outside of the Tomcat context? It seems to
>>me that it's mainly due to a provincial view of a web app as a
>>self-contained entity, but in reality most of the people I know writing web
>>apps nowadays are running into *exactly* this sort of issue again and again.
>>
>>
>>So to make our installer work, at this point I'm actually moving the
>>existing setclasspath.bat file to some tmp name and creating a new one that
>>sets the CLASSPATH to what we need. Is there any problem with this other
>>than it's not cool to monkey with another product's settings?
>>
>>Thanks for getting through all this! Any help or explanation is greatly
>>appreciated.
>>
>>Rick Herrick, senior software engineer
>>CIS/TM
>>(303) 362-4892
>>
>>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat shared libraries
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Tomcat 3.2 used CLASSPATH the way you are asking for. It resulted in
CLASSPATH problems being the second largest catecategory of user problems
(behind configuring web connectors, but only barely).
Tomcat 3.3 and 4.x ignore CLASSPATH, and this category of user problems
has basically vanished. Sounds like a smart move to me (especially since
that was my choice, and I've adamantly resisted the idea of regressing
back ever since).
By the way, symlinks are the right answer to your dilemma (from common/lib
to wherever the legacy JAR files are.
Craig McClanahan
On Wed, 11 Sep 2002, Herrick, Rick wrote:
> Date: Wed, 11 Sep 2002 05:29:12 +0200
> From: "Herrick, Rick" <Ri...@documentum.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: "'tomcat-user@jakarta.apache.org'" <to...@jakarta.apache.org>
> Subject: Tomcat shared libraries
>
> I'm currently in the process of developing a web application with Tomcat as
> the default reference platform. Although we'll support running with BEA,
> JRun, etc., our installer app will install and modify settings only if
> you're installing for Tomcat. I have to make a decision on how to proceed
> with our installer and really need to understand this problem.
>
> Now the problem is this: Tomcat doesn't use libraries from anywhere but
> within its scope. That is, it ignores the system classpath in its default
> configuration. I've read the class loader how-to (which isn't really a
> how-to, but whatever), and also worked with it for quite some time, so I
> understand pretty well how it works. Basically your classes and JARs need
> to be placed somewhere within the context of Tomcat: WEB-INF\classes,
> WEB-INF\lib, $CATALINA_HOME/common/classes,
> $CATALINA_HOME/common/endorsed/*.jar, $CATALINA_HOME/common/lib/*.jar,
> $CATALINA_HOME/shared/classes, and $CATALINA_HOME/shared/lib/*.jar.
>
> The problem is that this is a strictly web app-centric view of the world.
> In fact, many of the libraries that we need to use from within our web app
> are standard class libraries that other non-web applications need to use,
> such as our main server product, our non-web client applications,
> development tools, and so on. This leaves me three choices:
>
> * Replicate the libraries in two places, one for non-web apps and one for
> web apps (this solution, BTW, has to be cross-platform capable, so using
> links is out). This is less than desirable because of the maintenance
> problem with controlling versions.
>
> * Place the primary libraries within the Tomcat context and refer the other
> applications to that location. This doesn't work both for legacy and
> upgrade reasons (i.e. if you've already got a server installed, it expects
> to find its support libraries in a particular place and not have them moved
> over to another location) and because it's nonsensical for a non-web-based
> application to refer to an app server's repository.
>
> * Mung around with the batch files and add the required directories to the
> classpath for Tomcat.
>
> I do the third. This works just dandy: my required libraries remain in
> their central product-centric location, everyone can find what they need,
> and there's only one version of the libraries around (well, it's a
> development machine, so of course there's about 10 versions of every library
> around, but *I* know where they are :^).
>
> I browsed through the archives of this list and found the following quote:
>
> From
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg64144.html:
> "How do I add an existing jar to a servlet's classpath, if that jar doesn't
> want to live under WEB-INF/lib? (I ultimately asked this here, and got a
> solid "you can't" response, so I'm satisfied. However, I've seen this asked
> here often, so it'd make a great FAQ submission."--Paul Brinkley
>
> My question is, why is this so? Why is it that "you can't"? Since I know
> you can in practice (by setting the CLASSPATH sometime after
> setclasspath.bat nukes the system classpath or by removing setclasspath.bat
> altogether), the prohibition seems arbitrary. Is there a security issue
> with Tomcat doing class loading outside of the Tomcat context? It seems to
> me that it's mainly due to a provincial view of a web app as a
> self-contained entity, but in reality most of the people I know writing web
> apps nowadays are running into *exactly* this sort of issue again and again.
>
>
> So to make our installer work, at this point I'm actually moving the
> existing setclasspath.bat file to some tmp name and creating a new one that
> sets the CLASSPATH to what we need. Is there any problem with this other
> than it's not cool to monkey with another product's settings?
>
> Thanks for getting through all this! Any help or explanation is greatly
> appreciated.
>
> Rick Herrick, senior software engineer
> CIS/TM
> (303) 362-4892
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>