Re: cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http SocketInputStream.java
[EMAIL PROTECTED] wrote:
remm01/01/11 22:51:58
Modified:catalina/src/share/org/apache/catalina/connector/http
SocketInputStream.java
Log:
- Merge with some code inspired from code from BufferedInputStream.
- Removed some unnecessary synchronization (to be confirmed). If the
sync was necessary, I suggest doing it in the RequestInputStream.read()
instead.
*/
-public class SocketInputStream extends BufferedInputStream {
+public class SocketInputStream extends InputStream {
I think you should subclass FilterInputStream, because it will provide
you default implementations for the read(xxx) methods by calling the
read() method.
--
Thomas Butter [EMAIL PROTECTED] ICQ: 891617
"Unix IS user friendly, it is just selective about who his friends are."
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
BugRat Report #750 has been filed.
Bug report #750 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/750 REPORT #750 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: low Severity: critical Confidence: public Environment: Release: 4.0-20010111 JVM Release: JDK1.3 Operating System: Win 2000 Pro OS Release: 5.00.2195 Platform: Intel Synopsis: webwork.war (webwork 0.9) fails in 4.0, ok in 3.2.1 Description: Just wanted to let you know that the webwork system (http://sourceforge.net/projects/webwork/) is not installable with the latest nightly build (20010111). XML parsing error. erik Title: BugRat Report # 750 BugRat Report # 750 Project: Tomcat Release: 4.0-20010111 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: low Severity: critical Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Jan 12 2001, 04:32:02 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: webwork.war (webwork 0.9) fails in 4.0, ok in 3.2.1 Environment: (jvm, os, osrel, platform) JDK1.3, Win 2000 Pro, 5.00.2195, Intel Additional Environment Description: Report Description: Just wanted to let you know that the webwork system (http://sourceforge.net/projects/webwork/) is not installable with the latest nightly build (20010111). XML parsing error. erik View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
Hola Hans , Marc: You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks ago , that seems to resolve this problem, were reports #619 #653 #513 , and i think this is resolved in CVS, please review it and i will revise BugRat to close related bugs , if you agree it's already resolved.. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans Bergsten Enviado el: viernes 12 de enero de 2001 8:46 Para: [EMAIL PROTECTED] Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] Marc Saegesser wrote: Regarding BugReport #744. I've been trying to duplicate it on my Win2000 system and haven't had any luck. I always get back the executed page. Has anyone else been able to duplicate the problem behavior? I actually tested it today (on a Red Hat 7 system, but I doubt that matters) and was able to reproduce it easily; just make a GET request without the protocol. I haven't had a chance to try to figure out why yet though. [...] Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #166 was closed (apparently by: Ignacio Ortega)
Report #166 was closed by Person #0 Synopsis: When I start tomcat on Win2000 I get the following error message (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #628 was closed (apparently by: Ignacio Ortega)
Report #628 was closed by Person #0 Synopsis: Will not run unless logged in as adminstrator (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #722 was closed (apparently by: Ignacio Ortega)
Report #722 was closed by Person #0 Synopsis: Tomcat with Win 2000 ? (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #725 was closed (apparently by: Ignacio Ortega)
Report #725 was closed by Person #0 Synopsis: segmentation violation at first http request (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #721 was closed (apparently by: Ignacio Ortega)
Report #721 was closed by Person #0 Synopsis: a (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
patch against Tomcat-Workers-Howto
Hi guys, reading my way through the documentation, i've been finding things that look "wrong"- I'm creating patches for the obvious bits as I go, but I think this one needs to be done... What do you think? cheers, -Thom Index: src/doc/Tomcat-Workers-HowTo.html === RCS file: /home/cvspublic/jakarta-tomcat/src/doc/Tomcat-Workers-HowTo.html,v retrieving revision 1.1 diff -u -r1.1 Tomcat-Workers-HowTo.html --- src/doc/Tomcat-Workers-HowTo.html 2000/06/19 10:08:36 1.1 +++ src/doc/Tomcat-Workers-HowTo.html 2001/01/12 13:53:37 @@ -164,7 +164,7 @@ pworker.local.type=ajp12/p /td td - pDefines a worker named local that use the ajpv12 protocol + pDefines a worker named quot;localquot; that uses the ajpv12 protocol to forward requests to a Tomcat process./p /td /tr @@ -173,7 +173,7 @@ pworker.remote.type=ajp13/p /td td - pDefines a worker named local that use the ajpv12 protocol + pDefines a worker named quot;remotequot; that uses the ajpv13 protocol to forward requests to a Tomcat process./p /td /tr @@ -182,7 +182,7 @@ pworker.fast.type=jni/p /td td - pDefines a worker named local that use the ajpv12 protocol + pDefines a worker named quot;fastquot; that uses JNI to forward requests to a Tomcat process./p /td /tr @@ -191,8 +191,8 @@ pworker.loadbalancer.type=lb/p /td td - pDefines a worker named local that use the ajpv12 protocol - to forward requests to a Tomcat process./p + pDefines a worker named quot;loadbalancerquot; that + loadbalances several Tomcat processes transparently./p /td /tr /table @@ -600,4 +600,4 @@ work./p /body -/html \ No newline at end of file +/html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
I cvsup and build from source several times a week to make sure none of the changes going in have any detrimental effects on my application. I'm testing with the latest on the tomcat_32 branch. -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 5:03 AM To: '[EMAIL PROTECTED]' Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] Hola Hans , Marc: You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks ago , that seems to resolve this problem, were reports #619 #653 #513 , and i think this is resolved in CVS, please review it and i will revise BugRat to close related bugs , if you agree it's already resolved.. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans Bergsten Enviado el: viernes 12 de enero de 2001 8:46 Para: [EMAIL PROTECTED] Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] Marc Saegesser wrote: Regarding BugReport #744. I've been trying to duplicate it on my Win2000 system and haven't had any luck. I always get back the executed page. Has anyone else been able to duplicate the problem behavior? I actually tested it today (on a Red Hat 7 system, but I doubt that matters) and was able to reproduce it easily; just make a GET request without the protocol. I haven't had a chance to try to figure out why yet though. [...] Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
I'd like to hear from Hans before we close the report. He was able to duplicate the problem but I wasn't. If he's running tomcat_321_final then that would be expected, if he's using tomcat_32 latest and still seeing the problem then something else is wrong. -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 8:21 AM To: '[EMAIL PROTECTED]' Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] So you cant found a buggy behavior, it's solved by the previously pathc aplied , isn't it? I will close that report , and declare it resolved, if nobody complains.. Sorry i read exactly the inverse of your message, that is you can probe the buggy behavior :-), Saludos , Ignacio J. Ortega -Mensaje original- De: Marc Saegesser [mailto:[EMAIL PROTECTED]] Enviado el: viernes 12 de enero de 2001 15:12 Para: [EMAIL PROTECTED] Asunto: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] I cvsup and build from source several times a week to make sure none of the changes going in have any detrimental effects on my application. I'm testing with the latest on the tomcat_32 branch. -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 5:03 AM To: '[EMAIL PROTECTED]' Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] Hola Hans , Marc: You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks ago , that seems to resolve this problem, were reports #619 #653 #513 , and i think this is resolved in CVS, please review it and i will revise BugRat to close related bugs , if you agree it's already resolved.. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans Bergsten Enviado el: viernes 12 de enero de 2001 8:46 Para: [EMAIL PROTECTED] Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] Marc Saegesser wrote: Regarding BugReport #744. I've been trying to duplicate it on my Win2000 system and haven't had any luck. I always get back the executed page. Has anyone else been able to duplicate the problem behavior? I actually tested it today (on a Red Hat 7 system, but I doubt that matters) and was able to reproduce it easily; just make a GET request without the protocol. I haven't had a chance to try to figure out why yet though. [...] Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #751 has been filed.
Bug report #751 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/751
REPORT #751 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment:
Release: 3.2.1
JVM Release: 1.3.0
Operating System: Linux 2.2.16
OS Release: Red Hat Linux 7.0
Platform: x86
Synopsis:
NullPointerException thrown in SessionInterceptor when debug logging is on
Description:
When embedding Tomcat into my application using EmbededTomcat, I started
seeing NullPointerException being thrown on every HTTP request to the
server. On tracing through the source code, I found the problem
in line 136 of SessionInterceptor.java:
public int beforeBody( Request rrequest, Response response ) {
String reqSessionId = response.getSessionId();
== if( debug0 ) cm.log("Before Body " + reqSessionId );
if( reqSessionId==null)
return 0;
If response.getSessionId() returns null and debug logging is
turned on, the code attempts to concatenate a string with null,
resulting in the NullPointerException seen.
Title:
BugRat Report #
751
BugRat Report #
751
Project:
Tomcat
Release:
3.2.1
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
medium
Severity:
serious
Confidence:
public
Submitter:
Kris Zaragoza ([EMAIL PROTECTED])
Date Submitted:
Jan 12 2001, 10:19:19 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
NullPointerException thrown in SessionInterceptor when debug logging is on
Environment: (jvm, os, osrel, platform)
1.3.0, Linux 2.2.16, Red Hat Linux 7.0, x86
Additional Environment Description:
Report Description:
When embedding Tomcat into my application using EmbededTomcat, I started
seeing NullPointerException being thrown on every HTTP request to the
server. On tracing through the source code, I found the problem
in line 136 of SessionInterceptor.java:
public int beforeBody( Request rrequest, Response response ) {
String reqSessionId = response.getSessionId();
==> if( debug>0 ) cm.log("Before Body " + reqSessionId );
if( reqSessionId==null)
return 0;
If response.getSessionId() returns null and debug logging is
turned on, the code attempts to concatenate a string with null,
resulting in the NullPointerException seen.
How To Reproduce:
null
Workaround:
null
View this report online...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
3.2 cvs problems with ROOT context?
Hola a todos: I dong a brief review of 3.2.2 from cvs this evening, only to give a look over the latest ( big ) changes and so on... But after a cvs update a "build all" and double checked everything AFAIK, i can not get http://localhost:8080/ in my browser, i can access examples context but it seems that i can not access ROOT context @:( , so i'm really suprised and stucked, do a new check of everything , and nope!! nothings works in the ROOT context IMHO i'm forgetting something, or i can fire my dev system or i'm mad ( as usual )... Being addicted to debuggers,i did a try, a simple look inside, and whats my surprise ROOT context is mounted !!! but in "" path and SimpleMapper1 is trying to map a path="/" . I recall that the correct behavior the path as "" not "/" but... i've decided to ask everybody, to test that nothing is bad on my side... Everybody can access a freshly checkout of Tomcat 3.2.2 from cvs build them and access http://localhost:8080 without problems??? Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: possible problem with CLIENT-CERT login and security constraint on TOMCAT 4.0
[EMAIL PROTECTED] wrote: Hi, I try to configure TOMCAT server to authenticate client with certificate on HTTPS protocol. My connector is configure to accept request on 8443 port like this : Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0" scheme="https" secure="true"> Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="true" protocol="TLS" keystorePass="password1"/> /Connector> My tomcat-user.xml file is configured with a new entry that match the getSubjectDN().getName() of client certificat used : tomcat-users> user name="tomcat" password="tomcat" roles="tomcat" /> user name="role1" password="tomcat" roles="role1" /> user name="both" password="tomcat" roles="tomcat,role1" /> user name="OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr" password="tomcat" roles="tomcat,role1" /> /tomcat-users> I also uncomment the security constraint on my web.xml file like this security-constraint> web-resource-collection> web-resource-name>The Entire Web Application/web-resource-name> url-pattern>/*/url-pattern> /web-resource-collection> auth-constraint> role-name>tomcat/role-name> /auth-constraint> /security-constraint> login-config> auth-method>CLIENT-CERT/auth-method> realm-name>Tomcat Supported Realm/realm-name> /login-config> security-role> description> An example role defined in "conf/tomcat-users.xml" /description> role-name>tomcat/role-name> /security-role> My problem is when I try to connect on my tomcat serveur I have always the same message : HTTP Error 403 - Forbidden Possibly reasons : I try to compare BASIC authenticator and CLIENT-CERT authenticator. * BasicAuthenticator class register an MemoryRealmPrincipal object return by the MemoryRealm class * SSLAuthenticator class register an Principal object with is simply return by certs[0].getSubjectDN() method (and has no role associated) When I modified a little bit the SSLAuthenticator class to find on the MemoryRealm the MemoryRealmPrincipal associated with the username = certs[0].getSubjectDN().getName() ( with no password) that seems run better... Excuse me, if it's a know limitation, a bug already know or a bad settings ... Jrme In order to use CLIENT-CERT authentication, you *must* set up a user in whatever Realm is used for authentication, with a username equal to certs[0].getSubjectDN(). This is needed for the following reasons: * To know that this is a valid user for *this* application, (not just that the certificate is valid) * To know what roles are assigned to this user for *this* application. If you are using the default Realm implementation, this means you must add an entry to $CATALINA_HOME/conf/tomcat-users.xml for this user. Craig McClanahan
RE: An alternative to JSP
Whatcha looking for: np.instantis.com ??? Just curious to see what's happening over there, nothing more. That's what browsers are for. What's the relevance to Tomcat? -tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #752 has been filed.
Bug report #752 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/752 REPORT #752 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: Tomcat 3.2.1 JVM Release: 1.2.1_04 Operating System: Solaris OS Release: ??? Platform: SPARC Synopsis: User Principal incorrectly Maintained Description: I'm using the JDBCRealm and everything seems to work OK, but I'm actually dynamically generating info not just on the Role (which works fine), but the user itself. I'm getting the current user by calling request.getUserPrincipal().getName(). I have a user jim and jones both in the same role. If I log in as jim first, then the principal returns jim even if I log out (change or close the browser) and then log in as jones. You can see (below) that the realm is fine and shows the correct user logged in and authenticated with the correct role, but then at the bottom when I call request.getUserPrincipal().getName() I don't get the correct user. 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for user jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/images/favB.gif + null) Ct ( ) 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for user jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/images/bow.gif + null) Ct ( ) 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Authentication successful for user jones 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, user=jones 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/review.do + null) Ct (action(org.apache.struts.action.ActionServlet/null) ) 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer *** Current User Principal: jim Title: BugRat Report # 752 BugRat Report # 752 Project: Tomcat Release: Tomcat 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: David Winterfeldt ([EMAIL PROTECTED]) Date Submitted: Jan 12 2001, 11:25:46 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: User Principal incorrectly Maintained Environment: (jvm, os, osrel, platform) 1.2.1_04, Solaris, ???, SPARC Additional Environment Description: Report Description: I'm using the JDBCRealm and everything seems to work OK, but I'm actually dynamically generating info not just on the Role (which works fine), but the user itself. I'm getting the current user by calling request.getUserPrincipal().getName(). I have a user jim and jones both in the same role. If I log in as jim first, then the principal returns jim even if I log out (change or close the browser) and then log in as jones. You can see (below) that the realm is fine and shows the correct user logged in and authenticated with the correct role, but then at the bottom when I call request.getUserPrincipal().getName() I don't get the correct user. 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for user jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/images/favB.gif + null) Ct ( ) 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for user jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/images/bow.gif + null) Ct ( ) 2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Authentication successful for user jones 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, user=jones 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/review.do + null) Ct (action(org.apache.struts.action.ActionServlet/null) ) 2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer *** Current User Principal: jim View this report online... - To unsubscribe, e-mail:
Re: cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http SocketInputStream.java
I think you should subclass FilterInputStream, because it will provide you default implementations for the read(xxx) methods by calling the read() method. InputStream.read(b[], off, len) and skip(n), which are the two that I didn't implement (yet) look good enough to me (they both will end up calling read()). Or am I again making asumptions on how the InputStream class behaves ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x)
Benoit, Thanks -- I actually just fixed this in the 3.2 branch. -Dan Benoit Derouet wrote: Hi, The load balancer worker fail to handle load balancing (with sticky sessions) if the application uses custom cookies. In some circumstances, the load balancer worker can't retreive the server name from the JSessionID cookie and is not able to redirect to the good server. The algorithm parse the cookie header to extract the server name from the JSessionID cookie. It find properly the end of the server name but fail to cut the chars after. So, it works fine if the cookie header contains only one cookie (or if JSessionID is the last cookie) but If they are custom cookie, the server name extracted will be: "servername;mycookieVal=myCookieValue .." The bug is fixed around line 170. (line id_end=NULL; replaced by id_end[0] = '\0'; ) 'hope this will be integrated in future versions ! (as our customers need sticky load balancing...) regards. Benoit -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util PrefixMapper.java
larryi 01/01/12 10:04:24
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
PrefixMapper.java
Log:
Reimplement the last fix so the root context (i.e. "") doesn't have problems.
Revision ChangesPath
No revision
No revision
1.3.2.2 +7 -4
jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java
Index: PrefixMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- PrefixMapper.java 2001/01/04 21:28:33 1.3.2.1
+++ PrefixMapper.java 2001/01/12 18:04:20 1.3.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.3.2.1
2001/01/04 21:28:33 marcsaeg Exp $
- * $Revision: 1.3.2.1 $
- * $Date: 2001/01/04 21:28:33 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.3.2.2
2001/01/12 18:04:20 larryi Exp $
+ * $Revision: 1.3.2.2 $
+ * $Date: 2001/01/12 18:04:20 $
*
*
*
@@ -215,11 +215,14 @@
if( container!=null ) return container;
}
- while (s.length() 0) {
+ while (s.length() = 0) {
//if(debug8) context.log( "Prefix: " + s );
container = myMap.prefixMappedServlets.get(s);
if (container == null) {
+ // if empty string didn't map, time to give up
+ if ( s.length() == 0 )
+break;
s=URLUtil.removeLast( s );
} else {
if( myMap.mapCacheEnabled ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
BugRat Report #753 has been filed.
Bug report #753 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/753
REPORT #753 Details.
Project: Servlet API
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment:
Release: Tomcat 3.2.1
JVM Release: 1.3
Operating System: Linux / NT
OS Release: 7.2 / 4.51
Platform: Intel
Synopsis:
req.getParameter(name) Ignores charset. always assumes ISO8859-1.
Description:
I have an application that allows the user to enter UNICODE
characters on the WEB browser.
The web page is "rsp.setContentType("text/html; charset=UTF8");"
which enables UNICODE support on both IE and NetScape.
When I use "req.getParameter(name)" to get the user input,
it is not decoded correctly. Each byte of the UTF8 stream
is placed in a seperate character. (as if a deprecated String
constructor "String(bytearray,0,0,length)" is being used to
convert the bytes into a String).
This behavior is WRONG!
Java 2 classes should not use deprecated methods!
Also, it destroys important information needed to convert
the input byte stream into it's correct UNICODE String
representation.
Please tell me who supports javax.servlet.
Tim Tye -- [EMAIL PROTECTED]
Title:
BugRat Report #
753
BugRat Report #
753
Project:
Servlet API
Release:
Tomcat 3.2.1
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
high
Severity:
critical
Confidence:
public
Submitter:
_Anonymous ([EMAIL PROTECTED])
Date Submitted:
Jan 12 2001, 12:08:22 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
req.getParameter(name) Ignores charset. always assumes ISO8859-1.
Environment: (jvm, os, osrel, platform)
1.3, Linux / NT, 7.2 / 4.51, Intel
Additional Environment Description:
public String(byte[] ascii,
int hibyte,
int offset,
int count)
Deprecated. This method does not properly convert bytes into characters. As of JDK 1.1, the preferred way to do this is via the String
constructors that take a character-encoding name or that use the platform's default encoding.
Report Description:
I have an application that allows the user to enter UNICODE
characters on the WEB browser.
The web page is "rsp.setContentType("text/html; charset=UTF8");"
which enables UNICODE support on both IE and NetScape.
When I use "req.getParameter(name)" to get the user input,
it is not decoded correctly. Each byte of the UTF8 stream
is placed in a seperate character. (as if a deprecated String
constructor "String(bytearray,0,0,length)" is being used to
convert the bytes into a String).
This behavior is WRONG!
Java 2 classes should not use deprecated methods!
Also, it destroys important information needed to convert
the input byte stream into it's correct UNICODE String
representation.
Please tell me who supports javax.servlet.
Tim Tye -- [EMAIL PROTECTED]
Workaround:
null
View this report online...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
There lies the catch and the source of problem in my understanding. In different requests relating to the same session, I may get referance to HttpSessionFacade instances which are different, but I expect them to be same (although not guarantied by specs but I thought it was a tacit agreement between container and servlet developer). What I suggest is that tomcat should recycle the HttpSessionFacade instance only when the HttpSession instance is recycled.This might be more inefficient as it will result in N instances on You are right, I know what's the problem. It's not hard to fix, but this week I have no time ( and probably neither next week ), but this bug has been on my list. In fact, there is a larger problem here - with very serious security and performance implications. To get decent performance you need to recycle ( the cost of allocating few hundred objects per request is huge - it means the server will saturate on even small loads). Most servlet containers do recycle - the problem is common to all of them. Unfortunately recycling opens a security hole: a (bad) servlet may keep reference to the HttpServletRequest, HttpServletResponse and HttpSession objects - and later access the them. That means it'll be able to access data in a HttpServletRequest that is in use by another servlet, in another application. We have most of the elements to fix this hole - and with a decent ( small) perfomance hit. We need to make sure that a servlet receive only facades that are local to it's context. That's easy to do by either maintaining a per/context pool of facades or just doing nothing ( since the facade is very "light"). There is nothing that can be done with the original Request (and I don't know any possible fix for this problem in containers that don't use facades ) - you know the context after you process the request, and then you've already allocated the request. It may be possible to process the request line before allocating the request - but that's ugly. Anyway, that's not a problem in 3.x. Regarding HttpSessionFacade - you are right, ServerSession should have a get/setFacade and all getSession() calls should return the same facade. 1/2 of that is done in 3.3, I just need to do one more change - it's easy to duplicate this in 3.2 also. Of course, when the session is invalidated the facade must be either saved in a context-specific pool or just let it die. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
Gokul Singh wrote: [...] The reason you see a behavior difference is that Tomcat 3.1 did not recycle session object instances, but Tomcat 3.2 does. There lies the catch and the source of problem in my understanding. In different requests relating to the same session, I may get referance to HttpSessionFacade instances which are different, but I expect them to be same (although not guarantied by specs but I thought it was a tacit agreement between container and servlet developer). [...] The spec may not be explicit enough about this, but the session object you get back from the getSession() object is a container-managed object that the application is not supposed/allowed to keep long-lived references to. It's the same as with all other container-objects made available to the application; request, response, JSP tag handlers, etc. I'm not sure why you're keeping references to the session objects in you're application, but if you describe what you're trying to do I'm sure I can give you a hint about another way to accomplish the same thing without the problems you have with your current solution. -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Interceptor architecture
Hi, Could someone please direct me to any useful documentation that explains the architecture for building interceptors for Tomcat? Any resource that explains how to use the Tomcat open APIs would be helpful. Thanks in advance, Aprameya Paduthonse - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
on 1/12/01 11:49 AM, "Tomas Rokicki" [EMAIL PROTECTED] wrote: With the solution we're deploying in-house here, your dynamic row example is just tabletrtd%tr rundata%%key%/tdtd = %value%/td/tr/table which is editable in WYSIWYG HTML editors, contains no Java code, and so on . . . the magic %tr ...% tells it to iterate on table rows. Oh, but of course it's YATL so I'll shut up now. (It compiles down to JSPs.) Exactly. JSP alone didn't solve your problem. You had to do YATL in order to get it to do what you want. That just seems odd to me. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #756 has been filed.
Bug report #756 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/756 REPORT #756 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: 3.2.1 JVM Release: 1.2.1_04 Operating System: Solaris OS Release: ??? Platform: SPARC Synopsis: User Principal incorrectly Maintained - Fix Description: request.getUserPrincipal().getName() doesn't return the correct user all of the time. Title: BugRat Report # 756 BugRat Report # 756 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: David Winterfeldt ([EMAIL PROTECTED]) Date Submitted: Jan 12 2001, 01:53:23 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: User Principal incorrectly Maintained - Fix Environment: (jvm, os, osrel, platform) 1.2.1_04, Solaris, ???, SPARC Additional Environment Description: Report Description: request.getUserPrincipal().getName() doesn't return the correct user all of the time. Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
I don't look at it as odd at all. JSP and servlets in general are *very low level* abstractions. They are incredibly useful, but they are at such a low level that it's very difficult to build a complex application. It's like coding in machine language. It's not that difficult to add a layer or two to raise the level of abstraction. The good thing about JSP and servlets is they provide a stable, portable, and solid base with good engineering. They are complex enough that getting them implemented correctly is nontrivial (hence all the work on tomcat etc.) but yet generic enough that different abstractions can easily be constructed on top of them. This is precisely what I want, a good solid base engineered well on which I can build what we need. All the experimentation with the various macro languages and the like is all good, and we'll all learn from them and eventually it will all converge [or fail to do so]; I don't see that it has happened yet, and each solution has its pros and cons, none of which were acceptable when we started our project, which is why I've got a stupid lightweight YATL that we use in-house that solves our problems. I just thought I'd toss out an example of how we solved the `no code in JSP' problem. -tom -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 11:54 AM To: [EMAIL PROTECTED] Subject: Re: An alternative to JSP on 1/12/01 11:49 AM, "Tomas Rokicki" [EMAIL PROTECTED] wrote: With the solution we're deploying in-house here, your dynamic row example is just tabletrtd%tr rundata%%key%/tdtd = %value%/td/tr/table which is editable in WYSIWYG HTML editors, contains no Java code, and so on . . . the magic %tr ...% tells it to iterate on table rows. Oh, but of course it's YATL so I'll shut up now. (It compiles down to JSPs.) Exactly. JSP alone didn't solve your problem. You had to do YATL in order to get it to do what you want. That just seems odd to me. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #758 has been filed.
Bug report #758 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/758 REPORT #758 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2.1 JVM Release: 1.3 Operating System: Win2k OS Release: SP0 Platform: Apache 1.3.14 Synopsis: HTTP POST incorrect behavior Description: When I open a telnet session from a Linux machine to my Win2k machine running Tomcat, it allows me to type the following: POST /jgrady/servlet/PurchaseOrderServlet HTTP/1.0 content-length: 8 And then as soon as I hit enter after the '8', it tries to process my request. AFAIK, this is incorrect behavior for HTTP POSTing. I think it should allow me to type one blank line, some content, and then process my request. Integrating Apache with Tomcat and trying the same test only makes Apache return an error 500 'Internal Server Error'. [EMAIL PROTECTED] Title: BugRat Report # 758 BugRat Report # 758 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Jan 12 2001, 02:05:14 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: HTTP POST incorrect behavior Environment: (jvm, os, osrel, platform) 1.3, Win2k, SP0, Apache 1.3.14 Additional Environment Description: Report Description: When I open a telnet session from a Linux machine to my Win2k machine running Tomcat, it allows me to type the following: POST /jgrady/servlet/PurchaseOrderServlet HTTP/1.0 content-length: 8 And then as soon as I hit after the '8', it tries to process my request. AFAIK, this is incorrect behavior for HTTP POSTing. I think it should allow me to type one blank line, some content, and then process my request. Integrating Apache with Tomcat and trying the same test only makes Apache return an error 500 'Internal Server Error'. [EMAIL PROTECTED] How To Reproduce: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
Hans Bergsten wrote: "Ignacio J. Ortega" wrote: Hola Hans , Marc: You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks ago , that seems to resolve this problem, were reports #619 #653 #513 , and i think this is resolved in CVS, please review it and i will revise BugRat to close related bugs , if you agree it's already resolved.. I was using the 3.2.1 version, not the latest CVS version (duh!). Will test again with the CVS version. Okay, I have tested with the latest tomcat_32 version from CVS now and it works as it should. So the patch you applied solved the problem. Thanks for telling me before I spent time trying to solve this again ;-) Great, then I don't know of any serious issues that should hold up a 3.2.2 release. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
un subscribe me...................
-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: Friday, January 12, 2001 9:20 PMTo: [EMAIL PROTECTED]Subject: possible problem with CLIENT-CERT login and security constraint on TOMCAT 4.0Hi, I try to configure TOMCAT server to authenticate client with certificate on HTTPS protocol. My connector is configure to accept request on 8443 port like this : Connector className="org.apache.catalina.connector.http.HttpConnector" port="8443" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0" scheme="https" secure="true" Factory className="org.apache.catalina.net.SSLServerSocketFactory" clientAuth="true" protocol="TLS" keystorePass="password1"/ /Connector My tomcat-user.xml file is configured with a new entry that match the getSubjectDN().getName() of client certificat used : tomcat-users user name="tomcat" password="tomcat" roles="tomcat" / user name="role1" password="tomcat" roles="role1" / user name="both" password="tomcat" roles="tomcat,role1" / user name="OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr" password="tomcat" roles="tomcat,role1" / /tomcat-users I also uncomment the security constraint on my web.xml file like this security-constraint web-resource-collection web-resource-nameThe Entire Web Application/web-resource-nameurl-pattern/*/url-pattern /web-resource-collection auth-constraintrole-nametomcat/role-name /auth-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method realm-nameTomcat Supported Realm/realm-name /login-config security-role description An example role defined in "conf/tomcat-users.xml" /description role-nametomcat/role-name /security-role My problem is when I try to connect on my tomcat serveur I have always the same message : HTTP Error 403 - Forbidden Possibly reasons : I try to compare BASIC authenticator and CLIENT-CERT authenticator. * BasicAuthenticator class register an MemoryRealmPrincipal object return by the MemoryRealm class * SSLAuthenticator class register an Principal object with is simply return by certs[0].getSubjectDN() method (and has no role associated) When I modified a little bit the SSLAuthenticator class to find on the MemoryRealm the MemoryRealmPrincipal associated with the username = certs[0].getSubjectDN().getName() ( with no password) that seems run better... Excuse me, if it's a know limitation, a bug already know or a bad settings ... Jérôme
RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
BugReport 748 came in this morning. I'm up to my eyeballs at work lately so I haven't been able to look at it in depth, but it does look like a real spec violation so it probably should be considered for 3.2.2. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Bergsten Sent: Friday, January 12, 2001 2:43 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.] Hans Bergsten wrote: "Ignacio J. Ortega" wrote: Hola Hans , Marc: You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks ago , that seems to resolve this problem, were reports #619 #653 #513 , and i think this is resolved in CVS, please review it and i will revise BugRat to close related bugs , if you agree it's already resolved.. I was using the 3.2.1 version, not the latest CVS version (duh!). Will test again with the CVS version. Okay, I have tested with the latest tomcat_32 version from CVS now and it works as it should. So the patch you applied solved the problem. Thanks for telling me before I spent time trying to solve this again ;-) Great, then I don't know of any serious issues that should hold up a 3.2.2 release. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
Hans Bergsten wrote: The spec may not be explicit enough about this, but the session object you get back from the getSession() object is a container-managed object that the application is not supposed/allowed to keep long-lived references to. It's the same as with all other container-objects made available to the application; request, response, JSP tag handlers, etc. I would have agreed with you before I read the following in the 2.3PFD spec: 7.3 Session Scope HttpSession objects must be scoped at the application / servlet context level. The underlying mechanism, such as the cookie used to establish the session, can be shared between contexts, but the object exposed, and more importantly the attributes in that object, must not be shared between contexts. By mentioning that the HttpSession object cannot be shared outside the ServletContext, it strongly implies that it can be shared within the context. If that sort of thing isn't allowed, then 7.3 might need to be clarified. -cks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/catalina build.xml
remm01/01/12 14:14:38 Modified:catalina build.xml Log: - ResourceFactory and TransactionFactory don't need to be left out of the build, since dependencies and imports from other parts of J2EE have been removed (using dynamic class loading instead). Revision ChangesPath 1.31 +0 -4 jakarta-tomcat-4.1/catalina/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-4.1/catalina/build.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- build.xml 2001/01/09 04:27:05 1.30 +++ build.xml 2001/01/12 22:14:38 1.31 @@ -103,10 +103,6 @@ excludes="**/CVS/**" exclude name="**/factory/Tyrex*.java" unless="tyrex.present" / - exclude name="**/factory/ResourceFactory.java" - unless="jdbcse.present" / - exclude name="**/factory/TransactionFactory.java" - unless="jta.present" / exclude name="**/startup/CatalinaBlock.java" unless="avalon.present" / /javac - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
Hans Bergsten wrote: "Christopher K. St. John" wrote: 7.3 Session Scope HttpSession objects must be scoped at the application / servlet context level. The underlying mechanism, such as the cookie used to establish the session, can be shared between contexts, but the object exposed, and more importantly the attributes in that object, must not be shared between contexts. By mentioning that the HttpSession object cannot be shared outside the ServletContext, it strongly implies that it can be shared within the context. If that sort of thing isn't allowed, then 7.3 might need to be clarified. This section refers to the fact that a servlet in one context should not be able to gain access to the same session data as a servlet in another context (i.e., resources in two different context's can not "be part" of the same session) for security reasons . It has nothing to do with whether a servlet in one context is allowed to hold on to the actual session object or not, which has to do with how much freedom the spec gives to container vendors in terms of pooling and life-cycle management for the internal objects. Because Section 7.3 explicity discusses the HttpSession object itself (as opposed to the objects it contains), it suggests that the HttpSession object has an identity. I don't think there is any question that after the end of the lifecycle of an HttpSession object, it can be recycled. But what earlier messages in this thread suggested was that JServ was recycling HttpSession objects _during_ the lifetime of the session, so that req.getSession(false) could return two different objects even within the same session. That would mean that the practice of synchronzing on the HttpSession object was also not kosher? Since two servlets within the same session at the same time could not be sure of getting the same HttpSession object? Are you really suggesting that that behavior is allowed by the spec? If so, I find that very unintuitive. -cks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x)
Will you update also the 3.3 branch ?-) "Pour la plupart des hommes, se corriger consiste changer de dfauts." -- Voltaire -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 6:59 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x) Benoit, Thanks -- I actually just fixed this in the 3.2 branch. -Dan Benoit Derouet wrote: Hi, The load balancer worker fail to handle load balancing (with sticky sessions) if the application uses custom cookies. In some circumstances, the load balancer worker can't retreive the server name from the JSessionID cookie and is not able to redirect to the good server. The algorithm parse the cookie header to extract the server name from the JSessionID cookie. It find properly the end of the server name but fail to cut the chars after. So, it works fine if the cookie header contains only one cookie (or if JSessionID is the last cookie) but If they are custom cookie, the server name extracted will be: "servername;mycookieVal=myCookieValue .." The bug is fixed around line 170. (line id_end=NULL; replaced by id_end[0] = '\0'; ) 'hope this will be integrated in future versions ! (as our customers need sticky load balancing...) regards. Benoit -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester SetBufferSize01.java
craigmcc01/01/12 16:51:01
Modified:tester/src/tester/org/apache/tester SetBufferSize01.java
Log:
Tweak the details of this test so that it operates more like the
corresponding CTS version (i.e. outputs text before the attempted call to
setBufferSize()).
Revision ChangesPath
1.2 +4 -6
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/SetBufferSize01.java
Index: SetBufferSize01.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/SetBufferSize01.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SetBufferSize01.java 2000/12/22 22:13:07 1.1
+++ SetBufferSize01.java 2001/01/13 00:51:01 1.2
@@ -68,7 +68,7 @@
* Negative test for ServletResponse.setBufferSize().
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2000/12/22 22:13:07 $
+ * @version $Revision: 1.2 $ $Date: 2001/01/13 00:51:01 $
*/
public class SetBufferSize01 extends GenericServlet {
@@ -92,13 +92,11 @@
response.setContentType("text/plain");
PrintWriter writer = response.getWriter();
try {
-writer.println("TEST");
+writer.print("SetBufferSize01 ");
response.setBufferSize(100);
-response.reset();
-writer.println("SetBufferSize01 FAILED - Did not throw
IllegalStateException");
+writer.println("FAILED - Did not throw IllegalStateException");
} catch (IllegalStateException e) {
-response.reset();
-writer.println("SetBufferSize01 PASSED");
+writer.println("PASSED");
}
while (true) {
String message = StaticLogger.read();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/tester/src/tester/org/apache/tester SetBufferSize01.java
craigmcc01/01/12 16:52:01
Modified:tester/src/tester/org/apache/tester SetBufferSize01.java
Log:
Forward port the test imrpovement.
Revision ChangesPath
1.2 +4 -6
jakarta-tomcat-4.1/tester/src/tester/org/apache/tester/SetBufferSize01.java
Index: SetBufferSize01.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/tester/src/tester/org/apache/tester/SetBufferSize01.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SetBufferSize01.java 2000/12/22 22:13:07 1.1
+++ SetBufferSize01.java 2001/01/13 00:52:01 1.2
@@ -68,7 +68,7 @@
* Negative test for ServletResponse.setBufferSize().
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2000/12/22 22:13:07 $
+ * @version $Revision: 1.2 $ $Date: 2001/01/13 00:52:01 $
*/
public class SetBufferSize01 extends GenericServlet {
@@ -92,13 +92,11 @@
response.setContentType("text/plain");
PrintWriter writer = response.getWriter();
try {
-writer.println("TEST");
+writer.print("SetBufferSize01 ");
response.setBufferSize(100);
-response.reset();
-writer.println("SetBufferSize01 FAILED - Did not throw
IllegalStateException");
+writer.println("FAILED - Did not throw IllegalStateException");
} catch (IllegalStateException e) {
-response.reset();
-writer.println("SetBufferSize01 PASSED");
+writer.println("PASSED");
}
while (true) {
String message = StaticLogger.read();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Reports #638 #637
Hola a todos: Please AJP12 13 experts :-) Have a look at reports #637 #638 they seems related to same issue ( #638 is hard to undertsand but relates to the same issue i think ) , i can recall some guy did put a test page online some time ago about that, please take a look at it, seems related to redirections AJP apache linux ... i dont have a box to confirm it... Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core RequestImpl.java
nacho 01/01/12 17:08:27 Modified:src/share/org/apache/tomcat/core Tag: tomcat_32 RequestImpl.java Log: Bug Report #757 User Principal incorrectly Maintained Submitted by David Winterfeldt ( [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ) Revision ChangesPath No revision No revision 1.52.2.5 +1 -1 jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java Index: RequestImpl.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java,v retrieving revision 1.52.2.4 retrieving revision 1.52.2.5 diff -u -r1.52.2.4 -r1.52.2.5 --- RequestImpl.java 2000/11/21 02:39:06 1.52.2.4 +++ RequestImpl.java 2001/01/13 01:08:27 1.52.2.5 @@ -726,7 +726,6 @@ pathInfo=null; pathTranslatedIsSet=false; sessionIdSource = null; - // XXX a request need to override those if it cares // about security remoteAddr="127.0.0.1"; @@ -741,6 +740,7 @@ notAuthenticated=true; userRoles=null; reqRoles=null; +principal=null; } // End utils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #757 was closed (apparently by: Ignacio Ortega)
Report #757 was closed by Person #0 Synopsis: User Principal incorrectly Maintained - Fix (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #758 was closed (apparently by: Ignacio Ortega)
Report #758 was closed by Person #0 Synopsis: HTTP POST incorrect behavior (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #756 was closed (apparently by: Ignacio Ortega)
Report #756 was closed by Person #0 Synopsis: User Principal incorrectly Maintained - Fix (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/doc faq
nacho 01/01/12 17:12:23 Modified:src/doc Tag: tomcat_32 faq Log: src/doc/faq contains wrong information for overriding the JspServlet Submitter: David Rees ( [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ) Revision ChangesPath No revision No revision 1.1.4.1 +1 -1 jakarta-tomcat/src/doc/faq Index: faq === RCS file: /home/cvs/jakarta-tomcat/src/doc/faq,v retrieving revision 1.1 retrieving revision 1.1.4.1 diff -u -r1.1 -r1.1.4.1 --- faq 2000/02/08 21:08:34 1.1 +++ faq 2001/01/13 01:12:22 1.1.4.1 @@ -225,7 +225,7 @@ jsp /servlet-name servlet-class - org.apache.jasper.runtime.JSPServlet + org.apache.jasper.runtime.JspServlet /servlet-class init-param param-name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #528 was closed (apparently by: Ignacio Ortega)
Report #528 was closed by Person #0 Synopsis: src/doc/faq contains wrong information for overriding the JspServlet (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: An alternative to JSP
Exactly. It would have been nice if JSP was done right from the start instead of having an original goal of attempting to provide a solution to strictly compete with ASP. My thought is that JSP was `done right from the start' (at least, with custom taglibs)---it just doesn't solve the whole problem, nor would I want it to. logic:iterate id="parameter" name="parameters" The main problem I have against tag libs and tag-based templates is the tags are either invisible in the HTML view or else some squiggly little box; it's really tough to get semantic information (hence my use of %% rather than in my template language). Of course, dreamweaver is making that better, but even in dreamweaver it's still a box that looks like [~]. Until of course you turn on tomcat, which we do and our developers do, to see what's happening with the real server, but it's great to actually have a clue what you're looking at in the main view too. I'll shut up now and let everyone get back to work on TOTL (their own template language). -tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #758 was assigned to Z_Ant Alias
Report #758 was assigned to Person #17 Name: Z_Ant Alias Email:[EMAIL PROTECTED] HomePage: -NA- Phone:-NA- FAX: -NA- The report was previously assigned to person #1 Name: Z_Tomcat Alias Email:[EMAIL PROTECTED] HomePage: http://jakarta.apache.org Phone:-NA- FAX: -NA- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: BugRat Report #758 was closed (apparently by: Ignacio Ortega)
758 has been reopened. On Sat, 13 Jan 2001, Ignacio J. Ortega wrote: Upsss, this was closed by mistake, sorry Nick can you reopen it, please ??? TIA Saludos , Ignacio J. Ortega -Mensaje original- De: BugRat Mail System [mailto:[EMAIL PROTECTED]] Enviado el: sábado 13 de enero de 2001 2:05 Para: Z_Tomcat Alias Asunto: BugRat Report #758 was closed (apparently by: Ignacio Ortega) Report #758 was closed by Person #0 Synopsis: HTTP POST incorrect behavior (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [OFF TOPIC] HTML question
on 1/12/01 6:12 PM, "Marc Saegesser" [EMAIL PROTECTED] wrote: There must be something simple that I'm missing. URL encode it. -jon -- Honk if you love peace and quiet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCHES] Catalina 4.1 Session Persistence
These patches are my proposal for session persistence in Catalina 4.1. Please look these over and give me your comments, and commit them if they look OK. The main change is the addition of a PersistentManager class, an optional replacement for StandardManager, providing the following configurable functionality: - Saves sessions to a Store on shutdown, loads on restart. This is currently implemented in StandardManager, but PersistentManager makes use of the Store interface. - Swaps sessions out to a Store if the number in memory exceeds maxActiveSessions, to better manage resources. A minIdleSwap property prevents sessions from being swapped out if they haven't been idle for very long, to avoid thrashing. - Swaps sessions out to a Store if they are idle for too long. With this feature, an app can have very long session expiration times without over-burdening memory. - Backs sessions up to Store (but keeps them in memory) if they are idle for too long. This provides basic fault tolerance, since the sessions will be read in from the Store when the server starts after a crash. NOT IMPLEMENTED YET! There is an issue regarding the Servlet 2.3 specification which I will discuss below. To test this out, see the server.xml file - there is a section to uncomment and tweak the configuration. ISSUES: - Backing up Sessions: I believe that HttpSessionActivationListeners should be notified when sessions are being backed up and restored. However, application developers reading the Servlet 2.3 specification [PFD] might not expect a session to remain in active use after the sessionWillPassivate() method is called. I would like to get some feedback on this. - I still have not figured out how to get Catalina to instantiate the Store class for me, this patch hard-codes the use of FileStore in PersistentManager. I've tried mucking around in startup/Catalina.java, to no avail. Can anyone help me out with this? - There is a lot of duplication of code between PersistentManager and StandardManager. Maybe this should be moved to ManagerBase? - The use of Session/StandardSession is very messy in ManagerBase, StandardManager, and now PersistentManager. Although some code uses the Session interface and executes StandardSession-specific code only after testing, much of this code will break if an alternative implementation is used (essential properties aren't set, etc.), and some code has StandardSession hard-coded without tests. It looks as if someone had good intentions to make it possible to replace StandardSession with a different implementation, but it hasn't been followed through, so it's just a mess. This means I can't create a PersistentSession class and keep persistence-related code out of StandardSession, which is too bad. Fixing this will require a fair amount of refactoring. - While developing apps you would sometimes like to wipe out all of the sessions, which is a bit awkward to do with persistence enabled because the server saves and restores them on restarts. Currently you would have to change the server.xml configuration for PersistentManager to disable all persistence and backups, and then it will clear out the Store when you restart. You can manually delete them from the directory used by FileStore, but this won't work with other Store implementations. Ideally there should be a command line argument which causes the Store to be cleared. PATCH COMMENTS Store.java - Added getManager(), setManager(), and clear() methods. FileStore.java - Implemented Store functionality, sessions are serialized one per file. PersistentManager - Implemented persistence across server restarts - Implemented swapping out of sessions to manage resources, based on the number of sessions in memory and idle times. - Stubs for backing up of sessions based on idle times, not yet implemented. server.xml - Added a commented out section to enable and configure PersistentManager LocalStrings.properties - Added strings for logging by FileStore and PersistentManager. Regards, Kief --- FileStore.java.orig Fri Aug 11 20:39:15 2000 +++ FileStore.java Fri Jan 12 21:55:02 2001 @@ -74,18 +74,27 @@ import java.io.FileNotFoundException; import java.io.FileOutputStream; import java.io.IOException; +import java.io.InputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; +import java.io.ObjectStreamClass; import java.io.Serializable; import java.util.Enumeration; import java.util.Hashtable; import java.util.Vector; +import javax.servlet.ServletContext; +import org.apache.catalina.Context; +import org.apache.catalina.Globals; import
[PATCHES] Catalina Session handling
This is the first of two sets of patches relating to sessions. The following
set will be my proposed session persistence package, while these are more
general and should be considered independently.
ManagerBase.java
- Fixed a bug where recycled sessions don't seem to have their Managers set.
The session.recycle() clears the manager, so the createSession() method should
set the manager if it uses a recycled session. It's possible this is done elsewhere,
but I don't see it, caused some NullPointerExceptions while testing my persistence
code.
- Fixed a bug where findSession() apparently doesn't call access() on the returned
session. The result is sessions will expire based on when they were first created,
not when they were last accessed. Again, this might be set somewhere else, but
it wasn't getting set in my persistence testing.
StandardSession.java
- Changed expire() to recycle the session if the Manager is a subclass of ManagerBase.
- Added activate() and passivate() methods which notify HttpSessionActivationListeners
when the session is activated or passivated, as per the Servlet 2.3 specification
PFD.
Kief
--- ManagerBase.java.orig Fri Jan 12 22:03:13 2001
+++ ManagerBase.javaFri Jan 12 21:22:44 2001
@@ -506,7 +506,9 @@
recycled.remove(size - 1);
}
}
- if (session == null)
+ if (session != null)
+ session.setManager(this);
+ else
session = new StandardSession(this);
// Initialize the properties of the new session and return it
@@ -544,7 +546,10 @@
if (id == null)
return (null);
synchronized (sessions) {
- return ((Session) sessions.get(id));
+ Session session = (Session) sessions.get(id);
+ if (session != null)
+ session.access();
+ return (session);
}
}
--- StandardSession.java.orig Thu Jan 11 23:01:02 2001
+++ StandardSession.javaFri Jan 12 22:17:50 2001
@@ -77,6 +77,7 @@
import java.util.Iterator;
import javax.servlet.ServletException;
import javax.servlet.http.HttpSession;
+import javax.servlet.http.HttpSessionActivationListener;
import javax.servlet.http.HttpSessionAttributesListener;
import javax.servlet.http.HttpSessionBindingEvent;
import javax.servlet.http.HttpSessionBindingListener;
@@ -538,10 +539,58 @@
// We have completed expire of this session
expiring = false;
+ if ((manager != null) (manager instanceof ManagerBase)) {
+ recycle();
+ ((ManagerBase) manager).recycle(this);
+ }
}
+/**
+ * Perform the internal processing required to passivate
+ * this session.
+ */
+public void passivate() {
+
+ // Notify ActivationListeners
+ HttpSessionEvent event = null;
+ String keys[] = keys();
+ for (int i = 0; i keys.length; i++) {
+ Object attribute = getAttribute(keys[i]);
+ if (attribute instanceof HttpSessionActivationListener) {
+ if (event == null)
+ event = new HttpSessionEvent(this);
+ // FIXME: Should we catch throwables?
+ ((HttpSessionActivationListener)attribute).sessionWillPassivate(event);
+ }
+ }
+
+}
+
+
+/**
+ * Perform internal processing required to activate this
+ * session.
+ */
+public void activate() {
+
+ // Notify ActivationListeners
+ HttpSessionEvent event = null;
+ String keys[] = keys();
+ for (int i = 0; i keys.length; i++) {
+ Object attribute = getAttribute(keys[i]);
+ if (attribute instanceof HttpSessionActivationListener) {
+ if (event == null)
+ event = new HttpSessionEvent(this);
+ // FIXME: Should we catch throwables?
+ ((HttpSessionActivationListener)attribute).sessionDidActivate(event);
+ }
+ }
+
+}
+
+
/**
* Return the codeisValid/code flag for this session.
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/doc faq
[EMAIL PROTECTED] wrote: nacho 01/01/12 17:12:23 Modified:src/doc Tag: tomcat_32 faq Log: src/doc/faq contains wrong information for overriding the JspServlet Submitter: David Rees ( [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ) [...] - org.apache.jasper.runtime.JSPServlet + org.apache.jasper.runtime.JspServlet Hmm... Doesn't look like you changed much ;-) "runtime" should be replaced with "servlet". If you don't have the time to fix this I will try to get to it this weekend. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources FileDirContext.java
remm01/01/12 21:15:56
Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java
Log:
- Fix minor path related problems.
- Still three unimplemented functions.
- Apparently, there are problems with encoding/decoding (so accessing files
containing spaces fail. This is probably a problem with the FileDirContext
implementation.
Revision ChangesPath
1.3 +8 -4
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java
Index: FileDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FileDirContext.java 2001/01/12 06:59:08 1.2
+++ FileDirContext.java 2001/01/13 05:15:55 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
1.2 2001/01/12 06:59:08 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2001/01/12 06:59:08 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
1.3 2001/01/13 05:15:55 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/01/13 05:15:55 $
*
*
*
@@ -97,7 +97,7 @@
* Filesystem Directory Context implementation helper class.
*
* @author Remy Maucherat
- * @version $Revision: 1.2 $ $Date: 2001/01/12 06:59:08 $
+ * @version $Revision: 1.3 $ $Date: 2001/01/13 05:15:55 $
*/
public class FileDirContext extends BaseDirContext {
@@ -796,7 +796,11 @@
} catch (IOException e) {
}
absPath = absPath.substring(absoluteBase.length());
+if (absPath.equals(""))
+absPath = "/";
canPath = canPath.substring(absoluteBase.length());
+if (canPath.equals(""))
+canPath = "/";
if ((canPath == null) || (absPath == null)
|| (!canPath.equals(absPath)))
return null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources DirContextURLStreamHandlerFactory.java DirContextURLConnection.java LocalStrings.properties
remm01/01/12 21:17:05
Modified:catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java
LocalStrings.properties
Added: catalina/src/share/org/apache/naming/resources
DirContextURLStreamHandlerFactory.java
Log:
- Added a factory for the stream handler.
- The URL connection will auto connect.
Revision ChangesPath
1.2 +57 -16
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
Index: DirContextURLConnection.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DirContextURLConnection.java 2001/01/12 06:59:08 1.1
+++ DirContextURLConnection.java 2001/01/13 05:17:04 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.1 2001/01/12 06:59:08 remm Exp $
- * $Revision: 1.1 $
- * $Date: 2001/01/12 06:59:08 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.2 2001/01/13 05:17:04 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/01/13 05:17:04 $
*
*
*
@@ -84,7 +84,7 @@
* content is directly returned.
*
* @author a href="mailto:[EMAIL PROTECTED]"Remy Maucherat/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class DirContextURLConnection
extends URLConnection {
@@ -132,6 +132,12 @@
protected Attributes attributes;
+/**
+ * Date.
+ */
+protected long date;
+
+
// - Properties
@@ -145,19 +151,24 @@
public void connect()
throws IOException {
-try {
-object = context.lookup(getURL().getFile());
-attributes = context.getAttributes(getURL().getFile());
-if (object instanceof Resource)
-resource = (Resource) object;
-if (object instanceof DirContext)
-collection = (DirContext) object;
-} catch (NamingException e) {
-// Object not found
+if (!connected) {
+
+try {
+date = System.currentTimeMillis();
+object = context.lookup(getURL().getFile());
+attributes = context.getAttributes(getURL().getFile());
+if (object instanceof Resource)
+resource = (Resource) object;
+if (object instanceof DirContext)
+collection = (DirContext) object;
+} catch (NamingException e) {
+// Object not found
+}
+
+connected = true;
+
}
-connected = true;
-
}
@@ -180,6 +191,14 @@
/**
* Return the last modified date.
*/
+public long getDate() {
+return date;
+}
+
+
+/**
+ * Return the last modified date.
+ */
public long getLastModified() {
return getHeaderFieldDate(ResourceAttributes.LAST_MODIFIED, 0);
}
@@ -189,6 +208,14 @@
* Returns the name of the specified header field.
*/
public String getHeaderField(String name) {
+if (!connected) {
+// Try to connect (silently)
+try {
+connect();
+} catch (IOException e) {
+}
+}
+
Attribute attribute = attributes.get(name);
try {
return attribute.get().toString();
@@ -196,6 +223,7 @@
// Shouldn't happen, unless the attribute has no value
}
return (null);
+
}
@@ -205,8 +233,11 @@
public Object getContent()
throws IOException {
+if (!connected)
+connect();
+
if (resource != null)
-return resource;
+return getInputStream();
if (collection != null)
return collection;
if (object != null)
@@ -241,8 +272,18 @@
public InputStream getInputStream()
throws IOException {
-if (resource == null)
-throw new IOException();
+if (!connected)
+connect();
+
+if (resource == null) {
+throw
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java LocalStrings.properties
remm01/01/12 21:20:05
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java LocalStrings.properties
Log:
- Fix lots of path related problems.
- Directory browser works again.
- The only known issues are :
- writing, which will fail because of functions which are not implemented yet
in the FileDirContext.
- accessing encoded URLs fail (like files with spaces in their names.
- WebDAV is broken at the moment, and needs a small revision of the
algorithms.
Revision ChangesPath
1.20 +11 -19
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- DefaultServlet.java 2001/01/12 06:55:34 1.19
+++ DefaultServlet.java 2001/01/13 05:20:05 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.19 2001/01/12 06:55:34 remm Exp $
- * $Revision: 1.19 $
- * $Date: 2001/01/12 06:55:34 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.20 2001/01/13 05:20:05 remm Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/01/13 05:20:05 $
*
*
*
@@ -118,7 +118,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.19 $ $Date: 2001/01/12 06:55:34 $
+ * @version $Revision: 1.20 $ $Date: 2001/01/13 05:20:05 $
*/
public class DefaultServlet
@@ -1439,12 +1439,6 @@
}
- if (!resourceInfo.exists()) {
- response.sendError(HttpServletResponse.SC_NOT_FOUND,
- resourceInfo.path);
- return;
- }
-
// Checking If headers
if ( !checkIfHeaders(request, response, resourceInfo) ) {
return;
@@ -1525,7 +1519,8 @@
if (content) {
// Serve the directory browser
-resourceInfo.is = render(resourceInfo);
+resourceInfo.is =
+render(request.getContextPath(), resourceInfo);
}
}
@@ -1738,9 +1733,8 @@
* @param contextPath Context path to which our internal paths are
* relative
*/
-public InputStream render(ResourceInfo resourceInfo) {
+public InputStream render(String contextPath, ResourceInfo resourceInfo) {
-String contextPath = resourceInfo.path;
String name = resourceInfo.path;
// Number of characters to trim from the beginnings of filenames
@@ -1785,8 +1779,8 @@
writer.print(rewriteUrl(contextPath));
if (parent.equals(""))
parent = "/";
-if (contextPath.endsWith("/"))
-parent = parent.substring(1);
+//if (contextPath.endsWith("/"))
+//parent = parent.substring(1);
writer.print(parent);
writer.print("\"");
writer.print(sm.getString("directory.parent", parent));
@@ -1821,7 +1815,7 @@
ResourceInfo childResourceInfo =
new ResourceInfo(resourceName, directory);
-String trimmed = resourceName.substring(trim);
+String trimmed = resourceName/*.substring(trim)*/;
if (trimmed.equalsIgnoreCase("WEB-INF") ||
trimmed.equalsIgnoreCase("META-INF"))
continue;
@@ -1835,9 +1829,7 @@
writer.print("td align=\"left\"nbsp;nbsp;\r\n");
writer.print("a href=\"");
writer.print(rewriteUrl(contextPath));
-resourceName = rewriteUrl(resourceName);
-if ((contextPath.endsWith("/")) (resourceName.length() 0))
-resourceName = resourceName.substring(1);
+resourceName = rewriteUrl(name + resourceName);
writer.print(resourceName);
writer.print("\"tt");
writer.print(trimmed);
1.4 +6 -0
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties,v
retrieving revision 1.3
retrieving revision
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core StandardContext.java
remm01/01/12 21:20:49
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- Fix path initialization of the DirContext.
Revision ChangesPath
1.35 +15 -10
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- StandardContext.java 2001/01/12 06:50:06 1.34
+++ StandardContext.java 2001/01/13 05:20:49 1.35
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.34 2001/01/12 06:50:06 remm Exp $
- * $Revision: 1.34 $
- * $Date: 2001/01/12 06:50:06 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.35 2001/01/13 05:20:49 remm Exp $
+ * $Revision: 1.35 $
+ * $Date: 2001/01/13 05:20:49 $
*
*
*
@@ -136,7 +136,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.34 $ $Date: 2001/01/12 06:50:06 $
+ * @version $Revision: 1.35 $ $Date: 2001/01/13 05:20:49 $
*/
public class StandardContext
@@ -922,12 +922,17 @@
if (container == null) {
docBase = (new File(engineBase(), getDocBase())).getPath();
} else {
-// Use the "appBase" property of this container
-String appBase = ((Host) container).getAppBase();
-File file = new File(appBase);
-if (!file.isAbsolute())
-file = new File(engineBase(), appBase);
-docBase = (new File(file, getDocBase())).getPath();
+File file = new File(getDocBase());
+if (!file.isAbsolute()) {
+// Use the "appBase" property of this container
+String appBase = ((Host) container).getAppBase();
+file = new File(appBase);
+if (!file.isAbsolute())
+file = new File(engineBase(), appBase);
+docBase = (new File(file, getDocBase())).getPath();
+} else {
+docBase = file.getPath();
+}
}
((BaseDirContext) resources).setDocBase(docBase);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core ApplicationContext.java
remm01/01/12 21:22:41
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
Log:
- Implement getRealPath (fixes Jasper).
- getRealPath() returns the name of the file which would be server by the
request. Note that a file does not necessarily exists.
Revision ChangesPath
1.11 +8 -5
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ApplicationContext.java 2001/01/12 06:50:06 1.10
+++ ApplicationContext.java 2001/01/13 05:22:40 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.10 2001/01/12 06:50:06 remm Exp $
- * $Revision: 1.10 $
- * $Date: 2001/01/12 06:50:06 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.11 2001/01/13 05:22:40 remm Exp $
+ * $Revision: 1.11 $
+ * $Date: 2001/01/13 05:22:40 $
*
*
*
@@ -66,6 +66,7 @@
import java.io.InputStream;
+import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.ArrayList;
@@ -104,7 +105,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.10 $ $Date: 2001/01/12 06:50:06 $
+ * @version $Revision: 1.11 $ $Date: 2001/01/13 05:22:40 $
*/
public final class ApplicationContext
@@ -351,7 +352,9 @@
*/
public String getRealPath(String path) {
-return (null);
+// Here, we return a fake path
+File file = new File(context.getDocBase(), path);
+return (file.getAbsolutePath());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: AccessLogUtil and minor patch to AccessLogValve
In diving through the documentation I found for log4j, and hitting the website I noticed...it is now part of the jakarta project (yay!). Seems like this would be a (much much much) better idea than my mostly-untested syslog code for an addition to the logger classes, any thoughts on this? David Weinrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
