[OT] Holiday Reading - Refactoring
Hi guys, I read from some threads that Costin mentioned that 3.3 is a refactoring of 3.2 code. Here I found an article about Refactoring: http://www.sdmagazine.com/articles/2000/0012/0012b/0012b.htm Enjoy! Merry X'mas Punky
Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)
Craig,
Here's one step towards what you were asking for. It's a standalone test case of the
problem. I've written this because, judging from some of the issues that were
occuring with Cocoon, I have a feeling that this problem is System/Java version
dependent. The problem has been seen on Solaris, MacOS X and Windows with versions
1.2.2 and 1.3, but it may be only in certain combinations.
If this test case reproduces the problem on your system, then were going in the right
direction. If not, then we'll never produce a test case for you to be able to test.
Here's the code:
import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
public class Test {
public static void main(String args[]) {
System.out.println("STARTED");
try {
String filename = "jac.zip";
String filepath2 = "/Users/stuart/";
String filepath3 = "Documents/../temp/";
String filepath = filepath2 + filepath3;
System.out.println("filepath = " + filepath);
System.out.println("filepath2 = " + filepath2);
System.out.println("filepath3 = " + filepath3);
System.out.println("filename = " + filename);
File file1 = new File(filepath, filename);
System.out.println("file1 = new File(filepath, filename) = " +
file1.toString());
System.out.println("file1.getAbsolutePath() = " + file1.getAbsolutePath());
System.out.println("file1.getCanonicalPath() = " +
file1.getCanonicalPath());
URL url1 = new URL("file:" + filepath);
URL url2 = new URL("file", null, -1, filepath);
URL url3 = new URL("file", null, filepath);
URL url4 = new URL(new URL("file:"+filepath2), filepath3);
System.out.println("url1 = new URL(\"file:\" + filepath) = " + url1);
System.out.println("url2 = new URL(\"file:\", null, -1, filepath) = " +
url2);
System.out.println("url3 = new URL(\"file:\", null, filepath) = " + url3);
System.out.println("url4 = new URL(new URL(\"file:\"+filepath2),
filepath3) = " + url4);
//URL inUrls [] = {url1, url2, url3, url4};
URL inUrls1 [] = {url2,url3};
URL inUrls2 [] = {url1,url4};
URLClassLoader classLoader1 = new URLClassLoader(inUrls1);
URLClassLoader classLoader2 = new URLClassLoader(inUrls2);
URL outUrls1 [] = classLoader1.getURLs();
URL outUrls2 [] = classLoader2.getURLs();
for (int i = 0; i outUrls1.length; i++) {
System.out.println("outUrls1["+i+"] = " + outUrls1[i]);
}
for (int i = 0; i outUrls2.length; i++) {
System.out.println("outUrls2["+i+"] = " + outUrls2[i]);
}
System.out.println("Resource found by classloader1 = " +
classLoader1.findResource(filename));
System.out.println("Resource found by classloader2 = " +
classLoader2.findResource(filename));
} catch (Exception e) {
System.out.println(e);
}
System.exit(0);
}
}
Please substitute in appropriate values for filepath2, filepath3 and filename.
filepath3 should contain a "../" element, filepath + filename should point to a real
file on your system.
My test results are:
STARTED
filepath = /Users/stuart/Documents/../temp/
filepath2 = /Users/stuart/
filepath3 = Documents/../temp/
filename = jac.zip
file1 = new File(filepath, filename) = /Users/stuart/Documents/../temp/jac.zip
file1.getAbsolutePath() = /Users/stuart/Documents/../temp/jac.zip
file1.getCanonicalPath() = /Users/stuart/temp/jac.zip
url1 = new URL("file:" + filepath) = file:/Users/stuart/temp/
url2 = new URL("file:", null, -1, filepath) = file:/Users/stuart/Documents/../temp/
url3 = new URL("file:", null, filepath) = file:/Users/stuart/Documents/../temp/
url4 = new URL(new URL("file:"+filepath2), filepath3) = file:/Users/stuart/temp/
outUrls1[0] = file:/Users/stuart/Documents/../temp/
outUrls1[1] = file:/Users/stuart/Documents/../temp/
outUrls2[0] = file:/Users/stuart/temp/
outUrls2[1] = file:/Users/stuart/temp/
Resource found by classloader1 = null
Resource found by classloader2 = file:/Users/stuart/temp/jac.zip
Stuart.
On Thursday, December 21, 2000, at 06:56 PM, Craig R. McClanahan wrote:
Stuart Roebuck wrote:
In the course of fixing a problem I was having getting Apache Cocoon to run, I
came across a
bug in Java in the File.toURL() method. This fault, combined with the use of the
URLClassLoader resulted in a classloading issue.
Stuart,
I'm trying to create a simple, reproducible test case that causes Tomcat 4.0 to fail
because of this -- but so far, I have not been able to.
For example, I would assume that the following scenario should fail due to this
problem:
* Run on Linux (RH 6.2) + JDK 1.2.2
* Do *not* set the CATALINA_HOME
Jasper Architecture Question (Was: How to do my own JSP processing)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 19:23 To: [EMAIL PROTECTED] Subject: Re: How to do my own JSP processing Sounds like you are planning on inventing your own variant of a servlet+JSP server, since you're wanting to change or ignore many of the spec requirements. And you will end up with an app that will only run in your own server. Unless you like building servers as a hobby, you've got a *lot* of hard work ahead of you. I would suggest you look at how you can architect your application *within* the requirements of the servlet and JSP specs. That way, you can focus on writing an app rather than a server, and have some assurance that you can run that app elsewhere if and when you outgrow Tomcat. Actually I have my own template language which is compiled to a JSP file. Everything is supposed to be as much Servlet 2.3 spec conformant as possible. Here is a simplistic view on my main servlet service() 1. begin database transaction 2. do some business logic 3. execute JSP file 4. commit transaction 5a. if commit successful send response content to the network 5b. if not generate error response (and discard result of JSP) The problems with 3.) are I.) the JSP files are located outside my servlet context II.) JSP execution must be buffered because the content is not be sent before the database transaction commits III.) the JSP execution must be able to set response header lines (e.g. cookie) IV.) it should be possible in JSPs to use tag libraries and do all other things possible if the JSP is served directly by Tomcat Because of I.) I cant use a "simple" servlet request dispatcher II.) forward() won't work because if the forward() returns the response is already committed and closed by the container III.) includes() won't do because I can't set headers On top of this I want my servlet to pick a JSP file, run it, capture the output and send this output be email before saying "sending email was successful." over HTTP. From what I read about Jasper it should be possible to call it compile my JSPs and trigger their execution independent of the all of this is running in a servlet itself or a standalone application, right? Thanks Christian PS: I know it will be a nice piece of work ... -- Christian Mallwitz INTERSHOP Communications Germany Senior Software Engineerphone: +49 3641 50 3453
RE: Tomcat session replicator
Interesting subject, a farm of Apache behind a larger farm of Tomcats ? Let me develop : Could we have say a farm of X Apache connected to a farm of Y Tomcat where Y = 2 * X or Y = 3 * X ? Also could the session replicator be compatible with eventuals ACL/Crypto in mod_jk/ajp protocols ? "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire
Question about auth-method=CLIENT-CERT on web.xml file ?
Yes I understand what you said about CLIENT-CERT and I add a new entry in my tomcat-usr.xml file : 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 Functions getSubjectDN().getName() return OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr value for the first certificate chain, so I consider this value is the new user name. I have yet auth-method into CLIENT-CERT value and when I try to connect on my tomcat serveur I have the same message : You are not authorized to view this page My local_host_access.log file give me this information : camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:07:50 1000] GET /examples/servlet/SnoopServlet HTTP/1.1 200 4017 camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:08:32 1000] GET /examples/servlet/SnoopServlet HTTP/1.1 403 - So I try to cut attribut password on tomcat-users file because when I use a certificate I don't understand what I would say... but with no success... Is it possible that value OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr as too complicate for a user name Thank you if you are a another good idea ? Best Regards Jérôme Craig McClanahan écrit : [EMAIL PROTECTED] wrote: Hello, I try to use the auth-method of web.xml to CLIENT-CERT value like it's precise on web.dtd So the fragment of web.xml file !-- Default login configuration uses form-based authentication -- login-config auth-methodCLIENT-CERT/auth-method realm-nameExample Form-Based Authentication Area/realm-name form-login-config form-login-page/jsp/security/login/login.jsp/form-login-page form-error-page/jsp/security/login/error.jsp/form-error-page /form-login-config /login-config When I try to access on a url-pattern who is protect by a security-constraint with https on port 8443, I always have the same response on the catalina server : You are not authorized to view this page When you use CLIENT-CERT login plus a security constraint, what you are asking Catalina to do is look up the authenticated client in its Realm (by default, the MemoryRealm that reads from $CATALINA_HOME/conf/tomcat-users.xml), to (a) make sure that the client is present in the Realm, and (b) look up the associated roles to verify against the security constraint. The username that is looked up is the value returned by calling getSubjectDN().getName() on the first certificate in the certificate chain -- in other words, the principal name of the client that was authenticated by this certificate. If all you want to do is make sure the client has a valid certificate, you don't need to use a security constraint at all -- just set the clientAuth property on the Connector to true, and no requests will be accepted without a certificate. On the other hand, if you want to use security constraints in addition, you will need to define the user (and associated roles) in your Realm, just as you would for any other login method. Anybody know where do I find any information about this fonctionnality whas I bad used ? Best regards JérômeCraig McClanahan
VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session replicator)
Shai has contributed great bug fixes ( one specially difficult in 3.2, thanks Shai ) and he wants to contribute a distributed session manager It has been proposed as committer by Craig in a informal way, now it's proposed in a formal way :-) it has my +1 as well +1 from Craig in the message below. Votes , please. Saludos , Ignacio J. Ortega -Mensaje original- De: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Enviado el: jueves 21 de diciembre de 2000 20:14 Para: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: Tomcat session replicator Shai, I apologize for not responding to you earlier ... substantive discussions are getting a little lost in the noise at the moment. For some reason, my Netscape mail reader won't let me intersperse comments -- so I've put them at the end. I think I read into your earlier comment that you'd be interested in being a committer to work on this stuff. If you're still interested, you've got my +1. Craig [EMAIL PROTECTED] wrote: Hi, Two weeks ago I posted note here saying Im going to write patch for Tomcat 3.2 to support redundancy, in manner of having session information stored between reloads and shared between tomcat instances. In order to support tomcat redundancy I thought on implementing that in two phases: 1. (dumping) While shutting down Tomcat it will save sessions in file and reload them while going up. This feature will allow restarting tomcat without loosing state. 2. (replication) Sending session from one Tomcat to another (AKA: buddy). This will allow the session to have backup on another machine. mod_jkwill send user connection requests to the second machine while the original machine is unavailable. Number 1. above is already implemented, and 2. is going to be finish soon. The question I have is: Should I implement the session replicator listener as stand-alone connector, or incorporate in into Ajpv13? This will require adding two commands to the protocol implementation. Options: 1. Stand-alone connector. This will require another listener. 2. Incorporate it into Ajp13. 3. Incorporate it into Ajp13 and calling it Ajp14. Other ideas? Implementation details will be followed soon. Shai Fultheim Chief Technology Officer BRM Seed E-Mail: [EMAIL PROTECTED] Mobile: 972-53-866-459 Office: 972-2-5891-459 The biggest problem I have with integrating session replication into AJPxx is that it means this will only work if you're running Apache connected, versus when Tomcat is running stand alone. Even in that environment, does the Apache instance really need to know what's going on? Wouldn't it just be a case of updating the cookie to include the new "router" information when you migrate a session from one JVM to another? Personally, I'd like to see a session migration mechanism that works between the "back end" Tomcat instances. There are probably few enough of those (in most use cases) that you can maintain a spiderweb of persistent connections that is used only to communicate session migration information. Just as a small technical detail -- the servlet spec says that an application *must* run within a single JVM unless it marks itself as distributable/ in the deployment descriptor -- don't forget to check for that. As to what version of Tomcat to work on, no matter what the future holds it seems like the current 3.2 code base is not really appropriate for major innovation. I would only point out that the 4.0 architecture has an interface (org.apache.catalina.Store) behind which session migration stuff can easily be hidden -- as well as support for persistence, swapping, and other advanced features -- without modifying the remainder of the servlet container. Several other folks have expressed interest in working on this at various times, so collaboration would be quite useful. Craig McClanahan
Re: VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session replicator)
+1 for Shai Fultheim -- Pierre
Re: back port to 3.2 -- JspInterceptor
Hi Costin, JspInterceptor is not "enabled" in 3.2 - it was one of the changes I wanted to spend more time into and make sure it's stable enough. It'll be used in 3.3 - or whatever will be called. Thanks for the clarification. However since it is being compiled in the build, it is "somewhat" enabled :-). I'll just comment out the part that does not compile (with proper references). BTW, did you fixed the command line compiler ? JspInterceptor is based on the command line compiler, so if you fix the first it'll be very easy for me to fix the 3.3 interceptor. Sorry, my radar must have missed this one. If you can give me pointers/info, I'll look into it. -- Pierre
BugRat Report #653 has been filed.
Bug report #653 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/653 REPORT #653 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: webbug State: received Priority: high Severity: serious Confidence: confidential Environment: Release: tomcat 3.2.1 JVM Release: 1.2.2 Operating System: linux OS Release: 2.2.16 Platform: Intel Synopsis: Incorrect HTTP header returns source file (jsp) Description: Do: = telnet localhost 8080 GET /path/filename.jsp = Note the missing HTTP/1.0 or ... Title: BugRat Report # 653 BugRat Report # 653 Project: Tomcat Release: tomcat 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: webbug State: received Priority: high Severity: serious Confidence: confidential Submitter: Manoel Sa ([EMAIL PROTECTED]) Date Submitted: Dec 22 2000, 07:51:53 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Incorrect HTTP header returns source file (jsp) Environment: (jvm, os, osrel, platform) 1.2.2, linux, 2.2.16, Intel Additional Environment Description: Report Description: Do: = telnet localhost 8080 GET /path/filename.jsp = Note the missing HTTP/1.0 or ... View this report online...
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request JspInterceptor.java
pierred 00/12/22 06:19:15
Modified:src/share/org/apache/jasper Tag: tomcat_32
EmbededServletOptions.java JspC.java Options.java
src/share/org/apache/jasper/compiler Tag: tomcat_32
Compiler.java
src/share/org/apache/jasper/resources Tag: tomcat_32
messages.properties
src/share/org/apache/tomcat/request Tag: tomcat_32
JspInterceptor.java
Log:
Bug fix: bug report #269 -- java.io.UnsupportedEncodingException when processing JSP
From the bug report:
"A "java.io.UnsupportedEncodingException: UTF8" is thrown when generating
the servlet for a JSP file when the Kaffe VM is used. The "UTF8" encoding
name is hardcoded in the Compiler class as the encoding for the generated
servlet source code file. I believe the reason for using "UTF8" as opposed
to "UTF-8" (note the dash) is that this is the only name supported in
JDK 1.1. I suggest adding an init parameter to JspServlet for setting
the encoding name when "UTF8" doesn't work."
Given that there are several possible representations of Unicode data
(UTF-8, UTF-16, UTF-32), and given that the supported encodings vary
between different implementations of the Java platform,
the best way to tackle this is probably as suggested by Hans.
Submitted by: Hans Bergsten ( [EMAIL PROTECTED] )
Revision ChangesPath
No revision
No revision
1.4.2.1 +14 -4
jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.4
retrieving revision 1.4.2.1
diff -u -r1.4 -r1.4.2.1
--- EmbededServletOptions.java2000/05/26 18:55:09 1.4
+++ EmbededServletOptions.java2000/12/22 14:19:10 1.4.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v 1.4
2000/05/26 18:55:09 costin Exp $
- * $Revision: 1.4 $
- * $Date: 2000/05/26 18:55:09 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.4.2.1 2000/12/22 14:19:10 pierred Exp $
+ * $Revision: 1.4.2.1 $
+ * $Date: 2000/12/22 14:19:10 $
*
*
*
@@ -135,6 +135,11 @@
*/
public String jspCompilerPath = null;
+/**
+ * Java platform encoding to generate the JSP
+ * page servlet.
+ */
+private String javaEncoding;
/**
* Are we keeping generated code around?
@@ -207,6 +212,10 @@
return jspCompilerPath;
}
+public String getJavaEncoding() {
+ return javaEncoding;
+}
+
/**
* Create an EmbededServletOptions object using data available from
* ServletConfig and ServletContext.
@@ -309,7 +318,8 @@
Logger.FATAL);
}
}
-
+
+this.javaEncoding = config.getInitParameter("javaEncoding");
}
}
1.15.2.2 +7 -3 jakarta-tomcat/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.15.2.1
retrieving revision 1.15.2.2
diff -u -r1.15.2.1 -r1.15.2.2
--- JspC.java 2000/07/12 16:04:20 1.15.2.1
+++ JspC.java 2000/12/22 14:19:10 1.15.2.2
@@ -1,7 +1,7 @@
/*
- * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v
1.15.2.1 2000/07/12 16:04:20 shemnon Exp $
- * $Revision: 1.15.2.1 $
- * $Date: 2000/07/12 16:04:20 $
+ * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,v
1.15.2.2 2000/12/22 14:19:10 pierred Exp $
+ * $Revision: 1.15.2.2 $
+ * $Date: 2000/12/22 14:19:10 $
*
*
*
@@ -198,6 +198,10 @@
public String getJspCompilerPath() {
// we don't compile, so this is meanlingless
return null;
+}
+
+public String getJavaEncoding() {
+ return "UTF-8";
}
public String getClassPath() {
1.11.2.1 +9 -3 jakarta-tomcat/src/share/org/apache/jasper/Options.java
Index: Options.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- Options.java 2000/05/26 18:55:10 1.11
+++ Options.java 2000/12/22 14:19:11
Re: Tomcat session replicator
On Thu, 21 Dec 2000 [EMAIL PROTECTED] wrote: Two weeks ago I posted note here saying I'm going to write patch for Tomcat 3.2 to support redundancy, in manner of having session information stored between reloads and shared between tomcat instances. In order to support tomcat redundancy I thought on implementing that in two phases: 1. Stand-alone connector. This will require another listener. 2. Incorporate it into Ajp13. 3. Incorporate it into Ajp13 and calling it Ajp14. My preference would be wither 2 or 3. I think we should be able to add new message types to Ajp13 - that's needed to support the autoconfiguration anyway, and will be needed in future. If that's not possible - we should add what's needed and make it 14. ( AFAIK it should be - I remember this was a thing Gal had in mind when he wrote the code ) Costin why not do iot in shared storage and implement SSI ? thats what the mod_jserv shm file was for...a shared hunk of disk store. -Ys- [EMAIL PROTECTED]
Catalina: HttpProcessor and HttpConnector synchronize on ?
Hi, I noticed something peculiar while browsing through the sources of Tomcat/Catalina. Both HttpProcessor and HttpConnector use a private String object to synchronize their threads on: private String threadSync = ""; The JLS requires that all static String be 'intern'ed so they all refer to the same String Object. See the Java Language Spec. 3.10.5 (http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html) This means that all HttpProcessors and HttpConnectors use the same object to synchronize on! Unless this is intentional (which I doubt) it suggest both be replaced by private Object threadSync = new Object(); Luc Vanlerberghe Index: HttpConnector.java === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpConnector.java,v retrieving revision 1.5 diff -u -r1.5 HttpConnector.java --- HttpConnector.java 2000/12/16 19:01:23 1.5 +++ HttpConnector.java 2000/12/22 15:42:37 @@ -253,7 +253,7 @@ /** * The thread synchronization object. */ -private String threadSync = ""; +private Object threadSync = new Object(); /** Index: HttpProcessor.java === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v retrieving revision 1.18 diff -u -r1.18 HttpProcessor.java --- HttpProcessor.java 2000/12/17 01:05:40 1.18 +++ HttpProcessor.java 2000/12/22 15:42:38 @@ -242,7 +242,7 @@ /** * The thread synchronization object. */ -private String threadSync = ""; +private Object threadSync = new Object(); /**
RE: Commiters WHO and WHERE
My plan: TOMCAT 3.2: Start using it :-) TOMCAT 3.3: As I said: - merge all changes/bug-fixes from 3.2 ( that are not merged by their authors ) - finish the core refactoring, try to get as much feedback as possible ( estimate - 1 month ) - build milestones, build beta, build release-proposal, ask for a vote - based on the vote result, build the final 3.3 - continue to maintain 3.3 ( or the CVS head ) After 3.3: start rewriting and replacing modules, start adding features, start implementing Servlet2.3 - all that in an independent project/repository. TOMCAT 4.0: Help Dan with mod_jk/mod_webapp integration, make sure the result works in both 4.0 and 3.3 ( I'll only work on the C side ) Enhance performance of the various components that I reuse in 3.3, try to get the changes back into 4.0 Costin
BugRat Report #654 has been filed.
Bug report #654 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/654 REPORT #654 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: any Operating System: solaris OS Release: 2.8 Platform: sparc Synopsis: C++ style comments in mod_jserv autochange.c break compile Description: The C++ comments (//) in src/native/apache/jserv/autochange.c C files cause errors with SparcCompiler. SparcCompiler is invoked when using apxs to rebuild mod_jserv.so. This may be related to bug 397. Title: BugRat Report # 654 BugRat Report # 654 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Dec 22 2000, 10:36:26 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: C++ style comments in mod_jserv autochange.c break compile Environment: (jvm, os, osrel, platform) any, solaris, 2.8, sparc Additional Environment Description: Report Description: The C++ comments (//) in src/native/apache/jserv/autochange.c C files cause errors with SparcCompiler. SparcCompiler is invoked when using apxs to rebuild mod_jserv.so. This may be related to bug 397. How To Reproduce: null Workaround: null View this report online...
BugRat Report #655 has been filed.
Bug report #655 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/655
REPORT #655 Details.
Project: Jasper
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment:
Release: Tomcat-4.0-m5
JVM Release: 1.3
Operating System: NT
OS Release: 4.0
Platform: x86
Synopsis:
Compiler error concerning jsp:include tag
Description:
Possible error in IncludeGenerator.java, line 156:
writer.println("String [] _tmpS = new String[" + value.length +"];");
Writes same string to generated code possibly multiple times.
Problem is can't declare same variable more than once in a Java code block - compiler
complains.
Also note this line appears to be useless since _tmpS is never used. (Possible
leftover from previous version :)
Example code that produces error situation:
jsp:include page="/servlet/usingjsp.TableServlet" flush="true"
jsp:param name="data" value="people"/
jsp:param name="tableOptions" value="BORDER=4"/
jsp:param name="column" value="name"/
jsp:param name="columnType" value="data"/
jsp:param name="columnHeader" value="Name"/
jsp:param name="column" value="age"/
jsp:param name="columnType" value="data"/
jsp:param name="columnHeader" value="Age"/
jsp:param name="column" value="getPhoneNumber"/
jsp:param name="columnType" value="data"/
jsp:param name="columnHeader" value="Phone #"/
/jsp:include
Produces following code from jsp compiler:
String _jspx_qStr = "";
String [] _tmpS = new String[3];
_jspx_qStr = _jspx_qStr + "?columnType=" + "data";
_jspx_qStr = _jspx_qStr + "columnType=" + "data";
_jspx_qStr = _jspx_qStr + "columnType=" + "data";
_jspx_qStr = _jspx_qStr + "tableOptions=" + "BORDER=4";
_jspx_qStr = _jspx_qStr + "data=" + "people";
String [] _tmpS = new String[3];
_jspx_qStr = _jspx_qStr + "columnHeader=" + "Name";
_jspx_qStr = _jspx_qStr + "columnHeader=" + "Age";
_jspx_qStr = _jspx_qStr + "columnHeader=" + "Phone #";
String [] _tmpS = new String[3];
_jspx_qStr = _jspx_qStr + "column=" + "name";
_jspx_qStr = _jspx_qStr + "column=" + "age";
_jspx_qStr = _jspx_qStr + "column=" + "getPhoneNumber";
pageContext.include("/servlet/usingjsp.TableServlet" + _jspx_qStr);
Note the 3 ocurrences of String [] _tmpS = new String[3]; in the above code.
Compiler Complaint:
Error: 500
Location: /examples/jspbook/Chap07/ShowTable.jsp
Internal Servlet Error:
org.apache.jasper.JasperException: Unable to compile class for
JSPC:\jakarta-tomcat-3.2.1\work\localhost_8080%2Fexamples\_0002fjspbook_0002fChap_00030_00037_0002fShowTable_0002ejspShowTable_jsp_0.java:115:
Variable '_tmpS' is already defined in this method.
String [] _tmpS = new String[3];
^
C:\jakarta-tomcat-3.2.1\work\localhost_8080%2Fexamples\_0002fjspbook_0002fChap_00030_00037_0002fShowTable_0002ejspShowTable_jsp_0.java:119:
Variable '_tmpS' is already defined in this method.
String [] _tmpS = new String[3];
^
2 errors
Title:
BugRat Report #
655
BugRat Report #
655
Project:
Jasper
Release:
Tomcat-4.0-m5
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
medium
Severity:
serious
Confidence:
public
Submitter:
Paul Fernandes ([EMAIL PROTECTED])
Date Submitted:
Dec 22 2000, 10:37:35 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
Compiler error concerning jsp:include tag
Environment: (jvm, os, osrel, platform)
1.3, NT, 4.0, x86
Additional Environment Description:
Report Description:
Possible error in IncludeGenerator.java, line 156:
writer.println("String [] _tmpS = new String[" + value.length +"];");
Writes same string to generated code possibly multiple times.
Problem is can't declare same variable more than once in a Java code block - compiler complains.
Also note this line appears to be useless since _tmpS is never used. (Possible leftover from previous version :)
Example code that produces error situation:
Produces following code from jsp compiler:
String _jspx_qStr = "";
String [] _tmpS = new String[3];
_jspx_qStr = _jspx_qStr + "?columnType=" + "data";
_jspx_qStr = _jspx_qStr + "=" + "data";
_jspx_qStr = _jspx_qStr + "=" + "data";
_jspx_qStr = _jspx_qStr + "=" + "BORDER=4";
_jspx_qStr = _jspx_qStr + "=" + "people";
String [] _tmpS = new String[3];
_jspx_qStr = _jspx_qStr + "=" + "Name";
_jspx_qStr = _jspx_qStr + "=" + "Age";
_jspx_qStr = _jspx_qStr + "=" + "Phone #";
String [] _tmpS = new String[3];
_jspx_qStr = _jspx_qStr + "=" + "name";
_jspx_qStr = _jspx_qStr + "=" + "age";
_jspx_qStr = _jspx_qStr + "=" + "getPhoneNumber";
pageContext.include("/servlet/usingjsp.TableServlet" + _jspx_qStr);
Note the 3 ocurrences of String [] _tmpS = new String[3]; in the
Re: Commiters WHO and WHERE
on 12/22/2000 3:27 AM, "GOMEZ Henri" [EMAIL PROTECTED] wrote: There is still now, 3 projects (Sorry jon ;-) : I'm not the only person who disagrees with having 3 versions of Tomcat that we have to support, maintain and develop so please don't put it on only me. -jon
Re: back port to 3.2 -- JspInterceptor
[EMAIL PROTECTED] wrote: BTW, did you fixed the command line compiler ? JspInterceptor is based on the command line compiler, so if you fix the first it'll be very easy for me to fix the 3.3 interceptor. Sorry, my radar must have missed this one. If you can give me pointers/info, I'll look into it. JspC ? It's a great tool - and BTW, in 3.2 it can drastically increase the performance of jsp pages ( if you precompile _and_ use the option to automatically declare the jsps in web.xml )- it's almost as fast as 3.3 with JspInterceptor ( which does the same thing at run time). ( it's not about the first compilation, but JspC and JspInterceptor are removing the *.jsp - JspServlet - actual page servlet overhead ) Costin, Sorry, I was confused. I thought you meant that the command line compiler was broken and needed a fix. A fix was made to JspC to accomodate the proper handling of "javaEncoding". Is that what you were asking? -- Pierre
Re: mod_webapp / mod_jk
Another point of mod_jk is for Dan and about the question of security and or ligth crypto support. ajp12/ajp13 didn't support ACL to accept/deny connections from a list of known host, and the protocol is in clear text. Costin suggest using SSH tunnels which be a fast work-around but I really like to have this ACL+CRYPTO included in mod_jk/ajp13. I agree that some form of authentication (and possibly encryption) are high-priority things to add to mod_jk / ajp13. Before I dive into that work, though, I want to be sure that there is a future for the code -- that's why I'm proposing using it in TC 4 as well as TC 3. In some previous discussions about extending ajp13, there had been hope that it could be done fairly easily, since there are typed packets, so new packet types could be added without breaking the protocol. Unfortunately, I don't think that's going to work -- the current code does read packet types, but if it sees an unknown packet type, it closes the connection down. This makes it impossible to send packets in an exploratory manner. Fortunately, the ACL's should be implementable without touching the packet types (I think you suggested this, Henri). We can just add a list of safe hosts to the configuration directives for TC, and it will only allow connections if they come from the specified hosts. I think this would still leave us open to IP address spoofing, but it would certainly be an improvement over what we've got now. For encryption, we would have to introduce new packet types. Personally, my feeling is that encryption of the stream between the Web Server and TC is much less important than authenticating connections. Especially given that SSH tunnels are not that hard to set up, I am reluctant to add the complexity of crypto code to ajp13. Finally, going ahead. I think it would be a good idea to introduce ajp14 (once the bulk of the work above has been completed). I would propose it as a slight variant on ajp13. Basically, the same protocol, with a few new packet types (we need something to handle 8K of header information), *and* with provision for handling unknown packet types more intelligently. I think this would give us a protocol which we could live with more easily over time. We could add new features, but it could still communicate with old web server plugin versions. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session replicator)
+1 Nacho wrote: Shai has contributed great bug fixes ( one specially difficult in 3.2, thanks Shai ) and he wants to contribute a distributed session manager It has been proposed as committer by Craig in a informal way, now it's proposed in a formal way :-) it has my +1 as well +1 from Craig in the message below. Votes , please. -- Dan Milstein // [EMAIL PROTECTED]
Re: Tomcat session replicator
"[EMAIL PROTECTED]" wrote: why not do iot in shared storage and implement SSI ? thats what the mod_jserv shm file was for...a shared hunk of disk store. -Ys- [EMAIL PROTECTED] This is certainly one valid approach. It works for cases where the servers are all on the same machine. But you still need an approach that works on a multiple machine environment as well. It would be worth someone taking the time to articulate proposed use cases, from which we can identify desired features. My bet is that we will end up wanting a variety of pluggable implementations with different functionality and performance characteristics. Craig
RE: mod_webapp / mod_jk
I agree that some form of authentication (and possibly encryption) are high-priority things to add to mod_jk / ajp13. Before I dive into that work, though, I want to be sure that there is a future for the code -- that's why I'm proposing using it in TC 4 as well as TC 3. Fortunately, the ACL's should be implementable without touching the packet types (I think you suggested this, Henri). We can just add a list of safe hosts to the configuration directives for TC, and it will only allow connections if they come from the specified hosts. I think this would still leave us open to IP address spoofing, but it would certainly be an improvement over what we've got now. Yes something before the packet decoding. Like the host.allow/host.deny found on Linux Boxes. For encryption, we would have to introduce new packet types. Personally, my feeling is that encryption of the stream between the Web Server and TC is much less important than authenticating connections. Especially given that SSH tunnels are not that hard to set up, I am reluctant to add the complexity of crypto code to ajp13. May be we could find a not so hog crypto code. Finally, going ahead. I think it would be a good idea to introduce ajp14 (once the bulk of the work above has been completed). I would propose it as a slight variant on ajp13. Basically, the same protocol, with a few new packet types (we need something to handle 8K of header information), *and* with provision for handling unknown packet types more intelligently. I think this would give us a protocol which we could live with more easily over time. We could add new features, but it could still communicate with old web server plugin versions. +1 Only keep ajp13 for backward compatibily ?
Re: Jasper Architecture Question (Was: How to do my own JSP processing)
See intermixed. Christian Mallwitz wrote: -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 19:23 To: [EMAIL PROTECTED] Subject: Re: How to do my own JSP processing Sounds like you are planning on inventing your own variant of a servlet+JSP server, since you're wanting to change or ignore many of the spec requirements. And you will end up with an app that will only run in your own server. Unless you like building servers as a hobby, you've got a *lot* of hard work ahead of you. I would suggest you look at how you can architect your application *within* the requirements of the servlet and JSP specs. That way, you can focus on writing an app rather than a server, and have some assurance that you can run that app elsewhere if and when you outgrow Tomcat. Actually I have my own template language which is compiled to a JSP file. Everything is supposed to be as much Servlet 2.3 spec conformant as possible. Here is a simplistic view on my main servlet service() 1. begin database transaction 2. do some business logic 3. execute JSP file 4. commit transaction 5a. if commit successful send response content to the network 5b. if not generate error response (and discard result of JSP) The problems with 3.) are I.) the JSP files are located outside my servlet context That one is a non-spec-compliant requirement -- all resources are supposed to be addressable *within* a context. Depending on your OS and servlet container, you might be able to "cheat" and simulate this with a symbolic link or something. II.) JSP execution must be buffered because the content is not be sent before the database transaction commits You can do that already, by just setting the page buffer size big enough -- but see below for an alternative approach. III.) the JSP execution must be able to set response header lines (e.g. cookie) That's fine, as long as the response has been buffered and not committed yet. IV.) it should be possible in JSPs to use tag libraries and do all other things possible if the JSP is served directly by Tomcat So you are essentially writing JSP source on the fly, and then wanting the servlet container to execute them? Sounds like an overly complicated design to me, but I presume you've determined that the extra layer is worth it. Because of I.) I cant use a "simple" servlet request dispatcher II.) forward() won't work because if the forward() returns the response is already committed and closed by the container III.) includes() won't do because I can't set headers On top of this I want my servlet to pick a JSP file, run it, capture the output and send this output be email before saying "sending email was successful." over HTTP. From what I read about Jasper it should be possible to call it compile my JSPs and trigger their execution independent of the all of this is running in a servlet itself or a standalone application, right? There isn't really such a thing as running the compiled JSP page in a stand-alone application. The generated code relies on being run inside a servlet context (i.e. for application-scope beans and such). In Tomcat's case, the stand-alone compiler (jspc) generates compiled servlets and a bunch of stuff that needs to be added to the web.xml file -- not a dynamic process, as you are describing. You might also want to look at an alternative architecture for organizing your app. There are several frameworks available (such as Struts and Turbine within the Apache realm) that use a model-view-controller (MVC) design pattern. For example, to deal with the buffering problem, you would do something like this: * Submit a request to the controller servlet * Controller servlet dispatches to business logic that processes that particular type of request * Business logic initiates the transaction, performs the required changes, and attempts to commit * Based on the results, forward to a "success" page or a "failure" page. Note that the buffering issue goes away -- you will never have tried to execute the "success" page unless the transaction succeeded. Also, you will be separating the business logic and presentation logic portions of your app, which will make it easier to maintain and enhance in the future. Just a thought. Thanks Christian PS: I know it will be a nice piece of work ... -- Christian Mallwitz INTERSHOP Communications Germany Senior Software Engineerphone: +49 3641 50 3453 Craig
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java ParserController.java
pierred 00/12/22 10:37:40
Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java ParserController.java
Log:
Fix for Bug #55.
-
Synopsis:
Default for included files is 8859_1, with no option to set otherwise.
Report Description:
The default for reading an included file is ISO_8859_1. We can,
of course, set pageConent to read UTF-8 (which is what we need it
to be to support international
code). Unfortunately, when there are two or more levels of
encoding (or the pageContent type ins't set), the encoding that
the JspReader gets set to a hard-coded
"ISO_8859_1", and doesn't allow this to be set to anything else
via the runtime system properties. In:
org.apache.jasper.compiler.JspReader JspReader.java line
158, encoding ALWAYS defaults to 8859_1, and the file.encoding,
when set from the System properties. This is an easy fix, to set
encoding to: encoding =
System.getPropert("file.encoding","8859_1") ; The result,
typically, is that the file will flake out and convert all of the
non-UTF-8 characters to US-ASCII, @%, etc.
-
I'm not sure I fully understand what's described there,
so here is what I believe should be done.
The "encoding" for a JSP file is currently handled as follows:
1. In Compiler.java, we create a JspReader for the top-level
("including") jsp file using the 8859_1 encoding.
2. Using that JspReader, we check if there is a page directive
with 'contentType' specified. If there is, then
a new JspReader for the page is created with the encoding set to the
"charset" specified in the contentType value of the page
directive; otherwise we stick with the default 8859_1 encoding.
3. When a page is included, JspReader.pushFile() is called,
and the encoding passed as argument appears to always
be null (since no encoding attribute can be specified in
the "include" directive, reading 'encoding' off of the
attributes appears to be a bug in JspParseEventListener).
Because it is null, it always defaults to 8859_1.
If I understand well the intent of the bug report, we'd need the
following modifications:
- In step 2, if contentType is not specified in the "including" page,
set the encoding to be:
encoding = System.getProperty("file.encoding", "8859_1");
This means that the default encoding of all JSP files at a site could
be defined globally using system property "file.encoding".
I don't think this is spec-compliant, and would be reluctant
to make that change.
-- Change not done
Comments from Hans Bergsten
"I agree that using "file.encoding" as the ultimate default is not
spec compliant. I suggest you stick to the current behavior, with
"8859_1" if contentType doesn't specify a charset."
- In step 3, use the encoding of the "including" page.
This would fix what I believe is a bug in the current implementation.
-- Change done
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.20 +4 -6
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- JspParseEventListener.java2000/12/21 23:16:41 1.19
+++ JspParseEventListener.java2000/12/22 18:37:39 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.19 2000/12/21 23:16:41 pierred Exp $
- * $Revision: 1.19 $
- * $Date: 2000/12/21 23:16:41 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.20 2000/12/22 18:37:39 pierred Exp $
+ * $Revision: 1.20 $
+ * $Date: 2000/12/22 18:37:39 $
*
*
*
@@ -750,8 +750,6 @@
if (directive.equals("include")) {
String file = attrs.getValue("file");
- String encoding = attrs.getValue("encoding");
-
if (file == null)
throw new CompileException(start,
Constants.getString("jsp.error.include.missing.file"));
@@ -766,7 +764,7 @@
}
*/
try {
- parserCtl.parse(file, encoding);
+ parserCtl.parse(file);
} catch (FileNotFoundException ex) {
throw new CompileException(
start,
1.9
FW: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/utilSessionIdGenerator.java
Just think. Instead of having to watch the commit messages and backport
everything that keeps getting fixed in 4.0, you could have been working on
fixing bugs in 4.0 or developing features for 4.0.
Geee..what a concept!
-jon
--
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 22 Dec 2000 17:35:06 -
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util
SessionIdGenerator.java
marcsaeg00/12/22 09:35:06
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
SessionIdGenerator.java
Log:
The PRNG is now initialized with a seed value to prevent the multi-second
delay seen on many platforms.
This code is based on Craig's changes to Catalina that address the same
issue there.
Revision ChangesPath
No revision
No revision
1.3.2.3 +51 -7
jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator.java
Index: SessionIdGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator
.java,v
retrieving revision 1.3.2.2
retrieving revision 1.3.2.3
diff -u -r1.3.2.2 -r1.3.2.3
--- SessionIdGenerator.java 2000/11/18 01:33:59 1.3.2.2
+++ SessionIdGenerator.java 2000/12/22 17:35:05 1.3.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator
.java,v 1.3.2.2 2000/11/18 01:33:59 craigmcc Exp $
- * $Revision: 1.3.2.2 $
- * $Date: 2000/11/18 01:33:59 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator
.java,v 1.3.2.3 2000/12/22 17:35:05 marcsaeg Exp $
+ * $Revision: 1.3.2.3 $
+ * $Date: 2000/12/22 17:35:05 $
*
*
*
@@ -114,7 +114,41 @@
*/
public final static long ticDifference = 2000;
-// ** NOTE that this must work together with
get_jserv_session_balance()
+/**
+ * A String initialization parameter used to increase the entropy of
+ * the initialization of our random number generator.
+ */
+private static String entropy = null;
+
+
+/**
+ * Return the entropy increaser value, or compute a semi-useful value
+ * if this String has not yet been set.
+ */
+public static String getEntropy() {
+
+ // Calculate a semi-useful value if this has not been set
+ if (entropy == null)
+ setEntropy((new Object()).toString());
+
+ return (entropy);
+
+}
+
+
+/**
+ * Set the entropy increaser value.
+ *
+ * @param entropy The new entropy increaser value
+ */
+public static void setEntropy(String newEntropy) {
+
+ entropy = newEntropy;
+
+}
+
+
+ // ** NOTE that this must work together with
get_jserv_session_balance()
// ** in jserv_balance.c
static synchronized public String getIdentifier (String jsIdent)
{
@@ -133,10 +167,20 @@
}
if (randomSource == null)
randomSource = new java.security.SecureRandom();
-}
+
+// Set the seed PRNG's seed value
+long seed = System.currentTimeMillis();
+char entropy[] = getEntropy().toCharArray();
+for (int i = 0; i entropy.length; i++) {
+ long update = ((byte) entropy[i]) ((i % 8) * 8);
+ seed ^= update;
+}
+randomSource.setSeed(seed);
+}
+
-// random value ..
-long n = randomSource.nextLong();
+// random value ..
+long n = randomSource.nextLong();
if (n 0) n = -n;
n %= maxRandomLen;
// add maxLen to pad the leading characters with '0'; remove
BugRat Report #269 was closed (apparently by: Pierre Delisle)
Report #269 was closed by Person #0 Synopsis: java.io.UnsupportedEncodingException when processing JSP (logged in as: Pierre Delisle)
BugRat Bug #55 was closed (apparently by: Pierre Delisle)
Bug #55 was closed by Person #0 Synopsis: Default for included files is 8859_1, with no option to set otherwise. (logged in as: Pierre Delisle)
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/utilSessionIdGenerator.java
Actually, no. My product embeds TC3.2.x. When TC4.0 is ready I'll probably
switch to that, but it will take time and I'll still have to support an
existing customer base with the TC3.2.x version installed. That's just a
fact of life and business.
For this reason it is important to me that bugs in 3.2.x get fixed and that
this version remains stable and robust. That's why I became a committer. I
would really like to join in the development of 4.0 but I simply don't have
enough time right now. I wish I did because I think it would be a blast.
Maybe in a few months...
I have *NO* intention, desire, or time to enhance 3.2.x beyond fixing bugs.
Stop. Read the previous sentence again. Repeat until it sinks in.
I could have used the anon-CVS server and made all my bug fixes privately.
I chose not to.
I could have posted bug fixes to tomcat-dev hoping that one of the
committers would take time away from 4.0 development to commit them for me.
I chose not to.
I decided to take the more active approach to help keep the 3.2.x version in
good shape both for myself and for all the others who, for very valid
business reasons, still need to use it. I would think that committers
currently working on 4.0 would appreciate this as it reduces the time they
need to spending supporting the currently released version.
I have no intention of joining the 3.x vs. 4.x flame war.
Finally, the problem this commit addressed, the long PRNG initialization, is
a problem that I've been meaning to fix for a while. I just happened to
like Craig's fix better than the one I proposed several weeks ago so I went
ahead and committed it now.
-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 22, 2000 12:10 PM
To: tomcat-dev
Subject: FW: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/utilSessionIdGenerator.java
Just think. Instead of having to watch the commit messages and backport
everything that keeps getting fixed in 4.0, you could have been working on
fixing bugs in 4.0 or developing features for 4.0.
Geee..what a concept!
-jon
--
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 22 Dec 2000 17:35:06 -
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util
SessionIdGenerator.java
marcsaeg00/12/22 09:35:06
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
SessionIdGenerator.java
Log:
The PRNG is now initialized with a seed value to prevent the multi-second
delay seen on many platforms.
This code is based on Craig's changes to Catalina that address the same
issue there.
Revision ChangesPath
No revision
No revision
1.3.2.3 +51 -7
jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator.java
Index: SessionIdGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator
.java,v
retrieving revision 1.3.2.2
retrieving revision 1.3.2.3
diff -u -r1.3.2.2 -r1.3.2.3
--- SessionIdGenerator.java 2000/11/18 01:33:59 1.3.2.2
+++ SessionIdGenerator.java 2000/12/22 17:35:05 1.3.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator
.java,v 1.3.2.2 2000/11/18 01:33:59 craigmcc Exp $
- * $Revision: 1.3.2.2 $
- * $Date: 2000/11/18 01:33:59 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator
.java,v 1.3.2.3 2000/12/22 17:35:05 marcsaeg Exp $
+ * $Revision: 1.3.2.3 $
+ * $Date: 2000/12/22 17:35:05 $
*
*
*
@@ -114,7 +114,41 @@
*/
public final static long ticDifference = 2000;
-// ** NOTE that this must work together with
get_jserv_session_balance()
+/**
+ * A String initialization parameter used to increase the entropy of
+ * the initialization of our random number generator.
+ */
+private static String entropy = null;
+
+
+/**
+ * Return the entropy increaser value, or compute a semi-useful value
+ * if this String has not yet been set.
+ */
+public static String getEntropy() {
+
+ // Calculate a semi-useful value if this has not been set
+ if (entropy == null)
+ setEntropy((new Object()).toString());
+
+ return (entropy);
+
+}
+
+
+/**
+ * Set the entropy increaser value.
+ *
+ * @param entropy The new entropy increaser value
+ */
+public static void setEntropy(String newEntropy) {
+
+ entropy = newEntropy;
+
+}
+
+
+ // ** NOTE that this must work together with
get_jserv_session_balance()
// ** in jserv_balance.c
static synchronized public String getIdentifier (String jsIdent)
{
@@ -133,10 +167,20 @@
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JspParseEventListener.java JspReader.java
pierred 00/12/22 11:33:08
Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
JspParseEventListener.java JspReader.java
Log:
Fix for Bug #55. (tomcat_32)
-
Synopsis:
Default for included files is 8859_1, with no option to set otherwise.
Report Description:
The default for reading an included file is ISO_8859_1. We can,
of course, set pageConent to read UTF-8 (which is what we need it
to be to support international
code). Unfortunately, when there are two or more levels of
encoding (or the pageContent type ins't set), the encoding that
the JspReader gets set to a hard-coded
"ISO_8859_1", and doesn't allow this to be set to anything else
via the runtime system properties. In:
org.apache.jasper.compiler.JspReader JspReader.java line
158, encoding ALWAYS defaults to 8859_1, and the file.encoding,
when set from the System properties. This is an easy fix, to set
encoding to: encoding =
System.getPropert("file.encoding","8859_1") ; The result,
typically, is that the file will flake out and convert all of the
non-UTF-8 characters to US-ASCII, @%, etc.
-
I'm not sure I fully understand what's described there,
so here is what I believe should be done.
The "encoding" for a JSP file is currently handled as follows:
1. In Compiler.java, we create a JspReader for the top-level
("including") jsp file using the 8859_1 encoding.
2. Using that JspReader, we check if there is a page directive
with 'contentType' specified. If there is, then
a new JspReader for the page is created with the encoding set to the
"charset" specified in the contentType value of the page
directive; otherwise we stick with the default 8859_1 encoding.
3. When a page is included, JspReader.pushFile() is called,
and the encoding passed as argument appears to always
be null (since no encoding attribute can be specified in
the "include" directive, reading 'encoding' off of the
attributes appears to be a bug in JspParseEventListener).
Because it is null, it always defaults to 8859_1.
If I understand well the intent of the bug report, we'd need the
following modifications:
- In step 2, if contentType is not specified in the "including" page,
set the encoding to be:
encoding = System.getProperty("file.encoding", "8859_1");
This means that the default encoding of all JSP files at a site could
be defined globally using system property "file.encoding".
I don't think this is spec-compliant, and would be reluctant
to make that change.
-- Change not done
Comments from Hans Bergsten
"I agree that using "file.encoding" as the ultimate default is not
spec compliant. I suggest you stick to the current behavior, with
"8859_1" if contentType doesn't specify a charset."
- In step 3, use the encoding of the "including" page.
This would fix what I believe is a bug in the current implementation.
-- Change done
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.17.2.3 +4 -6
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.17.2.2
retrieving revision 1.17.2.3
diff -u -r1.17.2.2 -r1.17.2.3
--- JspParseEventListener.java2000/12/21 23:25:27 1.17.2.2
+++ JspParseEventListener.java2000/12/22 19:33:08 1.17.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.17.2.2 2000/12/21 23:25:27 pierred Exp $
- * $Revision: 1.17.2.2 $
- * $Date: 2000/12/21 23:25:27 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.17.2.3 2000/12/22 19:33:08 pierred Exp $
+ * $Revision: 1.17.2.3 $
+ * $Date: 2000/12/22 19:33:08 $
*
*
*
@@ -717,15 +717,13 @@
if (directive.equals("include")) {
String file = (String) attrs.get("file");
- String encoding = (String) attrs.get("encoding");
-
if (file == null)
throw new CompileException(start,
Constants.getString("jsp.error.include.missing.file"));
// jsp.error.include.bad.file needs taking care of here??
try {
-
Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)
Just so you know, these recent changes to correct the paths has screwed up Turbine. :-) I was depending on a path to have a ./ in it and now that is removed and therefore, Turbine is broken because the paths don't get generated properly. I'm not complaining because I should probably fix it in Turbine as well (and will do so ASAP), but I'm just letting you know that these recent changes do in fact affect other applications. :-) -jon
BugRat Report #657 has been filed.
Bug report #657 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/657 REPORT #657 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: low Severity: non-critical Confidence: public Environment: Release: Tomcat 3.2+ JVM Release: Sun/HotSpot/1.3.0 Operating System: Windows NT 4.0 OS Release: 4.0 SP6a Platform: Windows Synopsis: Tomcat's webserver doesn't create URLs properly for oddly named files. Description: While Tomcat's JSP engine handles oddly named files very well, the builtin webserver does a poor job of creating properly formatted URLs for those files. For example, a JSP with filename "odd file name.jsp" should be accessed by the relative URL "/path/odd%20file%20name.jsp". Unfortunately, when the webserver's directory indexer generates relative URLs like this, "/path/odd file name.jsp", so that when the user follows this link, a 404 error page is returned: Not found (404) Original request: /path/odd Not found request: /paths/odd Also, if it's an oddly named resource (html file), then the webserver can't handle the correct URL, either. (For example, for "odd file.html", the directory indexer will generate a link like "/path/odd file.html", which doesn't work, so I type "http://server/path/odd%20file.html" into the location, and I get a 404: Not found (404) Original request: /path/odd%20file.html Not found request: /path/odd%20file.html Clearly, the webserver included in tomcat is not a production webserver, and tomcat is meant to be installed into another webserver, but it is a bug none-the-less. The indexer could probobly be fixed rather easily to generate proper directory indices, and there's a good chance that the resource finder could be patched to handle %-escaped URLs proplerly relatively easily, too. Title: BugRat Report # 657 BugRat Report # 657 Project: Tomcat Release: Tomcat 3.2+ Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: low Severity: non-critical Confidence: public Submitter: Michael R Head ([EMAIL PROTECTED]) Date Submitted: Dec 22 2000, 01:51:40 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Tomcat's webserver doesn't create URLs properly for oddly named files. Environment: (jvm, os, osrel, platform) Sun/HotSpot/1.3.0, Windows NT 4.0, 4.0 SP6a, Windows Additional Environment Description: I've tested this in tomcat 3.2.1 and 3.2 final, both under Sun's JDK's JVM 1.3.0 (hotspot enabled) on a windows NT4.0 machine. This occurs when run as an NT service (via jk_nt_service.exe) and when run using startup.bat. Report Description: While Tomcat's JSP engine handles oddly named files very well, the builtin webserver does a poor job of creating properly formatted URLs for those files. For example, a JSP with filename "odd file name.jsp" should be accessed by the relative URL "/path/odd%20file%20name.jsp". Unfortunately, when the webserver's directory indexer generates relative URLs like this, "/path/odd file name.jsp", so that when the user follows this link, a 404 error page is returned: Not found (404) Original request: /path/odd Not found request: /paths/odd Also, if it's an oddly named resource (html file), then the webserver can't handle the correct URL, either. (For example, for "odd file.html", the directory indexer will generate a link like "/path/odd file.html", which doesn't work, so I type "http://server/path/odd%20file.html" into the location, and I get a 404: Not found (404) Original request: /path/odd%20file.html Not found request: /path/odd%20file.html Clearly, the webserver included in tomcat is not a production webserver, and tomcat is meant to be installed into another webserver, but it is a bug none-the-less. The indexer could probobly be fixed rather easily to generate proper directory indices, and there's a good chance that the resource finder could be patched to handle %-escaped URLs proplerly relatively easily, too. How To Reproduce: null Workaround: null View this report online...
Re: [tomcat-4.0] Session Creation Slowness
I have confirmed that: The latest nightly build fixes this problem and Turbine/Catalina now starts up and initializes and returns a request in about 3-4 seconds on my machine...more than acceptable now. :-) thanks craig for tracking it down. this is going to save months of development time. :-) -jon
Re: Tomcat session replicator
Craig R. McClanahan wrote: "[EMAIL PROTECTED]" wrote: why not do iot in shared storage and implement SSI ? thats what the mod_jserv shm file was for...a shared hunk of disk store. -Ys- [EMAIL PROTECTED] This is certainly one valid approach. It works for cases where the servers are all on the same machine. But you still need an approach that works on a multiple machine environment as well. Yes! I want a system where you can have as many Tomcats as you want on each machine, and as many of those machines as you want, and they all act together as one big distributed farm of Tomcats. The administrator should be able to configure which Tomcat instance replicates to which other Tomcat instance(s). And, this should be transparent to users regardless of the web server being used. Unless I'm missing something, I don't see why we should change the C-side of the AJP code to make all this work.. It would be worth someone taking the time to articulate proposed use cases, from which we can identify desired features. Yes, and I'll see what I can do.. My bet is that we will end up wanting a variety of pluggable implementations with different functionality and performance characteristics. I sure do. Some features I'd like to add to Tomcat 4 (and use!): * Add the functionality to Catalina to operate as a distributed Servlet container as described in the latest Servlet specification in stand-alone operation. This should support pluggable communication mechanisms (plug in the protocol of your choice at runtime via a custom config), including RMI and IP-Multicast technologies like Weblogic uses. * Add a load balancing and fault tolerance Valve to Catalina that makes the web server act as a load balancing HTTP redirect server. The goal is to make it easy to install, run, and maintain a cluster of Tomcat "web containers". This Valve should later be able to take advantage of Avalon if Catalina is running within Avalon, and if not it should still work in standalone mode. More detail: This Valve makes the web server serve HTTP redirects (HTTP 302 - Moved Temporarily) when the request should be moved to another Tomcat instance. It acts in concert with one or more other Tomcat instances in a completely decentralized way. For instance, no single machine acts as the central brain for the system.. each redirect server tries to cooperate with any other redirect servers in the system, but each one has authority over its own requests should it not be able to communicate with other redirect servers in the system. These redirect servers keep track of how many content servers there are in the system, and distribute HTTP requests to each of the content servers in a manner dependent on the load balancing module. The load balancing module should be able to use many different load balancing algorithms. The system administrator should be able to configure which algorithm(s) to use for any given context. Load balancing algorithms may include: - Least Loaded Server: load can be calculated in one of many ways, including counting requests per unit of time, asking the operating system for the load average, current number of request Threads running, etc. - Weighted Percentage: larger, more powerful servers in the cluster are given a higher percentage of the requests that each redirect server must forward. Smaller, less capable servers will receive a smaller percentage of the requests/workload. - Fastest Path: a module at each data center will use ICMP pings to determine which data center has the fastest path back to the client. At that time, the fastest data center's own cluster of content servers are the only remaining candidates for forwarding and serving the request. Note that the pinger can't be written in the Java programming language (no support for ICMP -- a potential security issue for consumers), so that component needs to be written in another programming language. - Sticky Sessions: Any user's request will be sent to the same content server that the user's last request was sent to. Identification of a user is usually done in the form of cookies, or jsessionids. - Round Robin: perhaps the least intelligent algorithm, but the simplest to understand, set up, and try out. Redirect servers simply redirect requests one to each server in the list, looping back to the first server when the last server in the list is used. The load balancing module should allow pluggable load balancing algorithms to work in conjunction with each other. The administrator should be able to assign a decision making "weights" to each algorithm so that the decision about where to send a request can be made after considering more than just one algorithm's suggestion. Some algorithms, though, should never be used in combination with others (for example, Sticky Sessions.. what if you use it with
Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)
Jon Stevens wrote: fyi, the difference is that I had to add a "./" to the front of a parameter to a file that I was passing in... init-param param-nameproperties/param-name !-- This is relative to the docBase -- param-value ./WEB-INF/conf/TurbineResources.properties /param-value /init-param I didn't have to have that before. -jon Are you accessing the properties file via ServletContext.getResource() or ServletContext.getResourceAsStream()? If so, it should be accessed with a standard context-relative path like "/WEB-INF/conf/TurbineResources.properties". The path normalization code in Tomcat does this to your "./" anyway, so the "." should actually be redundant (unless you depend on it for some application specific reason). Craig
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler ParserXJspSaxHandler.java
pierred 00/12/22 12:34:56
Modified:jasper/src/share/org/apache/jasper/compiler
ParserXJspSaxHandler.java
Log:
Removed debug statement.
Revision ChangesPath
1.7 +1 -1
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserXJspSaxHandler.java
Index: ParserXJspSaxHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserXJspSaxHandler.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ParserXJspSaxHandler.java 2000/12/10 05:56:43 1.6
+++ ParserXJspSaxHandler.java 2000/12/22 20:34:56 1.7
@@ -378,7 +378,7 @@
} else {
// this is a custom tag
node.validate(true, false);
- System.out.println("node is: " + node);
+ //System.out.println("node is: " + node);
processCustomTagEnd((NodeTag)node, stop);
}
}
Re: Mud (Was: [OT] Holiday Reading - Refactoring)
Hi, about mud, here is a pattern called "Big ball of mud" by Brian Foote and Joseph Yoder. Read it! http://www.laputan.org/mud/ Regards Stein M. Eliassen System Developer - KPNQwest Norway AS - Business communications @ the speed of light.
Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)
on 12/22/2000 12:25 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Are you accessing the properties file via ServletContext.getResource() or ServletContext.getResourceAsStream()? Neither actually. We are using JServ's old code for loading properties so it is still direct file/io access. Yes, I know this breaks the idea of compressed WAR files, but for now we still require leaving them uncompressed anyway because of log files are stored in directories and such. /me thinks the idea of closed WAR files was lame anyway. If so, it should be accessed with a standard context-relative path like "/WEB-INF/conf/TurbineResources.properties". The path normalization code in Tomcat does this to your "./" anyway, so the "." should actually be redundant (unless you depend on it for some application specific reason). Right. Well, it was originally "WEB-INF/." and that worked fine before and now it doesn't. :-) thanks, -jon -- Honk if you love peace and quiet.
BugRat Report #655 was closed (apparently by: Pierre Delisle)
Report #655 was closed by Person #0 Synopsis: Compiler error concerning jsp:include tag (logged in as: Pierre Delisle)
Object Passivation in TC 3.2.x ?
Hi, I am creating a connection pool in my jsp pages. This connection pool is a context wide static class that is referenced by each jsp page through a static class method. If the website is inactive for about 2-3 hours, I get an error trying to get connections from the pool. I suspect that this is due to that class being serialized. This does not seem to happen in tomcat 3.1 though. The same site / connection pool class works fine !!! Is this my problem ? Is there any way to turn this off. Thanks Shahed.
RE: mod_webapp / mod_jk
I've builded the mod_webapp module and it fail when session are in use. May be related to cookies support. I could tell you more later after some capture with ethereal. Finally, someone actually trying it so we can fix the bugs :-) I'll try to fix whatever I can but we need a little more documentation on mod_webapp. I wonder if mod_webapp will support Load Balancing and Fault Tolerance. It's not clear in Directives. I've asked Pier to document what he has described to me informally as goals for the mod_webapp design, but this is definitely on the list of desireable things to support. Of course, getting the basic stuff working right first is important. Yep, but mod_jserv (and now mod_jk) ability to support fault/balancing was a big +1000 in my the decision using ApacheJServ 1.x and then to switch to Tomcat later. Did mod_webapp will support ACL/CRYPTO ? Even if crypto is not easily exportable even mod_ssl is such relaxed now that it could be used in Redhat Distributions (6.2/7.0) The code inside mod_webapp is layered, with precisely this type of use in mind. Nice to see that. I'll take more time to study mod_webapp. May be at some point it could reach Dan and Costin works on ajp13/14 evolutions. I'll try to make the ACL code for ajpxx portable to mod_webapp.
RE: Commiters WHO and WHERE
Since Costin and Dan will focus on mod_jk/ajpxx on 3.2/3.3 base, I'll focus on Apache 2.0 modules for mod_jk and mod_webapp. I'll try to release some RPM for httpd-2.0, apr, apr-utils and mod_jk, mod_webapp.
Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)
Thanks Craig, I'm in the middle of some tricky development with Cocoon at the moment and I don't wont to risk breaking my environment just at this instant. I hadn't consciously had a problem with this on Tomcat (only specifically within the internal ClassLoaders of Cocoon). I only mentioned it because the bug was one of these 'hard to pinpoint' ones that meant that some people's setups seemed to work and others didn't for no apparent reason. It stuck me that Tomcat was likely to be doing similar stuff, and it was worth looking for incase it was a problem for someone else. Hopefully some folk's setups will magically work now. I will update my CVS copy soon. Thanks again for following this up so quickly - I was worried this morning that I might have lead you on a wild goose chase! Festive greetings from Scotland, Stuart. On Friday, December 22, 2000, at 06:07 PM, Craig R. McClanahan wrote: Stuart Roebuck wrote: Craig, Here's one step towards what you were asking for. It's a standalone test case of the problem. I've written this because, judging from some of the issues that were occuring with Cocoon, I have a feeling that this problem is System/Java version dependent. The problem has been seen on Solaris, MacOS X and Windows with versions 1.2.2 and 1.3, but it may be only in certain combinations. Thanks for the test case. I've got equivalent behavior to yours (classloader 1 fails, classloader2 succeeds) on: * Linux, Sun JDK 1.2.2 and Sun JDK 1.3.0 * Win98, Sun JDK 1.2.2 and Sun JDK 1.3.0 If this test case reproduces the problem on your system, then were going in the right direction. If not, then we'll never produce a test case for you to be able to test. Yesterday, I committed the Tomcat 4.0 changes to use getCanonicalPath() instead of getAbsolutePath() in all the relevant cases. Looking at what we're seeing, I would bet you were certain to have problems (on the affected platforms) before if your CATALINA_HOME had "../" elements, or if the document root of a particular web app had them. Have you had a chance to try the updated code yet? The nightly build from last night is probably the easiest way. Craig - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Mac OS X, Java, XML, etc. ADOLOS http://www.adolos.com/
RE: BugRat Report #659 has been filed.
mod_jk was built on an EAPI apache but is run on a standard apache. Could be closed ;-) "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire -Original Message- From: BugRat Mail System [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 23, 2000 12:54 AM To: [EMAIL PROTECTED] Subject: BugRat Report #659 has been filed. Bug report #659 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/659 REPORT #659 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 Operating System: Linux (SuSE 7.0) OS Release: Kernel 2.2 Platform: Intel Synopsis: mod_jk is garbled Description: After successful compilation of mod_jk, using the supplied Makefile.linux, and after having copied the mod_jk.so file to apaches libexec directory, I get the following error message when starting apache Syntax error on line 8 of /home/ar/projekte/br-2/tomcat/conf/mod_jk.conf-auto: API module structure `jk_module' in file /home/ar/projekte/br-2/libexec/mod_jk.so is garbled - perhaps this is not an Apache module DSO? ./bin/apachectl start: httpd could not be started Line 8 of mod_jk.conf.auto looks like this 5: # 6: # The following line instructs Apache to load the jk module 7: # 8: LoadModule jk_module libexec/mod_jk.so What is wrong?
Re: crimson
Jon Stevens wrote: Hey Craig, Can we pull crimson out of there until it is a bit more stable? :-) One of my Scarab ppl is having problems with it. Catalina does not care (it needs only JAXP/1.0), but Jasper needs JAXP/1.1 compatible APIs. If Xerces supports that, it can be used instead. Or, if you don't use Jasper, you can remove crimson from the "lib" directory and use whatever you want. In general, Xerces is *not* an "economy-sized" download, so I'd personally prefer to leave that replacement opportunity in the hands of the Tomcat installer. -jon Craig
JDBCRealm, possible fix for Bug Report #605
In going through the tomcat-dev archives I found a bug report (#605)
involving the JDBCRealm class that may be related to my last bug
report(#602). In my original patch to fix that problem I missed what seems
to be a similar problem with re-establishing the connection if it has failed
in each method that hits the database in Tomcat 3.2.x. Here are a few
snippets of code from the part I think may be in error ( please forgive the
re-formatting of the code, I am trying to avoid the nastiness that comes
with text being wrapped by my email client ):
Tomcat 3.2:
---
from authenticate:
---
// Establish the database connection if necessary
if ((dbConnection == null) || dbConnection.isClosed()) {
log(sm.getString("jdbcRealm.authDBClosed"));
dbConnection = DriverManager.getConnection(connectionURL);
if( (dbConnection == null) || dbConnection.isClosed() ) {
log(sm.getString("jdbcRealm.authDBReOpenFail"));
return false;
}
dbConnection.setReadOnly(true);
}
---
from getUserRoles:
---
if( (dbConnection == null) || dbConnection.isClosed() ) {
log(sm.getString("jdbcRealm.getUserRolesDBClosed"));
dbConnection = DriverManager.getConnection(connectionURL);
if( dbConnection == null || dbConnection.isClosed() ) {
log(sm.getString("jdbcRealm.getUserRolesDBReOpenFail"));
return null;
}
---
from contextInit:
---
Class.forName(driverName);
if ((connectionName == null || connectionName.equals(""))
(connectionPassword == null || connectionPassword.equals(""))) {
dbConnection = DriverManager.getConnection(connectionURL);
} else {
dbConnection = DriverManager.getConnection(connectionURL,
connectionName,
connectionPassword);
*
Tomcat-Catalina-4.0m5:
---
from authorize:
---
if ((dbConnection == null) || dbConnection.isClosed()) {
log(sm.getString("jdbcRealm.authDBClosed"));
if ((connectionName == null || connectionName.equals(""))
(connectionPassword == null || connectionPassword.equals(""))) {
dbConnection = DriverManager.getConnection(connectionURL);
} else {
dbConnection = DriverManager.getConnection(connectionURL,
connectionName,
connectionPassword);
}
if( (dbConnection == null) || dbConnection.isClosed() ) {
log(sm.getString("jdbcRealm.authDBReOpenFail"));
return null;
}
...
}
---
from start:
---
if ((connectionName == null || connectionName.equals(""))
(connectionPassword == null || connectionPassword.equals(""))) {
dbConnection = DriverManager.getConnection(connectionURL);
} else {
dbConnection = DriverManager.getConnection(connectionURL,
connectionName,
connectionPassword);
}
---
There are a few questions I have about these parts of the code:
* Would it be acceptable for me to submit a patch for this code that
currently gets repeated in 2-3 different places ( in a few different ways
for Tomcat 3.2 ), moving the act of reconnecting to the database to it's own
seperate method that either returns void or returns a connection.
* Would this adversely affect the amount of logging that is done in the
current code?
* If I am interpreting the logic that checks for the presence of a
connection name and connection password correctly, in the case that only
*one* of them is empty or null, the three parameter getConnection method is
used. Is it possible that this could cause problems as well?
I apologize for not catching this with my original patch, and for not
submitting a full patch with this message. I am fairly new at this and want
to be sure 1) My guesswork is correct that these parts of JDBC can/will
cause problems and B) I am doing things the right/acceptable/logical way
before submitting a patch. ( And nacho I promise to include the patch as an
attached text file next time ;) Thanks again and I hope everyone has a great
holiday season!
David Weinrich
cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester TesterHttpServletRequestWrapper.java WrapperFilter.java
craigmcc00/12/22 20:06:47
Modified:tester/src/bin tester.xml
tester/src/tester/org/apache/tester WrapperFilter.java
Added: tester/src/tester/org/apache/tester
TesterHttpServletRequestWrapper.java
Log:
Add the HttpServletRequestWrapper implementation.
Revision ChangesPath
1.3 +0 -2 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- tester.xml2000/12/22 22:13:06 1.2
+++ tester.xml2000/12/23 04:06:46 1.3
@@ -115,11 +115,9 @@
request="${context.path}/GetQueryString01?foo=1"
outContent="GetQueryString01 PASSED"/
-!--
tester host="${host}" port="${port}" debug="0"
request="${context.path}/WrappedGetQueryString01?foo=1"
outContent="GetQueryString01 PASSED"/
---
!-- == Other ServletRequest Tests --
1.2 +4 -4
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/WrapperFilter.java
Index: WrapperFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/WrapperFilter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- WrapperFilter.java2000/12/22 22:13:07 1.1
+++ WrapperFilter.java2000/12/23 04:06:46 1.2
@@ -68,7 +68,7 @@
* it passes on with either generic or HTTP-specific wrappers.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2000/12/22 22:13:07 $
+ * @version $Revision: 1.2 $ $Date: 2000/12/23 04:06:46 $
*/
public class WrapperFilter implements Filter {
@@ -114,10 +114,10 @@
ServletResponse outResponse = inResponse;
if (requestWrapper.equals("generic")) {
outRequest = new TesterServletRequestWrapper(inRequest);
-} /* else if (requestWrapper.equals("http")) {
-outRequest = new TesterHttpServletRequestWrapper(inRequest);
+} else if (requestWrapper.equals("http")) {
+outRequest = new TesterHttpServletRequestWrapper
+((HttpServletRequest) inRequest);
}
-*/
if (responseWrapper.equals("generic")) {
outResponse = new TesterServletResponseWrapper(inResponse);
} else if (responseWrapper.equals("http")) {
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/TesterHttpServletRequestWrapper.java
Index: TesterHttpServletRequestWrapper.java
===
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999, 2000 The Apache Software Foundation. *
* All rights reserved.*
* *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
* fication, are permitted provided that the following conditions are met: *
* *
* 1. Redistributions of source code must retain the above copyright notice *
*notice, this list of conditions and the following disclaimer. *
* *
* 2. Redistributions in binary form must reproduce the above copyright *
*notice, this list of conditions and the following disclaimer in the *
*documentation and/or other materials provided with the distribution. *
* *
* 3. The end-user documentation included with the redistribution, if any, *
*must include the following acknowlegement: *
* *
* "This product includes software developed by the Apache Software *
*Foundation http://www.apache.org/." *
* *
*Alternately, this acknowlegement may
BugRat Report #661 has been filed.
Bug report #661 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/661
REPORT #661 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: non-critical
Confidence: public
Environment:
Release: jakarta-tomcat-3.2.1
JVM Release: Java2 Standard Edition Build 1.3.0_01
Operating System: Windows 2000 Professional
OS Release: Version 5 Build 2195
Platform: Pentium III
Synopsis:
examples/ShowSource always reports "Invalid JSP file" due to logic error in
ShowSource.java
Description:
Within the source for the ShowSource tab from the examples
context, ie. the file installed at:
$(TOMCAT_HOME)\webapps\examples\WEB-INF\classes\examples\ShowSource.java,
lines 23 to 26 look like this:
if ((jspFile.indexOf( ".." ) = 0) ||
(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) ||
(jspFile.toUpperCase().indexOf("/META-INF/") != 0))
throw new JspTagException("Invalid JSP file " + jspFile);
lines 24 and 25 should use "!= -1" rather than "!= 0"
This effects the "show source" links of all the
jsp examples that use the "ShowSource" tag.
Title:
BugRat Report #
661
BugRat Report #
661
Project:
Tomcat
Release:
jakarta-tomcat-3.2.1
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
medium
Severity:
non-critical
Confidence:
public
Submitter:
Tony Robertson ([EMAIL PROTECTED])
Date Submitted:
Dec 22 2000, 11:19:25 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
examples/ShowSource always reports "Invalid JSP file" due to logic error in ShowSource.java
Environment: (jvm, os, osrel, platform)
Java2 Standard Edition Build 1.3.0_01, Windows 2000 Professional, Version 5 Build 2195, Pentium III
Additional Environment Description:
Report Description:
Within the source for the ShowSource tab from the examples
context, ie. the file installed at:
$(TOMCAT_HOME)\webapps\examples\WEB-INF\classes\examples\ShowSource.java,
lines 23 to 26 look like this:
if ((jspFile.indexOf( ".." ) >= 0) ||
(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) ||
(jspFile.toUpperCase().indexOf("/META-INF/") != 0))
throw new JspTagException("Invalid JSP file " + jspFile);
lines 24 and 25 should use "!= -1" rather than "!= 0"
This effects the "show source" links of all the
jsp examples that use the "ShowSource" tag.
How To Reproduce:
null
Workaround:
null
View this report online...
