BugRat Report #381 has been filed.
Bug report #381 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/381 REPORT #381 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: tomcat 4m4 JVM Release: sun jdk1.3 Operating System: linus OS Release: redhat 7 Platform: i386 Synopsis: can no longer forward to j_security_check Description: In tomcat 3.2 beta 4 (don't know about others) you could create a form based login which posted to a jsp instead of j_security_check. This allowed the jsp to store the username and password in the session and then forward the info on to j_security_check. This is required in order to use the username/password to connect to an external system from within a servlet. With Tomcat 4 milestone 4 this same method causes an exception when the jsp:forward occurs. It also creates an empty file in the login directory. Title: BugRat Report # 381 BugRat Report # 381 Project: Tomcat Release: tomcat 4m4 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Barry Dunne ([EMAIL PROTECTED]) Date Submitted: Nov 14 2000, 09:28:31 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: can no longer forward to j_security_check Environment: (jvm, os, osrel, platform) sun jdk1.3, linus, redhat 7, i386 Additional Environment Description: Report Description: In tomcat 3.2 beta 4 (don't know about others) you could create a form based login which posted to a jsp instead of j_security_check. This allowed the jsp to store the username and password in the session and then forward the info on to j_security_check. This is required in order to use the username/password to connect to an external system from within a servlet. With Tomcat 4 milestone 4 this same method causes an exception when the jsp:forward occurs. It also creates an empty file in the login directory. How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #382 has been filed.
Bug report #382 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/382 REPORT #382 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.1 JVM Release: 1.2.2 Operating System: AIX OS Release: 4.3.3 Platform: RS/6000 (M80) Synopsis: Tomcat stops after socket exception Description: In my current project I have a servlets which redirects requests to Tomcat/Jasper for chaching purposes. If a page hasn't changed, the page will be delivered directly from the servlet's cache instead of the JSP page. While working with Tomcat/Jasper on AIX I encountered the following problem: If I view a page with IE 5.0, press CTRL+F5 (reload all) and hold down these keys, IE obviously send out many requests which in turn causes the JVM to throw a SocketException in serverSocket.accept(). Tomcat catches this exception and sets running to false which kills Tomcat. If you comment out the line which stops Tomcat, everything is fine. hope this helps matthias Title: BugRat Report # 382 BugRat Report # 382 Project: Tomcat Release: 3.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Matthias Schoger ([EMAIL PROTECTED]) Date Submitted: Nov 14 2000, 11:33:59 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Tomcat stops after socket exception Environment: (jvm, os, osrel, platform) 1.2.2, AIX, 4.3.3, RS/6000 (M80) Additional Environment Description: Report Description: In my current project I have a servlets which redirects requests to Tomcat/Jasper for chaching purposes. If a page hasn't changed, the page will be delivered directly from the servlet's cache instead of the JSP page. While working with Tomcat/Jasper on AIX I encountered the following problem: If I view a page with IE 5.0, press CTRL+F5 (reload all) and hold down these keys, IE obviously send out many requests which in turn causes the JVM to throw a SocketException in serverSocket.accept(). Tomcat catches this exception and sets running to false which kills Tomcat. If you comment out the line which stops Tomcat, everything is fine. hope this helps matthias Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BugRat Report #380 has been filed.
BugRat Mail System wrote: Bug report #380 has just been filed. [...] Environment: Release: 3.2 Beta 7 JVM Release: 1.3 Operating System: Linux/NT OS Release: 2.2.16/4 Platform: any Synopsis: Sessions don't work without cookies Description: If Cookies are turned off in a browser the session-management by url-rewriting does not work. This bug was introduced by 3.2 beta6 and is still around in beta7 This is serious enough to warrant a fix before 3.2 goes final, IMHO. It used to work in 3.1 and the earlier 3.2 betas so it's a regression bug. I started to look at this one, and noticed that there are two interceptors that deal with sessions: * SessionInterceptor, seems to deal with session IDs in the URL but doesn't care about cookies. This one is invoked first. * StandardSessionInterceptor, seems to deal with session IDs received as cookies but doesn't care about session IDs in the URL. Before I start hacking here, can someone tell me why there are two interceptors and what the intention with the two are? Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BugRat Report #380 has been filed.
As close as I can tell, SessionInterceptor needs to be called first to parse the url sessionid out of the URL before it can be context mapped. StandardSessionInterceptor lets you work with the sessions once you know which context the request is going to. I've done some work in there, but I won't claim to know the original motivation for seperating them other than what is listed above. The motivation was simple: there are many ways to encode the ID in a request ( cookies, rewriting, SSL - plus special cases if the real server decodes the session, like in load-balancing cases ). There are many ways to store the sessions ( the simple hashtables we use in StandardSI, database, session migration, etc ). I thought it's better to separate the 2 problems and use 2 different modules. The storage module doesn't try to extract the session ID using cookies/rewriting/etc - that means someone can add a new sessionId decoding module without changing the storage module, and someone can write a new storage module without worry about session id encoding. Costin It might be possible to check the URL based session IDs in the same place as we check multiple cookies to find a valid one. Paul Hans Bergsten wrote: BugRat Mail System wrote: Bug report #380 has just been filed. [...] Environment: Release: 3.2 Beta 7 JVM Release: 1.3 Operating System: Linux/NT OS Release: 2.2.16/4 Platform: any Synopsis: Sessions don't work without cookies Description: If Cookies are turned off in a browser the session-management by url-rewriting does not work. This bug was introduced by 3.2 beta6 and is still around in beta7 This is serious enough to warrant a fix before 3.2 goes final, IMHO. It used to work in 3.1 and the earlier 3.2 betas so it's a regression bug. I started to look at this one, and noticed that there are two interceptors that deal with sessions: * SessionInterceptor, seems to deal with session IDs in the URL but doesn't care about cookies. This one is invoked first. * StandardSessionInterceptor, seems to deal with session IDs received as cookies but doesn't care about session IDs in the URL. Before I start hacking here, can someone tell me why there are two interceptors and what the intention with the two are? Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: *.apache.org traffic, configuration, etc
on 11/11/2000 5:10 PM, "Roy Wilson" [EMAIL PROTECTED] wrote: You mentioned that you thought *.apache.org gets 2M hits per day. Is there a (good?) source of info re: hardware/software/traffic information? Essentially, i think it is a piii 500mhz box, lots of disk space, i think around 500megs of ram and it is running FreeBSD. FreeBSD locus.apache.org 4.1-STABLE FreeBSD 4.1-STABLE #1: Fri Aug 25 02:56:11 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/locus i386 primary software is apache and qmail/ezmlm -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make rant
Hi Roy! If someone can provide a link to something like "Make for Dummies" I'd appreciate it. You betcha, and fyi-- this format is VERY similar to the make file Nick Bauman, myself and others use at our place of employment. (Some might say better!?) At the very least, it's well documented. http://geosoft.no/javamake.html enjoy. -Matthew PSI've been resisting the temptation to get involved on the ant rant thread, but this link might suggest I'm a Make fan. PPS I'm not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 4.0 -- JSP XML representation problems
Howdy... Tomcat 4.0 attempts to conform to the JSP 1.2 spec. JSP 1.2 specifies an XML representation for JSP pages. One is supposedly able to use the original syntax, or the new XML rep, but one CANNOT inter-mingle XML and the original syntax in the 1.2 spec. People, this is *awful*. All of my stuff breaks. For example: pThis version of the table was created by treating the nested content as the XML document (simulating the case where the JSP page itself would be rendering XML output), but using an external XSL stylesheet./p xsl:apply xsl="/xml/employeeList.xsl" ?xml version="1.0" encoding="ISO-8859-1"? employees employee id="123" first-nameJohn/first-name last-nameDoe/last-name telephone800-555-1212/telephone /employee employee id="456" first-nameJane/first-name last-nameSmith/last-name telephone888-555-1212/telephone /employee employee id="789" first-nameGeorge/first-name last-nameTaylor/last-name telephone555-555-1212/telephone /employee /employees /xsl:apply hr - This code cannot be incorporated into an "original-style" JSP page because its got XML in it. You have to go to the fully blown-out XML representation. I cannot really use the XML representation, because the jsp:cdata tag doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if I try to use this tag. It's actually worse than this, because my site uses XHTML -- the HTML pages are XML documents. I need Tomcat to emit XML, *INCLUDING* the DOCTYPE declaration. So by way of winding down this rant, has anyone been able to use the XSL taglib with Tomcat 4.0? Or any XML at all? -- boyd ps: I can see that ultimately, we'll have a clean xml rep of jsp, using the xml namespaces etc. But at the moment it's a mess... - Boyd Waters [EMAIL PROTECTED] National Radio Astronomy Observatory http://www.nrao.edu PO Box 0 Socorro, NM 87801 505.835.7346 http://www.zocalo.net/~waters [EMAIL PROTECTED] - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug-Report
I'am using Tomcat 3.2 beta 7 I am getting a "not found"-Response when posting a quite large file to a servlet (file upload with a filve about 30 Meg) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BUG] j_security_check forward no longer working
Hi, I need to trap the username and password entered by the user when accessing a secured web page, this is so that I can use this information when connecting to an external system in a servlet. The method I used was to have form based authentication but with the action posting to a jsp rather than j_security_check, the jsp then stores the username/password in the session and forwards the info on to j_security_check. This works perfectly with tomcat 3.2 beta 4, but tomcat 4 milestone 4 throws an exception and creates a blank file called j_security_check in the login directory. I am running on redhat linux 7 with sun jdk 1.3. The attached war file is the files I am using and the text file shows the different output when run in v3.2 and v4. Thanks, Barry. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. securitytest.war Output with tomcat 3.2 beta 4: User: tomcat Password: tomcat Output with tomcat 4 milestone 4: A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet.service() for servlet default threw exception at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:537) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:431) at login._0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32._jspService(_0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32.java:102) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:181) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:317) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:396) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:165) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:443) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:242) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:1876) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:343) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:785) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:902) at java.lang.Thread.run(Thread.java:484) Root Cause: java.lang.NullPointerException at org.apache.catalina.resources.FileResources.setResource(FileResources.java:586) at org.apache.catalina.servlets.DefaultServlet.doPut(DefaultServlet.java:401) at org.apache.catalina.servlets.DefaultServlet.doPost(DefaultServlet.java:365) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:517) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:431) at login._0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32._jspService(_0002flogin_0002fsecurity_0005fcheck_0002ejspsecurity_0005fcheck_jsp_32.java:102) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at
Re: [BUG] j_security_check forward no longer working
Barry Dunne wrote: Hi, I need to trap the username and password entered by the user when accessing a secured web page, this is so that I can use this information when connecting to an external system in a servlet. The method I used was to have form based authentication but with the action posting to a jsp rather than j_security_check, the jsp then stores the username/password in the session and forwards the info on to j_security_check. This works perfectly with tomcat 3.2 beta 4, but tomcat 4 milestone 4 throws an exception and creates a blank file called j_security_check in the login directory. I am running on redhat linux 7 with sun jdk 1.3. The attached war file is the files I am using and the text file shows the different output when run in v3.2 and v4. Thanks, Barry. Tomcat 4.0 should not throw an exception, but neither should it accept a form-based login unless the action is "j_security_check". See the Servlet 2.3 Spec (PFD), Section 12.5.3.1, p. 78. There's a similar section in the 2.2 spec that relates to Tomcat 3.2. Therefore, if Tomcat 3.2 is accepting your credentials when you post *to* a JSP page, as opposed to j_security_check, it is broken. The whole idea of form-based login is that, after you have successfully authenticated, you are returned to the page you originally asked for. The user experience should feel very similar to what happens with BASIC authentication -- the server pauses and asks for your username and password, but then proceeds to give you the page you asked for if you have successfully authenticated. Therefore, it doesn't really make any sense to talk about posting form based login criteria *to* a JSP page. On the other hand, it's perfectly reasonable to post *from* a JSP page -- that is what the example application does. It declares a JSP page as it's form-login-page. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BugRat Report #380 has been filed.
[EMAIL PROTECTED] wrote: I started to look at this one, and noticed that there are two interceptors that deal with sessions: * SessionInterceptor, seems to deal with session IDs in the URL but doesn't care about cookies. This one is invoked first. * StandardSessionInterceptor, seems to deal with session IDs received as cookies but doesn't care about session IDs in the URL. Before I start hacking here, can someone tell me why there are two interceptors and what the intention with the two are? The intention was to separate the module that extract the session id from a request from the module that provides the storage of session data. StandardSessionInterceptor was the original module, resulted from refactoring of session-related code. AFAIK ( or at least the intention was ) that StandardSessionInterceptor shouldn't deal in any way with finding the session id - it'll just store, find and create HttpSession and session attributes. The SessionInterceptor is ( possibly one of the ) modules that extract the session ID - it should be possible to add a SSLSessionIdInterceptor that implements SSL-based sessions, etc. The names are really bad - I know. StandardSessionInterceptor should be called "SimpleSessionStorageInterceptor" and the other one "StandardSessionIdInterceptor". I guess it's too late to change it. For 3.3 we can spend more time improving the interceptors. Okay, thanks for the info. I have found a fix to the problem that I'll post for review to the list in a second. If no one objects before tonight I'm going to commit it to the tomcat_32 branch. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ajpv13 protocol
Title: Ajpv13 protocol Is there a RFC on Ajp protocol? Or any documentation at all? -Sam
[TC 3.2b7 PATCH] Sessions without cookies [Was: Re: BugRat Report #380 has been filed.]
BugRat Mail System wrote:
Bug report #380 has just been filed.
[...]
Environment:
Release: 3.2 Beta 7
JVM Release: 1.3
Operating System: Linux/NT
OS Release: 2.2.16/4
Platform: any
Synopsis:
Sessions don't work without cookies
Description:
If Cookies are turned off in a browser the
session-management by url-rewriting does not work.
This bug was introduced by 3.2 beta6 and is still around
in beta7
Adding this to StandardSessionInterceptor seems to fix the problem.
I would appreciate if someone who has worked with the session
tracking stuff before can review this patch before I commit it to
the tomcat_32 branch. I really don't want to introduce new bugs in
3.2 this close to the release, but I feel this bug must be fixed.
// First check if we have a valid session ID from the URL, set
// by the SessionInterceptor, and if so, set it as the request
// session. If we have also received a valid session ID
// as a cookie, the next section of code will reset the session
// to the one matching the ID found in the cookie.
String requestedSessionID = request.getRequestedSessionId();
if (requestedSessionID != null) {
System.out.println("Found a requested session ID: " +
requestedSessionID);
sess = sM.findSession(requestedSessionID);
if (sess != null)
System.out.println("Found a requested session ID");
request.setSession(sess);
}
// The current cookie checking code comes here
...
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java
pierred 00/11/14 14:06:22
Modified:jasper/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
Log:
Bug fix: conversion of String to boolean was erroneous
Submitted by: Gareth Morgan [EMAIL PROTECTED]
Revision ChangesPath
1.3 +4 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JspRuntimeLibrary.java2000/09/26 00:47:56 1.2
+++ JspRuntimeLibrary.java2000/11/14 22:06:22 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
1.2 2000/09/26 00:47:56 pierred Exp $
- * $Revision: 1.2 $
- * $Date: 2000/09/26 00:47:56 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
1.3 2000/11/14 22:06:22 pierred Exp $
+ * $Revision: 1.3 $
+ * $Date: 2000/11/14 22:06:22 $
*
*
*
@@ -343,7 +343,7 @@
} else if (t.equals(boolean.class)) {
boolean[] tmpval = new boolean[values.length];
for (int i = 0 ; i values.length; i++)
- tmpval[i] = Boolean.getBoolean (values[i]);
+ tmpval[i] = (Boolean.valueOf(values[i])).booleanValue();
method.invoke (bean, new Object[] {tmpval});
} else if (t.equals(short.class)) {
short[] tmpval = new short[values.length];
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.0 -- JSP XML representation problems
Boyd, I cannot really use the XML representation, because the jsp:cdata tag doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if I try to use this tag. But you could still use ![CDATA[ ... ]] for your CDATA. jsp:cdata should be in tomcat-4.0 befroe the end of the week. ps: I can see that ultimately, we'll have a clean xml rep of jsp, using the xml namespaces etc. But at the moment it's a mess... With the community contributing constructive feedback, tests, code, patches, comments, etc, it will definitely get there faster... -- Pierre Boyd Waters wrote: Howdy... Tomcat 4.0 attempts to conform to the JSP 1.2 spec. JSP 1.2 specifies an XML representation for JSP pages. One is supposedly able to use the original syntax, or the new XML rep, but one CANNOT inter-mingle XML and the original syntax in the 1.2 spec. People, this is *awful*. All of my stuff breaks. For example: pThis version of the table was created by treating the nested content as the XML document (simulating the case where the JSP page itself would be rendering XML output), but using an external XSL stylesheet./p xsl:apply xsl="/xml/employeeList.xsl" ?xml version="1.0" encoding="ISO-8859-1"? employees employee id="123" first-nameJohn/first-name last-nameDoe/last-name telephone800-555-1212/telephone /employee employee id="456" first-nameJane/first-name last-nameSmith/last-name telephone888-555-1212/telephone /employee employee id="789" first-nameGeorge/first-name last-nameTaylor/last-name telephone555-555-1212/telephone /employee /employees /xsl:apply hr - This code cannot be incorporated into an "original-style" JSP page because its got XML in it. You have to go to the fully blown-out XML representation. I cannot really use the XML representation, because the jsp:cdata tag doesn't work with current Tomcat-4.0-devel. I get classCastExceptions if I try to use this tag. It's actually worse than this, because my site uses XHTML -- the HTML pages are XML documents. I need Tomcat to emit XML, *INCLUDING* the DOCTYPE declaration. So by way of winding down this rant, has anyone been able to use the XSL taglib with Tomcat 4.0? Or any XML at all? -- boyd ps: I can see that ultimately, we'll have a clean xml rep of jsp, using the xml namespaces etc. But at the moment it's a mess... - Boyd Waters [EMAIL PROTECTED] National Radio Astronomy Observatory http://www.nrao.edu PO Box 0 Socorro, NM 87801 505.835.7346 http://www.zocalo.net/~waters [EMAIL PROTECTED] - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building nsapi_redirector
I think the problem is that the project file has carriage-returns only at the end of each line, rather than CRLF. You can verify this by opening the project file in notepad. Instead of looking like 'normal' text, it is all on one line. If you delete the CRs, and insert your own CRLF in notepad, then you should be able to build the project. Could someone fix the project files before final release, so that they don't require manual editing? Thanks, Barbara Nelson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Client certificates in Tomcat 3.2beta7
I am testing Tomcat standalone with client authentication on, and getting some odd results. It works fine if client authentication is not turned on (for both IE and Netscape browsers). If I turn on client authentication, Netscape claims that I do not have a personal certificate, and IE asks me to choose from an empty list of certificates. If I go via Apache/SSL, and redirect to Tomcat, it works fine. Netscape lets me choose the certificate, IE shows the certificate in the list, and I can see the certificate in the SnoopServlet output. Any ideas on the problem with the certificate request when I use Tomcat standalone? Is there some configuration to indicate the type of certificate the server is requesting? I am using a self-signed certificate, generated via keytool, on the server. In the browser, I have a verisign personal certificate. Many thanks, Barbara Nelson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TC 3.2b7 PATCH] Sessions without cookies [Was: Re: BugRat Report#380 has been filed.]
Hi Hans,
The patch is great, +1 from me. ( it's the way the code was supposed to
work - if you look back 2-3 revisions for that file you'll find very
similar code ). It seems the patch for "multiple session cookies" broke
this part - it's great that we fix it back.
For 3.3 we should probably move the code that extracts the session id from
cookies back to the request/SessionInterceptor ( and rename it
SessionIdInterceptor ).
Costin
// First check if we have a valid session ID from the URL, set
// by the SessionInterceptor, and if so, set it as the request
// session. If we have also received a valid session ID
// as a cookie, the next section of code will reset the session
// to the one matching the ID found in the cookie.
String requestedSessionID = request.getRequestedSessionId();
if (requestedSessionID != null) {
System.out.println("Found a requested session ID: " +
requestedSessionID);
sess = sM.findSession(requestedSessionID);
if (sess != null)
System.out.println("Found a requested session ID");
request.setSession(sess);
}
// The current cookie checking code comes here
...
Hans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: *.apache.org traffic, configuration, etc
Thanks, Jon Roy Original Message On 11/14/00, 4:21:49 PM, Jon Stevens [EMAIL PROTECTED] wrote regarding Re: *.apache.org traffic, configuration, etc: on 11/11/2000 5:10 PM, "Roy Wilson" [EMAIL PROTECTED] wrote: You mentioned that you thought *.apache.org gets 2M hits per day. Is there a (good?) source of info re: hardware/software/traffic information? Essentially, i think it is a piii 500mhz box, lots of disk space, i think around 500megs of ram and it is running FreeBSD. FreeBSD locus.apache.org 4.1-STABLE FreeBSD 4.1-STABLE #1: Fri Aug 25 02:56:11 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/locus i386 primary software is apache and qmail/ezmlm -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajpv13 protocol
Is there a RFC on Ajp protocol? Or any documentation at all? No, there are just incremental enhancements and changes to Ajp11 - and I would say we might still have some changes and enhancements. ( there are additional messages that will probably be needed, the current stuff is stable and if it can be documented if anyone volunteers to do so, but there are few more things planed for ajp13 that are not yet implemented. ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector RequestBase.java
remm00/11/14 16:46:41
Modified:catalina/src/share/org/apache/catalina/connector
RequestBase.java
Log:
- Make sure the request bytes are always consumed.
Revision ChangesPath
1.6 +9 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java
Index: RequestBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RequestBase.java 2000/10/13 05:27:33 1.5
+++ RequestBase.java 2000/11/15 00:46:41 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
1.5 2000/10/13 05:27:33 craigmcc Exp $
- * $Revision: 1.5 $
- * $Date: 2000/10/13 05:27:33 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
1.6 2000/11/15 00:46:41 remm Exp $
+ * $Revision: 1.6 $
+ * $Date: 2000/11/15 00:46:41 $
*
*
*
@@ -97,7 +97,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.5 $ $Date: 2000/10/13 05:27:33 $
+ * @version $Revision: 1.6 $ $Date: 2000/11/15 00:46:41 $
*/
public abstract class RequestBase
@@ -482,6 +482,11 @@
* @exception IOException if an input/output error occurs
*/
public void finishRequest() throws IOException {
+
+// If neither a reader or an is have been opened, do it to consume
+// request bytes, if any
+if ((reader == null) (stream == null))
+getInputStream();
// If a Reader has been acquired, close it
if (reader != null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpRequestBase.java
remm00/11/14 16:52:35
Modified:catalina/src/share/org/apache/catalina/connector
HttpRequestBase.java
Log:
- Fix POST parameters decoding : parameters on the URL are decoded
using RequestUtil.URLDecode instead of java.net.URLDecoder.decode
Revision ChangesPath
1.13 +9 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java
Index: HttpRequestBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- HttpRequestBase.java 2000/10/28 01:39:43 1.12
+++ HttpRequestBase.java 2000/11/15 00:52:35 1.13
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
1.12 2000/10/28 01:39:43 craigmcc Exp $
- * $Revision: 1.12 $
- * $Date: 2000/10/28 01:39:43 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
1.13 2000/11/15 00:52:35 remm Exp $
+ * $Revision: 1.13 $
+ * $Date: 2000/11/15 00:52:35 $
*
*
*
@@ -98,7 +98,7 @@
* be implemented.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.12 $ $Date: 2000/10/28 01:39:43 $
+ * @version $Revision: 1.13 $ $Date: 2000/11/15 00:52:35 $
*/
public class HttpRequestBase
@@ -581,7 +581,7 @@
String queryString = getQueryString();
if ((queryString != null) (queryString.length() 0)) {
try {
- RequestUtil.parseParameters(results, queryString);
+ RequestUtil.parseParameters(results, queryString, true);
} catch (Throwable t) {
;
}
@@ -609,10 +609,11 @@
String data = null;
String encoding = getCharacterEncoding();
if (encoding == null)
- RequestUtil.parseParameters(results, new String(buf));
+ RequestUtil.parseParameters
+(results, new String(buf), false);
else
- RequestUtil.parseParameters(results,
- new String(buf, encoding));
+ RequestUtil.parseParameters
+(results, new String(buf, encoding), false);
} catch (Throwable t) {
;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java
remm00/11/14 16:52:45
Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
Log:
- Fix POST parameters decoding : parameters on the URL are decoded
using RequestUtil.URLDecode instead of java.net.URLDecoder.decode
Revision ChangesPath
1.9 +17 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java
Index: RequestUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- RequestUtil.java 2000/10/28 01:39:45 1.8
+++ RequestUtil.java 2000/11/15 00:52:45 1.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
1.8 2000/10/28 01:39:45 craigmcc Exp $
- * $Revision: 1.8 $
- * $Date: 2000/10/28 01:39:45 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
1.9 2000/11/15 00:52:45 remm Exp $
+ * $Revision: 1.9 $
+ * $Date: 2000/11/15 00:52:45 $
*
*
*
@@ -79,7 +79,7 @@
* General purpose request parsing and encoding utility methods.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.8 $ $Date: 2000/10/28 01:39:45 $
+ * @version $Revision: 1.9 $ $Date: 2000/11/15 00:52:45 $
*/
public final class RequestUtil {
@@ -217,10 +217,12 @@
*
* @param map Map that accumulates the resulting parameters
* @param data Input string containing request parameters
+ * @param urlParameters true if we're parsing parameters on the URL
*
* @exception IllegalArgumentException if the data is malformed
*/
-public static void parseParameters(Map map, String data) {
+public static void parseParameters(Map map, String data,
+ boolean urlParameters) {
if ((data == null) || (data.length() 1))
return;
@@ -260,14 +262,22 @@
// Decode the name and value if required
if ((name.indexOf('%') = 0) || (name.indexOf('+') = 0)) {
try {
-name = URLDecoder.decode(name);
+if (urlParameters) {
+name = URLDecode(name);
+} else {
+name = URLDecoder.decode(name);
+}
} catch (Throwable t) {
;
}
}
if ((value.indexOf('%') = 0) || (value.indexOf('+') = 0)) {
try {
-value = URLDecoder.decode(value);
+if (urlParameters) {
+value = URLDecode(value);
+} else {
+value = URLDecoder.decode(value);
+}
} catch (Throwable t) {
;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java
remm00/11/14 16:52:51
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
Log:
- Fix POST parameters decoding : parameters on the URL are decoded
using RequestUtil.URLDecode instead of java.net.URLDecoder.decode
Revision ChangesPath
1.2 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
Index: ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ApplicationHttpRequest.java 2000/08/23 01:07:11 1.1
+++ ApplicationHttpRequest.java 2000/11/15 00:52:50 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
1.1 2000/08/23 01:07:11 craigmcc Exp $
- * $Revision: 1.1 $
- * $Date: 2000/08/23 01:07:11 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
1.2 2000/11/15 00:52:50 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2000/11/15 00:52:50 $
*
*
*
@@ -92,7 +92,7 @@
* keep these two classes in synchronization when making changes!
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2000/08/23 01:07:11 $
+ * @version $Revision: 1.2 $ $Date: 2000/11/15 00:52:50 $
*/
class ApplicationHttpRequest extends HttpServletRequestWrapper {
@@ -450,7 +450,7 @@
return;
HashMap queryParameters = new HashMap();
- RequestUtil.parseParameters(queryParameters, queryString);
+ RequestUtil.parseParameters(queryParameters, queryString, true);
synchronized (parameters) {
Iterator keys = parameters.keySet().iterator();
while (keys.hasNext()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #355 was closed (apparently by: Remy Maucherat)
Report #355 was closed by Person #0 Synopsis: java.net.SocketException ConnectionReset by peer (logged in as: Remy Maucherat) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping Requests to Servlets
I think you'll find what you're looking for in org.apache.tomcat/request/SimpleMapper1.java though I must confess to being no expert ;-) -T Aron Kramlik wrote: Hi, Could someone point me to the class in Tomcat where the servlet mappings are implemented. i.e. Chapter 10 of the 2.2 spec "Mapping Requests to Servlets". In particular I am looking for the implementation of the wildcard rules. Thanks, Aron. -- Aron Kramlik. [EMAIL PROTECTED] Tenzing Communications Inc. www.tenzing.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session StandardSessionInterceptor.java
bergsten00/11/14 20:19:20
Modified:src/share/org/apache/tomcat/session Tag: tomcat_32
StandardSessionInterceptor.java
Log:
Fix to Bug Report #380
Added code for setting the session in the Request for the case
when the session ID is received as part of the URL.
Revision ChangesPath
No revision
No revision
1.5.2.2 +14 -0
jakarta-tomcat/src/share/org/apache/tomcat/session/StandardSessionInterceptor.java
Index: StandardSessionInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/session/StandardSessionInterceptor.java,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- StandardSessionInterceptor.java 2000/11/11 02:07:02 1.5.2.1
+++ StandardSessionInterceptor.java 2000/11/15 04:19:19 1.5.2.2
@@ -85,6 +85,7 @@
* session stuff ( cookie, rewrite, etc)
*
* @author [EMAIL PROTECTED]
+ * @author [EMAIL PROTECTED] (fixed it so that URL session ID is used)
*/
public final class StandardSessionInterceptor extends BaseInterceptor {
int manager_note;
@@ -121,6 +122,19 @@
log( "Configuration error in StandardSessionInterceptor - no context " +
request );
}
+ // Added by Hans:
+ // First check if we have a valid session ID from the URL, set by the
SessionInterceptor,
+ // and if so, set it as the request session. If we have also received a valid
session ID
+ // as a cookie, the next section of code will reset the session to the one
matching the
+ // ID found in the cookie.
+ String requestedSessionID = request.getRequestedSessionId();
+ if (requestedSessionID != null) {
+ if (debug 0) log("Found URL session ID: " + requestedSessionID);
+ sess = sM.findSession(requestedSessionID);
+ if (sess != null)
+ if (debug 0) log("The URL session ID is valid");
+ request.setSession(sess);
+ }
// PF, loop across all cookies named JSESSIONID checking to see if any of them
are valid.
// There should in most cases be a maximum of 2, and normally there will only
be one. The
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Closing Bug Reports?
I tried to find a way to close the following Bug Report through the admin interface, but no matter which option I choose I only get the admin menu: Bug report #380 has just been filed. [...] Synopsis: Sessions don't work without cookies If someone else has more BugRat karma than I do, please close this one since I have committed a solution to the tomcat_32 branch. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #386 has been filed.
Bug report #386 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/386 REPORT #386 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.12 JVM Release: 1.3 Operating System: SUN OS Release: 2.7 Platform: Solaris Synopsis: Communication Breakdown between Apache and Tomcat Description: I am running Tomcat 3.12 with ssl-aware Apache 1.3.12. We have compiled the mod_jserv.so for Solaris. The application runs fine with 4-5 users, but when the user base increase (to 20-25), the response of the system becomes very slow. Besides, we get an error: BROKEN PIPE. I believe this is a problem of communication between apache and tomcat. Can anyone help us out to resolve this problem? Thanks Regards, Sharad Kumar. Title: BugRat Report # 386 BugRat Report # 386 Project: Tomcat Release: 3.12 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Sharad Kumar ([EMAIL PROTECTED]) Date Submitted: Nov 15 2000, 01:44:37 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Communication Breakdown between Apache and Tomcat Environment: (jvm, os, osrel, platform) 1.3, SUN, 2.7, Solaris Additional Environment Description: ssl-aware Apache 1.3.12 with Tomcat 3.12 and Cocoon 1.8. The platform is Solaris, Sun Os: 2.7 Report Description: I am running Tomcat 3.12 with ssl-aware Apache 1.3.12. We have compiled the mod_jserv.so for Solaris. The application runs fine with 4-5 users, but when the user base increase (to 20-25), the response of the system becomes very slow. Besides, we get an error: BROKEN PIPE. I believe this is a problem of communication between apache and tomcat. Can anyone help us out to resolve this problem? Thanks & Regards, Sharad Kumar. How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
