DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4559.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Do you think that it would be smart and/or desirable to 'enforce' the
check for all people that use sessions with SSL? In other words, if you
have a TC session, and you're running things over SSL, we enforce the TC
session ID and SSL session ID match.
If there are security experts out there
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I am using poolman 2.1 with apache tomcat 4. The problem i am facing is that
connection pool is not accessible through jndi whereas in server window
poolman gives confirmation that pool is bound to jndi name. However
connection is available and working through Poolman class. I m really stuck
at
I am using poolman 2.1 with apache tomcat 4. The problem i am facing is
that connection pool is not accessible through jndi whereas in server
window poolman gives confirmation that pool is bound to jndi name. However
connection is available and working through Poolman class. I m really
stuck
Bill Barker at [EMAIL PROTECTED] wrote:
I know that Jon has already pointed out that Sun is going to sue the 3.x
branch out of Jakarta in five months,
I don't think Jon said that, and as a Sun employee I can guarantee that
Tomcat 3.x remains one of our strongholds AND the official servlet 2.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4520.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Thu, 1 Nov 2001, Antony Bowesman wrote:
Date: Thu, 01 Nov 2001 08:47:07 +0200
From: Antony Bowesman [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: J2EE 1.3/Tomcat/JAAS
Craig R. McClanahan wrote:
That
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4520.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
The following fix enables form-based authentication to work with
Apache + Tomcat.
Can someone add this to tomcat 3.2?
Thanks!
-Mike Jennings
Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java
===
RCS file:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Greetings All.
I have been following the mailing list for a while now and I had a question
regarding clustering support in Tomcat 4.0. We are looking at Tomcat as a
replacement for BEA Weblogic in our organization and one of the capabilities
we require is JDBC session persistence for a cluster
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4520.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
As far as I can tell, the following modification to the ApacheConfig.java class will
enable form-based authentication to work for people using mod_jk.conf-auto
with Apache.
mod_jk needs to be told to handle requests of the form
/webapproot/somedir/j_security_check
since a login.jsp page (for
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4520.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4571.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4520.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hello Apache / Cortexity:
I am a software engineer that works as an Enterprise Support Specialist at
MapInfo Corporation, which
is located in the United States of America. One of our main products
(MapInfo's MapXtremeJava4.0) ships
with TOMCAT3.2.2, and as of recent, we have been getting
remm01/11/01 09:59:45
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java HttpResponseStream.java
Log:
- If the client announced it was closing the connection, repeat the
connection: close in the response.
- Don't
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4571.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
As far as I know, that is a problem with Internet Explorer closing the
socket
prematurely on an http request.
Try hitting your servlet or JSP with a java.net.URL object
and see if you get the same error. Also try with Netscape.
My guess is that this bug is just how tomcat deals with
clients that
You can safely ignore this exception.
The explanation:
This is caused by the interaction between tc 3.2.X and ie4.0 and up, ie
abruptly breaks the connection when it finds a resource that it already
has in cache..
3.3 and up do not suffer this glitch ..
Saludos ,
Ignacio J. Ortega
I believe mod_jk's JkMount currently only accepts mappings in the
form:
JkMount /path/*
JkMount /path/*.ext
Something like:
JkMount /path/*something
is another way of saying:
JkMount /path/*
which makes the other settings written irrelevant since all
requests will be mapped
Hello Ignacio,
Thank you for the quick response.
Are you part of the Apache Software Foundation?
Or are you part of Cortexity?
Thanks again,
John Dove
--
John Dove
MapInfo Tech Support
I'll get into Tomcat 3.2.4 before the final release.
Marc Saegesser
-Original Message-
From: Michael Jennings [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 10:51 AM
To: [EMAIL PROTECTED]
Subject: Can someone commit this minor fix?
The following fix enables
remm01/11/01 10:45:01
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Clean up the URLs. I don't know if it was actually causing some problems, but it
may have.
Revision ChangesPath
1.25 +27 -12
You have posted to tomat-dev mail list at http://jakarta.apache.org/..
Cortexity was hosting a bug tracking system at his facilities many time
ago this system is not used anymore, and the bugs were imported into
bugzilla, now the bug tracking system is at
http://nagoya.apache.org/bugzilla/
Thanks!
-Mike
- Original Message -
From: Marc Saegesser [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 10:54 AM
Subject: RE: Can someone commit this minor fix?
I'll get into Tomcat 3.2.4 before the final release.
Marc Saegesser
Hi,
I issues to Tomcat one request which takes kind of long time to response, when the
backend servlet or bean is working on the result, I just can not wait and clicked
somewhere on my browser page to issue another request, in this case, I am wondering
what Tomcat to do with the previous
Please see my prior post as to why this may not do what
you expect, i.e.
JkMount /*j_security_check ajp12
will map *all* requests to Tomcat. :)
Larry
-Original Message-
From: Michael Jennings [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 01, 2001 3:05 PM
To: Tomcat
Mike,
[I tried sending this privately, but it bounced.]
I just got caught up on the rest of the messages in tomcat-dev and it looks
like this patch doesn't do what you expect. Mod_jk doesen't handle
wildcards per se. It only knows two kinds of mappings
JkMount /path/*
and
JkMount *.ext
The
It isn't a matter of how the '*' is interpreted, but that
mod_jk will put a null terminator following the '*' if the
next character isn't a '.'. Thus:
JkMount /*something ...
and
JkMount /* ...
end up being equivalent. So far no one has found time to
add more sophisticated string
This depends on the version of Tomcat, and to some extent whether you are
running Tomcat behind another web server.
- Original Message -
From: Hu, Xuebing [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 11:57 AM
Subject: How does Tomcat handle discarded-request
Thanks!
I'll take a look at the mod_jk C sources and see about submitting a patch.
Thanks again for pointing out the problem.
-Mike
- Original Message -
From: Larry Isaacs [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 12:32 PM
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Bugs imported from bugrat in Cortexity system can be found searching
for
BugRat Report#NNN in the summary line closed and resolved bugs were
not imported
On the official Apache bugdatabase (i.e. http://nagoya.apache.org/bugzilla/
),
I could not find my reported Tomcat3.2.x bug. I searched
Thanks, Bill for the response. Any detail? I am currently using TOMCAT 3.2.3.
David
--
From: Bill Barker[SMTP:[EMAIL PROTECTED]]
Reply To: Tomcat Developers List
Sent: Thursday, November 01, 2001 2:57 PM
To: Tomcat Developers List
Subject: Re: How does
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4573.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Thu, 1 Nov 2001, Hu, Xuebing wrote:
Date: Thu, 1 Nov 2001 17:03:29 -0500
From: Hu, Xuebing [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: How does Tomcat handle discarded-request
Thanks, Bill for the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4573.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
pier01/11/01 14:20:52
Modified:webapp INSTALL.txt Makedefs.in Makefile.in Makefile.win
README.txt configure.in
webapp/apache-1.3 Makefile.in Makefile.win mod_webapp.c
webapp/apache-2.0 Makefile.in mod_webapp.c
Hi, Craig,
Here is my skeleton jsp,
jsp:useBean id=workBean class=... ...
/jsp:useBean
%
Object param1=getParameter(Param1) ;
...
Object paramn = getParameter(Paramn) ;
// let us say that doWork takes a few minutes to finish
// and I just can not wait
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4330.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4577.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jfclere 01/11/01 15:05:21
Modified:catalina/src/share/org/apache/catalina/valves
CertificatesValve.java
Log:
Add javax.servlet.request.ssl_session to TC standalone.
Revision ChangesPath
1.8 +19 -4
Generally with 3.2.x it will throw there, but it may throw later due to
buffering. And since the browser has closed the connection, no you can't
send/receive anything further. Of course, there is nothing to prevent you
inclosing your code in a try {} finally {} block if workBean needs to do
Quoting Pier Fumagalli [EMAIL PROTECTED]:
Bill Barker at [EMAIL PROTECTED] wrote:
I know that Jon has already pointed out that Sun is going to sue the
3.x
branch out of Jakarta in five months,
I don't think Jon said that, and as a Sun employee I can guarantee
that
Tomcat 3.x remains
One year, three months and five days. It definitely didn't last long, or not
as long as I would have expected, or as long as I would have liked it. What?
Oh, I believe you noticed it already: effective today I'm no longer a Sun
Microsystems employee...
Well folks, it has been a long and wild
Quoting Pier Fumagalli [EMAIL PROTECTED]:
And in case I don't see you, good afternoon, good evening and good
bye...
Pier, my apologies for the Sun related e-mail on the list today. If I only knew,
I would never have sent it.
:-((
I wish you all the best in your future undertakings and I
Bojan Smojver at [EMAIL PROTECTED] wrote:
I wish you all the best in your future undertakings and I really hope you'll
stick around Jakarta because I'm sure your work is appreciated by all.
Not by _all_ AFAICS :) Read, been in a lot of flamewars myself... :)
Pier
--
To unsubscribe,
billbarker01/11/01 19:14:03
Modified:src/share/org/apache/tomcat/modules/server
Http10Interceptor.java
Log:
Fix recycling the remoteAddr and remoteHost.
The remoteAddr and remoteHost would get reset to the default localhost values after
recycling.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi
I like to present Japanese in portlet . Currently it does not work when I
put Japanese characters in ECS objects in getContent function. Please help.
Thanks
Dang Tuan
mailto:[EMAIL PROTECTED]
costin 01/11/01 20:22:59
Added: jk/native/common jk_channel.h
Log:
A first step in abstracting the TCP communication and adding support for
faster mechanisms.
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/native/common/jk_channel.h
Hi,
Tomcat currently only supports Sun's default keystore: JKS. Are there any
plans to change tomcat to take a keystore type as a parameter, and then run
using that keystore for it's SSL? We're currently looking at the code to
try and implement our keystore (which implements the
This is probably outside of the development plans for 3.2.x.
I'm +1 for supporting this in 3.3.1
I'm going to let the 4.0 people answer for themselves (e.g. I'm +0).
- Original Message -
From: Meren, Libby [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 01, 2001 9:30 PM
You are not seeing I think ;))
Maybe you are more appreciated than you think by the people you had
flamewars with ;)
Enjoy your independence and if you want something else then rain in London,
come and enjoy the rain here in Holland..
Mvgr,
Martin
-Original Message-
From: Pier
59 matches
Mail list logo
