Re: problem with classpath modification
* Steve Guo <[EMAIL PROTECTED]> [0211 07:11]: > > U must be using UNIX, although I have no experience with UNIX, but let me throw out > my thoughts at it. I use Tomcat 4.1.18 under Win200, no problem. > In general I do not modify .sh or.bat file, when I need to put something .jar into > the classpath of many webapps, I just do it using system variables (again windows). It's safer to stick it in CATALINA_HOME/common/lib , does the same thing I believe (that's how I installed PostGRESQL support in my webapps, anyway). And it's nice and portable too (across OSes, not servers). -- Nobody said computers were going to be polite. Rasputin :: Jack of All Trades - Master of Nuns - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with classpath modification
* William Claxton <[EMAIL PROTECTED]> [0221 05:21]: > We encountered an issue when adding a classpath entry to the Tomcat > (v4.1.18) 'setclasspath.sh' script. It so happens that the classpath entry > '/home/web/mediaware/WEB-INF/classes' is already accessible as a context, > but we need the classpath entry for some functions internal to our servlet. > When we add this classpath entry using 'setclasspath.sh', Tomcat seems to > loose its context. There are no errors in any of the startup logs, but > servlets located in '/home/web/mediaware/WEB-INF/classes' cannot run properly. STR there's some problem doing this, it causes different classes to be loaded by different classloaders. If /home/web/mediaware is a webapp directory, then classes in WEB_INF/classes will be searched, as will jarfiles in WEB-INF/lib - if you don't need moroe than that I'd undo your changes to setclasspath.sh, and spare yourself a lot of pain. -- Jone's Law: The man who smiles when things go wrong has thought of someone to blame it on. Rasputin :: Jack of All Trades - Master of Nuns - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with classpath modification
U must be using UNIX, although I have no experience with UNIX, but let me throw out my thoughts at it. I use Tomcat 4.1.18 under Win200, no problem. In general I do not modify .sh or.bat file, when I need to put something .jar into the classpath of many webapps, I just do it using system variables (again windows). In your case, I just modify the classpath in the shell (DOS window), using set classpath=%classpath%;your_folder So this is a temporary change, next time the computer is on, it is lost. U can even put the above into a .sh file (setclasspath_tc) with parameters, so that setclasspath_tc myapp will do set classpath=%classpath%;c:\tomcat\webapps\myapp\WEB-INF\classes. For a lazy man like me, this has worked well. William Claxton <[EMAIL PROTECTED]> wrote:Since I didn't see any reply to my first post, let me try to restate, and simplify the issue. Interested readers may refer to the earlier post (same subject) for details. We encountered an issue when adding a classpath entry to the Tomcat (v4.1.18) 'setclasspath.sh' script. It so happens that the classpath entry '/home/web/mediaware/WEB-INF/classes' is already accessible as a context, but we need the classpath entry for some functions internal to our servlet. When we add this classpath entry using 'setclasspath.sh', Tomcat seems to loose its context. There are no errors in any of the startup logs, but servlets located in '/home/web/mediaware/WEB-INF/classes' cannot run properly. For a simple HelloWorld script located in this 'classes' folder, the failure exhibits itself as inability to find the HttpServlet service. This can be fixed if we also add the following entry to the classpath: /usr/local/jakarta/jakarta-tomcat-4.1.18/common/lib/servlet.jar: This seems odd. Why does adding an existing 'classes' folder to our classpath cause Tomcat to fail to find it's own supporting jar file? Incidentally, the added entry in our classpath also causes Tomcat to fail to find supporting jar files in '/home/web/mediaware/WEB-INF/lib'. Any ideas? Regards, Bill Claxton [EMAIL PROTECTED] OpenAsia Solutions provides streaming media & payment solutions. Check out http://www.openasia.net : - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
problem with classpath modification
Since I didn't see any reply to my first post, let me try to restate, and simplify the issue. Interested readers may refer to the earlier post (same subject) for details. We encountered an issue when adding a classpath entry to the Tomcat (v4.1.18) 'setclasspath.sh' script. It so happens that the classpath entry '/home/web/mediaware/WEB-INF/classes' is already accessible as a context, but we need the classpath entry for some functions internal to our servlet. When we add this classpath entry using 'setclasspath.sh', Tomcat seems to loose its context. There are no errors in any of the startup logs, but servlets located in '/home/web/mediaware/WEB-INF/classes' cannot run properly. For a simple HelloWorld script located in this 'classes' folder, the failure exhibits itself as inability to find the HttpServlet service. This can be fixed if we also add the following entry to the classpath: /usr/local/jakarta/jakarta-tomcat-4.1.18/common/lib/servlet.jar: This seems odd. Why does adding an existing 'classes' folder to our classpath cause Tomcat to fail to find it's own supporting jar file? Incidentally, the added entry in our classpath also causes Tomcat to fail to find supporting jar files in '/home/web/mediaware/WEB-INF/lib'. Any ideas? Regards, Bill Claxton [EMAIL PROTECTED] OpenAsia Solutions provides streaming media & payment solutions. Check out http://www.openasia.net : - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem with classpath modification
We encountered an issue when adding a classpath entry to the
'setclasspath.sh' script. Our environment is RH Linux 8, Apache 2.0, and
Tomcat 4.1.18. We have connected Apache and Tomcat, and moved our appbase
to another folder (not $TOMCAT_HOME/webapps).
We need to add a classpath entry in order to help our servlet *find
itself*. This sounds a bit funny, but the servlet reads a config file, and
parses its own tag library. In a traditional environment we would set an
entry in the classpath for our servlet, and a couple dependent jar files.
In our Tomcat 4.x environment, such configuration is done through XML
files. As it is, a 'HelloWorld' servlet runs fine in our 'classes'
folder, and dependent jar files can be found in our 'lib' folder. But our
own servlet cannot *find itself* to bootstrap the tag library.
So we tried to add the entry '/home/web/mediaware/WEB-INF/classes' to the
CLASSPATH by modifying the 'setclasspath.sh' script. But it caused us to
get various 500 errors - the supporting classes could not be found! Even
the 'HelloWorld' servlet cannot be found.
To overcome this issue, we make the following modification in the
'setclasspath.sh' file (the 'joinClassPath' function assures that any
existing classpath is inherited, and that there are no null entries in the
classpath):
# Set standard CLASSPATH
# CLASSPATH="$JAVA_HOME"/lib/tools.jar
joinClassPath() {
# adds string argument to end of existing classpath
if [ -z "$CLASSPATH" ] ; then
CLASSPATH=$1
else
CLASSPATH=$CLASSPATH:$1
fi
export CLASSPATH=`echo $CLASSPATH | tr '::' ':'`
}
joinClassPath "$JAVA_HOME"/lib/tools.jar
joinClassPath "$TOMCAT_HOME"/common/lib/servlet.jar
joinClassPath /home/web/mediaware/WEB-INF/classes
joinClassPath /home/web/mediaware/WEB-INF/lib/activation.jar
joinClassPath /home/web/mediaware/WEB-INF/lib/collections.jar
joinClassPath /home/web/mediaware/WEB-INF/lib/mail.jar
A test servlet, located in our 'classes' folder displays the resulting
classpath as follows:
Output - The classpath is:
/usr/java/j2sdk1.4.1_01/lib/tools.jar:
/usr/local/jakarta/jakarta-tomcat-4.1.18/common/lib/servlet.jar:
/home/web/mediaware/WEB-INF/classes:
/home/web/mediaware/WEB-INF/lib/activation.jar:
/home/web/mediaware/WEB-INF/lib/collections.jar:
/home/web/mediaware/WEB-INF/lib/mail.jar:
/usr/local/jakarta/jakarta-tomcat-4.1.18/bin/bootstrap.jar
With this change, our servlet runs fine, and is able to *find itself*
(using the 'classes' entry). But the question is this: all our servlet
really needs to see is its own directory in the classpath - why does adding
this single entry to our classpath cause Tomcat to fail to find our
supporting jar files, and especially its own servlet jar! Why is it
necessary for us to forcibly tell Tomcat the classpath for our jar files,
which are sitting in our web application folder (literally under
'/WEB-INF/lib')?
Thanks in advance.
Regards, Bill Claxton [[EMAIL PROTECTED]]
OpenAsia Solutions provides streaming media & payment solutions.
Check out http://www.openasia.net
:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
