Costin Manolache wrote:
Bill Barker wrote:
At the moment (with the default settings), Tomcat 4.1.x and higher add
HTTP headers to non-SSL protected pages to prevent intermediate proxies
from
caching them. According to the HTTP/1.1 RFC (and even the HTTP/1.0 RFC),
POSTed pages are not allowed to
Alexander Leyke wrote:
Hi,
A question about enhancement adoption process - how long does it
typically take for new code to show up in CVS, in nightly builds? What
is the verification process for new code? I have posted enhancement
request to the mailing list and to Bugzilla
Tim Funk wrote:
Why is a kill done instead of a System.exit()?
System.exit() is a cleaner solution, but there are plenty of cases where
tomcat won't shut down at all with this solution, so a kill is needed
(either as suggested, or manually/externally). For example, I had a bug
in a webapp a
Yokota Takehiko wrote:
Hi, all.
There is a question about WebdavServlet in Tomcat4.1.12.
I tried to send MOVE request to WebdavServlet
and I expected that a file was moved, but it was copied and deleted.
I think org.apache.catalina.servlets.WebdavServlet#doMove() should
move resource instead
Remy Maucherat wrote:
Hi,
I was wondering about how expensive the Thread.setPriority method is,
and to which extent it does what it advetises.
Remy,
Thread.setPriority will (in a native threading implementation, rather
than something like the old green-threads JVM) be a system call, so it's
Scott Johnson wrote:
Hello,
We've got an application that is replicated for clients, each
replication runs in its own context. We're running jdk1.4.1, RH7.2,
Tomcat 4.0.6
Even though the application itself can run fine on 10mb RAM, as each
context initializes, EVERY thread allocates
Remy Maucherat wrote:
Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is
open in BZ). But, then again, I don't imagine that very many people
try and
use the Http10Connector in production, and Coyote is only available in the
nightly for 3.3
micael wrote:
I cannot see any difference relative to the invoker filter, ExampleFilter,
in the web.xml for Tomcat 4.1.10 versus 4.1.12. Nothing seems to be
commented out. I must be missing some point here. What is it?
The invoker servlet, whilst still defined in 4.1.12, has no
micael wrote:
I cannot access a webapp with the normal
http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat
4.1.12. (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except
that it won't access the examples servlets.) The error shown is a 404 The
requested
The DataSource factory wasn't setting maxIdle, and was incorrectly
setting maxActive
on the connection pool. This fixes it:
Michael
Index: DbcpDataSourceFactory.java
===
RCS file:
Here's a patch for clean builds on MSVC6 - includes a couple of missing
headers, and adds JK_METHOD attributes to the neccesary functions
(otherwise calling conventions are declared differently, and you get
compilation-fatal errors).
Michael Smith
Index: jk_channel_socket.c
for those.
Everything builds nicely under MSVC6 now.
Michael Smith
Index: jk_env.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_env.c,v
retrieving revision 1.3
diff -u -r1.3 jk_env.c
--- jk_env.c2001/11
[EMAIL PROTECTED] wrote:
costin 01/11/19 10:14:38
Modified:jk/native/common jk_registry.c jk_env.c jk_channel_socket.c
Log:
Patch from Michael Smith.
One change I didn't apply is the signature change in jk_env_objectFactory_t.
The problem with the worker_factory
[EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2001, Michael Smith wrote:
Ah. That'd be my misunderstanding of how things work...
_without_ that signature change, though, things still won't compile
(well, they probably will. With _really_ nasty warnings). I suppose the
right thing to do
Hi all,
I'm trying to set up tomcat4.0 (cvs, few days old), talking through
mod_jk (java bits compiled today from cvs, native bits the most recent
compiled version I could find - I don't have a copy of devstudio here)
to IIS (5.0, on win2k), using isapi_redirect.dll .
That bit works fine. Then
Yesterday I saw a bunch of 500 errors come up from a servlet we're
running.
Fortunately, it turned out that there was a full stacktrace in the log
file.
I think the error itself was due to transient network faults (or client
bugs)at the client end of things, so it's not a problem that tomcat
Last paragraph in the java.lang.String javadoc says:
The Java language provides special support for the string
concatentation operator
( + ), and for conversion of other objects to strings. String
concatenation is
implemented through the StringBuffer class and its append
method.
Since you've posted the URL again, I went back and read the initial proposal
again. Each time I read the proposal, I'm left with the same thoughts.
First, let me quote part Craig's message that started the thread and the
voting:
"To facilitate development of Tomcat 4.0, without compromising
18 matches
Mail list logo