I have seen instances of a HashMap whose entries got circularly
linked, I assume, due to updates which where not thread safe.
Any thread using a get() on such a HashMap will spin forever
chasing its tail.
Cheers,
Larry
-Original Message-
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
-Original Message-
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 06, 2005 9:03 AM
To: Tomcat Users List
Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
On Tue, 2005-09-06 at 08:47 -0400, Larry Isaacs wrote:
I have seen instances
A simple test works for me. Are you accessing Tomcat 3.3.2
directly or through another web server?
Larry
-Original Message-
From: Code Rebel [mailto:[EMAIL PROTECTED]
Sent: Monday, August 22, 2005 8:39 PM
To: tomcat-user@jakarta.apache.org
Subject: Tomcat 3.3.2: Not able to
Tomcat 3.3.x differs from 3.2.x in a number of important respects.
It is likely you will have to port your customizations, rather
than just copy them. To do so, you should familiarize yourself
with the documentation, which may be found in your distribution
or online here:
There are too many differences and too many what ifs to
provide a practical upgrade document. You will need to
assess what features and customizations you are using now
in 3.2.2 and discover how the same thing or something
equivalent may be accomplished in 3.3.2. Some things will
be the same or
Thanks Jess for replying to this.
If I recall correctly the vulnerability was in the handling for
a request for status via the AJP12 connector which continues
to be used as the default shutdown mechanism. The report
mentions a new DOS attack, but fails to note that if a remote
attacker has
If you are running Tomcat with a security manager, you will need
to make sure the catalina.policy file includes permission for
your webapp to connect to the server in question. The examples
found in the comments at the end of the default catalina.policy
file are examples of such a permission.
/webapps/- {
permission java.net.SocketPermission 127.0.0.1:5432,
connect;
permission java.net.SocketPermission 127.0.0.1:5432,
resolve;
};
Unfortunately that still doesn't work...
On Tue, 18 Jan 2005, Larry Isaacs wrote:
If you are running Tomcat with a security manager, you
David,
-D defines System properties, -X defines vendor specific JVM options.
Thus, -DXms128M is incorrect. It should be just -Xms128M. Same for
the other -DX arguments.
Cheers,
Larry
-Original Message-
From: David Johnson [mailto:[EMAIL PROTECTED]
Sent: Monday, January 17, 2005
PROTECTED] wrote:
I'll give it a try. thanks!
On Mon, 17 Jan 2005 13:07:26 -0500, Larry Isaacs
[EMAIL PROTECTED] wrote:
David,
-D defines System properties, -X defines vendor
specific JVM options.
Thus, -DXms128M is incorrect. It should be just
-Xms128M. Same
See Bug 27648.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27648
Cheers,
Larry
-Original Message-
From: Montz, James C. (James Tower) [mailto:[EMAIL PROTECTED]
Sent: Monday, October 11, 2004 3:25 PM
To: [EMAIL PROTECTED]
Subject: allowTrace noSuchMethodException in Multiple
Hi Chuck,
I believe your difficulty at this point is due to a second
problem, which is that default error page only unwraps two
levels of exceptions. Your real problem is at the third
level or below, and the two levels that are displayed leave
you clueless as to what the real problem is. In
I believe you would need to set the backgroundProcessorDelay attribute
on the Engine element to -1 in server.xml if you wanted keep it
from generating a little bit of garbage every 10 seconds. I'm not
aware that this would disable anything critical (assuming you can live
without the auto, live
You may wish to consider Tomcat 4 or 5, which implement more
recent versions of the Servlet and JSP specs (with all their
new features). However, what is causing this odd problem with
Tomcat 3.3.2 could also cause problems for Tomcat 4 and 5
as well.
What is the contents of the jre\lib\ext
You would configure the HTTP Proxy Server to use a port different
from Tomcat's, say 8082. Then you would reconfigure your browser
to use as its proxy the machine and port that correspond to HTTP
Proxy Server, i.e. your machine name:8082. Then access Tomcat
with your browser as you would
The following comes from the Tomcat 3.3.x faq file, which I assume
would apply in your situation:
Q. I have a bean with a property whose second letter is capitalized.
Why won't my JSP page that uses this bean compile?
A. This may not happen often, but can be difficult to determine why.
If you want to use JMS, add a jar that just contains JMS classes.
Don't assume you can add any jar you want without side effects.
If you look inside j2ee.jar, you will find a ton of additional
classes besides those for JMS. Among them you will find an
older version of Tomcat which, not
I have installed OptimizeIt on one Windows system and deployed
the needed profiling runtime to a remote Windows system. I was
able to attach to and profile an application on the remote
system. I would assume you would be able to do the same with
a remote Linux system. The OptimizeIt 5.5 I
I believe JSTL expects JSP 1.2 support. Tomcat 3.3.x provides
JSP 1.1. I think the simplest choice to use JSTL is to upgrade
your Tomcat.
Cheers,
Larry
-Original Message-
From: Peter Bosmans [mailto:[EMAIL PROTECTED]
Sent: Friday, April 09, 2004 10:39 AM
To: [EMAIL PROTECTED]
You might try adding the JservConfig ... element to your server.xml,
documented here:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#JservConfig
You will likely need a current version of the mod_jserv connector. The
Windows binary can be found here:
You can try looking in your wrapper.properties file. At the
bottom the wrapper.cmd_line property is defined. This
property contains the command line used to fire up Tomcat.
Create a batch file containing this command line with all
substitutions manually resolved. If done correctly, then
this
I'm not a GC expert, so please note that the following
speculation is based upon memories of some GC document I
read a while back. I vaguely recall that GC performance
drops if the survivor space fills up while collecting the
young generation. I think the result is that what might
have been
: akashjauhar
AIM: akashjauhar
e-mail: [EMAIL PROTECTED]
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 12:39 PM
To: Tomcat Users List
Subject: RE: tomcat 3.3.1 takes a high time for Minor GC
I'm not a GC expert, so please
I think Yoav may have meant SESSIONS.ser. I'm not aware
of a name change for that file.
Note that there is an easy way to inadvertently put a
logger into the session. If a object being put in the
session tries to declare a static logger variable, but
leaves out the static, then an instance
In case it helps, the struts.jar from 1.1-b3, and I assume
earlier, had a MANIFEST.MF file that had multiple
Class-Path lines, which would lead to this symptom.
The 1.1 release version of struts.jar had this corrected.
I don't know about the Struts 1.1 release candidates.
You might check your
You can find it in the source .tar.gz or .zip here:
http://archive.apache.org/dist/jakarta/tomcat-3/archive/v3.3.1/src/
or if you want just this one file, try:
See the uriEncoding attribute described at:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/http.html
The same attribute applies to Tomcat 4.1.30 as well.
I'm not aware of any specs that guarantee behavior when using
non-ASCII characters in the URL in this fashion, but it might
work.
the standard for international character transmission over
the net, if it's not the standard already. And UTF-8 looks
exactly like ASCII for all the values in the ASCII range. Is
this something worth bringing up in the Tomcat-Dev group?
-ET
-Original Message-
From: Larry Isaacs [mailto
Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 11, 2004 1:23 PM
To: Tomcat Users List
Subject: RE: international filenames inaccessible
This has been discussed on tomcat-dev pretty thoroughly
already. Tomcat 4.1.27 and earlier were hard coded to
use UTF-8
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 19, 2004 12:47 PM
To: Tomcat Users List
Subject: RE: Servlet won't run init()
Howdy,
I tried overriding init() and super.init(SerlvetConfig cf)
as 1st line
of init(ServletConfig
Where exactly is the lib123.soap.sms.SmsDriverSOAP class
located (jar and directory) and where are the
org.apache.soap.* classes listed in the stack trace
located (jar and directory)?
Cheers,
Larry
-Original Message-
From: Xavier ANDRE [mailto:[EMAIL PROTECTED]
Sent: Thursday,
.soap.sms.SmsDriverSOAP and
org.apache.soap.* classes
Xavier André
-Message d'origine-
De : Larry Isaacs [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 15 janvier 2004 15:53
À : Tomcat Users List
Objet : RE: NoClassDefFoundError
Where exactly is the lib123
See the note at the bottom of this page:
http://www.apache.org/dist/jakarta/tomcat-3/bin/win32/i386/
Cheers,
Larry
-Original Message-
From: Dreamy Wu [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 11, 2004 4:49 AM
To: [EMAIL PROTECTED]
Subject: Please help me for jk_nt_service
There is a choice when pre-compiling JSPs.
1. Compile to real servlets. This involves precompiling
the JSPs to classes and adding mappings to the web.xml
so they execute just like other servlets. This
cuts the JspServlet out of the picture and the JSPs
are executed the same as other
To see what attributes are supported for Ajp13Connector, see:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#Ajp13Connector
I believe maxThreads will accomplish the same thing as
maxProcessors.
Cheers,
Larry
-Original Message-
From: Volker [mailto:[EMAIL PROTECTED]
Correct. If you do not need to serve HTTP requests,
Http10Connector may be removed. I would recommend just commenting
it out. If you encounter problems when accessing through Apache,
you can re-enable it easily to see if you get different behavior
directly accessing Tomcat.
Cheers,
Larry
I believe the point that Yoav was going to make was that
Tomcat 4.1.18 doesn't honor the unpackWARs Host setting when
using the Manager's deploy function. Thus it always serves
such a webapp from the WAR, for which the Manager undeploy
works. Tomcat 4.1.27 does honor the unpackWARs setting,
so
I believe the presence of sun.misc.Launcher$AppClassLoader.loadClass
in the stack suggests that your servlet is being found by the
classpath classloader. The javax.servlet.http.HttpServlet class
is found in the common/lib classloader, thanks to the servlet.jar
located in the common/lib directory.
In Tomcat 4 and earlier, there is servlet.jar, which contains both
servlet and JSP classes. In Tomcat 5, the servlet and JSP classes
have been split into servlet-api.jar and jsp-api.jar.
Cheers,
Larry
-Original Message-
From: Javier [mailto:[EMAIL PROTECTED]
Sent: Thursday, November
Since JDK 1.4.2 is being used, try the workaround specified
for (you will need to register to see the bug):
http://developer.java.sun.com/developer/bugParade/bugs/4895132.html
which is:
Specify -Dsun.io.useCanonCaches=false to the JVM.
Or, try JDK 1.4.1 which doesn't have the cannon cache
-Original Message-
From: Lemke, Michael IZ/HZA-IE5 [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 8:04 AM
To: '[EMAIL PROTECTED]'
Subject: TC 3.3.1: How to disable static access to *certain*
directories?
I want to serve a few static pages with standalone tomcat
* directories?
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 3:07 PM
To: Tomcat Users List
Subject: RE: TC 3.3.1: How to disable static access to
*certain* directories?
-Original Message-
From: Lemke, Michael
more question: How can I change the default page,
i.e., the one that displays when I just enter a path, from
index.html to something else?
Thanks again,
Michael
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 3:59 PM
In Tomcat 4.1.x, both CATALINA_OPTS and JAVA_OPTS do the same thing.
Settings placed in one would work the same if placed in the other.
Having the two allows you to be a little more organized by letting
you separate settings intended for the JVM from settings intended for
for the server.
In
The constructor being looked for exists only in the JSP 2.0
implementation. Your error implies that the TagAttributeInfo
class, found in jsp-api.jar in tomcat-5.0.12's common/lib
directory, is being overridden by an older JSP 1.2 or 1.1
version of this class, probably in a servlet.jar or j2ee.jar
I believe you will need JDK 1.3.1, or later, to get the -Xrs
option. It was added to fix the logout problem JDK 1.3.
Cheers,
Larry
-Original Message-
From: Ron Andersen [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2003 1:59 PM
To: [EMAIL PROTECTED]
Subject: Jav Options
the service.
Cheers,
-Original Message-
From: Ron Andersen [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2003 2:45 PM
To: Tomcat Users List
Subject: RE: Jav Options
Did I missed this from the setup doco, or is this(JDK1.4) missing :) ?
Larry Isaacs [EMAIL PROTECTED] wrote:I
Assuming you are referring to Tomcat 3.3.x, you need to also execute:
/usr/local/tomcat/startup.sh jkconf
prior to restarting Apache. This will update the mod_jk.conf used
to configure mod_jk. See:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html
for details about
See the JVM Options comment near the bottom of:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat/src/etc/jk/wrapper.properties?rev=1.4
which mention the -Xrs option.
HTH,
Larry
-Original Message-
From: Glyn Walters [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 09, 2003
ant make new jar files.
I couldn't find anything in the docs in that regard that I
could understand.
Thanks,
Michael
-Original Message-
From: Larry Isaacs
Sent: Monday, September 29, 2003 7:32 PM
To: Tomcat Users List
Subject: RE: Tomcat 3.3.1: AccessLogInterceptor doesn't
,
Michael
-Original Message-
From: Larry Isaacs
Sent: Tuesday, July 02, 2002 2:10 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat 3.3.1: AccessLogInterceptor doesn't log
PUT requests
AcessLogInterceptor writes the log entry using the
beforeCommit() hook. If no response
Do you really have:
import com.fgic.Utility.*
Utility util = new Utility();
If so, I don't think that import is doing what you hope for.
I think:
import com.fgic.Utility;
would work better.
Larry
-Original Message-
From: Boemio, Neil (GEI, FGI) [mailto:[EMAIL PROTECTED]
Unfortunately I did not have time to test this latest build prior to leaving on
vacation. I'm not sure what changed. I'll have to investigate when I get back this
weekend.
Cheers,
Larry
-Original Message-
From: Power-Netz (Schwarz) [mailto:[EMAIL PROTECTED]
I believe you can add:
jkWorker=my worker name
to your Listener ... to specify the name.
I think Bill Barker's port of the classes involved
is recent enough that the Tomcat 3.3. attributes
(not the server.xml element itself) are valid in the
Tomcat 4 ApacheConfig Listener. See the Tomcat
See:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/NT-Service-howto.html
Also see the note at the bottom of:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/win32/i386/
If using a relatively current Sun JDK, you can address this by
including at least -Xrs in the
This typically happens when the value for one of the parameters,
such as wrapper.java_home, contains a space. The parsing of
this file always assumes a space separates individual values,
and surrounding the parameter value with quotes isn't supported.
Make sure the parameters that specify a
Actually this appears to be the issue mentioned in the note
at the bottom of:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/win32/i386/
Cheers,
Larry
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2003 9:37 AM
There is no equivalent to Tomcat 4.x's Tomcat.exe install program
in Tomcat 3.3.x. However, you can install Tomcat 3.3.x as a
service by using the jk_nt_service.exe downloadable from here:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/win32/i386/
Be sure to read the note
Since it seems unlikely that you are using mod_ssl for
Apache 1.3, you would use mod_jk-3.3-ap13-noeapi.so. See
the diagram and architecture discussion near the middle of:
http://www.modssl.org/docs/2.8/ssl_overview.html
to see where EAPI comes from.
Cheers,
Larry
-Original
Tomcat 3.3.x doesn't have an equivalent to the .exe that
Tomcat 4 provides. To install, unzip the distribution
and create the short-cuts you want. It may not be as simple
as using the installer, but you will have more control over
which JDK(s) you use to run Tomcat and can have multiple
versions
I have this mostly fixed in my local source for Tomcat 3.3.2,
but have not yet committed the changes to CVS. The changes
will be present when Tomcat 3.3.2 releases.
Note that the security vulnerability is not in the server
itself, but in the examples webapp and the SnoopServlet
in the ROOT
Is it a typo that localhost:8080/intranettv doesn't match the
case in url-pattern/IntranetTV/url-pattern? It needs
to in order to work.
Cheers,
Larry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 8:08 AM
To: [EMAIL PROTECTED]
and IntranetTV is the servlet.
(that was the
way it worked in tomcat 3.2.1. Please tell me if that is wrong!)
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 1:17 PM
To: Tomcat Users List
Subject: RE: servlet not working on tomcat 4.1.18 - help
Based on the information you have specified, the URL:
http://knuddel:8080/servlet/shop
is incorrect. It should be:
http://knuddel:8080/shop/servlet/shop
and there should be a shop.class file (i.e. the servlet)
in /webshop/shop/WEB-INF/classes. Your web.xml doesn't
apply at this
There isn't enough information here to offer much help.
Not knowing what your web application is doing, it
can't be determined if this is a bug in Tomcat or a
bug in your web application.
You are welcome to give Tomcat 3.3.2-dev a quick try
to see if it behaves differently. You can find it
here:
(
ThreadPool.jav
a:516)
at java.lang.Thread.run(Thread.java:484)
Thank for your help.
Liquid
- Original Message -
From: Larry Isaacs [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, February 04, 2003 3:53 PM
Subject: RE: problem using Tomcat 3.3.1
I would assume the stack trace is different when using mod_proxy.
What does it look like?
Larry
-Original Message-
From: Liquid [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 11:15 AM
To: Tomcat Users List
Subject: Re: problem using Tomcat 3.3.1
In now using 1.2.2
This means that the class that Class.ForName() is trying
to load has a dependency chain that includes a class
that has a dependency on HttpSessionBindingListener, i.e.
servlet.jar.
That class with the servlet.jar dependency is being found
in a classloader that is below (i.e. a parent,) of the
:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 4:41 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat 3.3.1 HttpSessionBindingListener not found
Yep, adding servlet.jar to the classpath did the trick! Thanks!
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED
Larry Isaacs wrote:
I would assume the stack trace is different when using mod_proxy.
What does it look like?
Larry
-Original Message-
From: Liquid [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 11:15 AM
To: Tomcat Users List
Subject: Re: problem
().getContextClassloader().loadClass()
which might work better than Class.forName()
Filip
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:01 PM
To: Tomcat Users List
Subject: RE: Tomcat 3.3.1 HttpSessionBindingListener
not found
I am able to run it as a service without problems. Be
sure the note found at:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/win32/i386/
isn't what is keeping it from working.
For the mysterious shutdowns, you may want to try increasing
the log level to see if any clues
You will need to be aware of a little bit about how
classloaders behave. Tomcat will create a webapp
classloader that includes WEB-INF/classes and the jars
WEB-INF/lib. In Tomcat 3.2.x, a parent of this webapp
classloader is the CLASSPATH classloader. As the parent,
classes in the webapp
Tomcat 3.3.1a has been released to address the following two
vulnerabilities found in Tomcat 3.3.1 and earlier. This
includes Tomcat 3.2.4 and earlier.
Tomcat 4.0.4, 4.0.6, 4.1.12, 4.1.18, and 4.1.19 have been
checked and do not have these vulnerabilities.
Vulnerability where, when used with
Since the exception states that the problem servlet-mapping
is at line 14 (I'm not sure that refers to the beginning
or ending tag), I don't think this web.xml is the one with
the problem. Unfortunately, which web.xml isn't identified
by the exception. Perhaps additional information in the
log
Make sure the note at:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1/bin/win32/i386/
doesn't apply to your wrapper.propertes. If it does, modifying the
wrapper.jvm.options line to the following will fix it if you are
using JDK 1.3.1 or later:
wrapper.jvm.options=-Xrs
There doesn't appear to be anything wrong with the XML below,
assuming the '-' at the beginning of some lines are *not* in the
actual file.
Check the log output of Tomcat to make sure no problems are being
reported at startup and when tomcat receives the browser request.
Cheers,
Larry
I believe this means that the tools.jar being used is out
of sync with your JDK/JRE. Note that you state that you
installed 1.4.1_01 JRE, which doesn't include a tools.jar.
If you are using a tools.jar from a 1.3.x JDK, I think
you would get an error like this.
Cheers,
Larry
-Original
: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 15, 2002 07:11
To: Tomcat Users List
Subject: RE: Debugging JSPs using Tomcat 3.2.3 and NetBeans 3.3.2
Reading of the conf/web.xml go turned off for Tomcat 3.2.x,
though the file is still present. You should add the XML
Reading of the conf/web.xml go turned off for Tomcat 3.2.x,
though the file is still present. You should add the XML
below to the WEB-INF/web.xml for the webapps you want to
debug.
Cheers,
Larry
-Original Message-
From: Bruce Dahms [mailto:bdahms;netscape.net]
Sent: Thursday,
-Original Message-
From: [EMAIL PROTECTED] [mailto:afreire;banelco.com.ar]
Sent: Tuesday, November 05, 2002 7:19 AM
To: [EMAIL PROTECTED]
Subject: URGENT= Problem with Session Cookie
I'm using Apache with Tomcat 3.3.1.
I have a servlet with multiples instances. When I call it
on one of them or on a performance difference.
Tomcat 3.3.x is much faster than Tomcat 3.2.x.
Cheers,
Larry
Any idea.
Regards
Alejandro
Larry Isaacs [EMAIL PROTECTED] con fecha 05/11/2002 11:05:15
Por favor, responda a Tomcat Users List
[EMAIL PROTECTED]
Destinatarios: Tomcat
. It's work fine
in Apache
Tomcat without ssl but in ssl I have the problem.
Any idea.
Regards
Alejandro
Larry Isaacs [EMAIL PROTECTED] con fecha 05/11/2002 12:58:32
Por favor, responda a Tomcat Users List
[EMAIL PROTECTED]
Destinatarios: Tomcat Users List [EMAIL PROTECTED]
CC
For server.xml info for Tomcat 3.3, see:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_server
Cheers,
Larry
-Original Message-
From: Craig R. McClanahan [mailto:craigmcc;apache.org]
Sent:
The property name is case sensitive. Thus,
maxThreads=256
will work, but
maxthreads=256
won't.
Cheers,
Larry
-Original Message-
From: Nagesh Nayudu [mailto:nagesh;supportsoft.com]
Sent: Tuesday, October 22, 2002 9:52 PM
To: 'Tomcat Users List'
Subject: tomcat
If you aren't using a security manager and your webapps
don't need to change, you can remove the
ReloadInterceptor. This will save on calls to the
file system to see if class files, web.xml, etc. are out
of date. However, it's remove does mean that to pick up
any webapp changes, including JSP
It looks like you are using Ant 1.4.x. The improved War task
in Ant 1.5.x appears to address your issue with nested
lib classes webinf and metainf elements that specify
FileSets. For details, see:
http://jakarta.apache.org/ant/manual/index.html
Cheers,
Larry
-Original Message-
From:
ice form of starting Tomcat does not
use
start up scripts. Right? I want to make sure I
understand what we are saying here about the
scripts.
--- Larry Isaacs [EMAIL PROTECTED] wrote:
Like Tomcat4, Tomcat 3.3's startup scripts
ignore
your CLASSPATH. Tomcat 3.2
Like Tomcat4, Tomcat 3.3's startup scripts ignore
your CLASSPATH. Tomcat 3.2.x's use of the CLASSPATH
was one of the top sources of problems.
For important differences upgrading from Tomcat 3.2.x
to Tomcat 3.3.x, see:
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/readme
For how to configure
Tomcat 3.3.1 doesn't include parser.jar. You should
find crimson.jar and xalan.jar in lib/container. You
may place your jars there, removing crimson.jar,
and everything should work. Your xalan.jar and
xerces.jar will be automatically made available to
web applications by default, thanks to the
Forwarding to /../error.jsp should cause an error of some
sort every time since error.jsp is outside of the web
application. Perhaps ../error.jsp or /error.jsp was
intended.
Apparently, the invalid URI made it into DecodeInterceptor's
normalize method which isn't currently coded to handle
See the last item in the RELEASE-NOTES-4.1.txt file in your
Tomcat 4.1.12 installation.
Cheers,
Larry
-Original Message-
From: Zsolt Koppany [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 9:04 AM
To: [EMAIL PROTECTED]
Subject: resource not available error in
The commas in the DTD declaration for the web-app element
(i.e. the commas in (icon?,display-name?,...) dictate
that these elements *must* occur in the sequence specified.
The sequence of the resource-ref and servlet elements
in your web.xml *do not match* the DTD sequence specified
for the
Also, if you need .../servlet/class to invoke a particular
servlet, you can include a servlet mapping with /servlet/class
as the url-pattern to emulate invoker for that servlet.
This would avoid enabling invoker and exposing all servlets.
Cheers,
Larry
-Original Message-
From: Bill
Look at the documentation in conf/web.xml for classdebuginfo
init parameter, found just above:
...
servlet
servlet-namejsp/servlet-name
...
/servlet
Cheers,
Larry
-Original Message-
From: Christophe Marchand [mailto:[EMAIL PROTECTED]]
Sent: Thursday,
The default configuration of Tomcat 3.3.1 writes the needed
shutdown port number in conf/ajp12.id when it starts up.
By default, the shutdown handling tries to read it from this
file. What do you see for the contents of this file?
Cheers,
Larry
-Original Message-
From: Rafael
You will need to start with Tomcat 3.3.1's default server.xml
and add appropriate changes from your 3.2.4 installation.
The 3.2.4 server.xml isn't usable in 3.3.1, as is.
You can still define contexts in server.xml, but Tomcat 3.3.1
provides a better mechanism where they are placed in a separate
location? It was my
understanding that
it was system wide. I don't want my virtual hosts to be able
to see each
others classes.
Thank you VERY VERY much for your help,
Joshua Drake
Larry Isaacs wrote:
Hi Joshua,
Is there some reason you are not putting your bean class in
WEB
Hi Joshua,
Is there some reason you are not putting your bean class in
WEB-INF/classes where they would be picked up automatically?
In the majority of cases for Tomcat 3.3.x, the CLASSPATH is
the wrong place to put web application classes.
Cheers,
Larry
-Original Message-
From:
You can include a java.text.SimpleDateFormat string enclosed
within ${} in the path specification of LogSetter in
the server.xml. For example, the LogSetter for the
servlet_log in the default server.xml uses:
path=logs/servlet-${MMdd}.log
This causes a new log to be started each
1 - 100 of 638 matches
Mail list logo
