DO NOT REPLY [Bug 29936] - XML parser loading problems by container
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29936 XML parser loading problems by container --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 07:57 --- Remy: You mention that there hasn;t been any classloader chnages since 5.0.16, but to the best of my knowledge 5.0.16 did not store service provider details in the apache work/catalina/localhost/webapp/loader sub-directories. Are there any explanations on this available? Tim: The taglibs are declared as: %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; % %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; % So not multiple declarations - there ins aninclude but this doesn't use taglibs. The problem is instantly resolved by removing saxon and crimson from the web- app lib. Thanks for your help so far... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Money
Do you have no money? Norton AntiVirus Deleted1.txt Description: plain/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29333] - Unable to read TLD
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29333. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29333 Unable to read TLD --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 11:43 --- I've experienced the same problem with SUNs java SDK 1.3.1-b24 but not in 1.3.1_01 or 1.3.1_12-b03. I guess it is a bug that was corrected in ver 1.3.1_01 but I can't find any info about it in SUNs release notes. I've only tested the Solaris sparc packages. /Ulrik Svensson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29579] - J2SE 1.5.0 and xmlParserAPIs.jar
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29579. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29579 J2SE 1.5.0 and xmlParserAPIs.jar --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 13:04 --- Well, at one point Tomcat will want to support JDK 1.5, won't it? How will it be solved then? Would it be possible to fix this by not loading $TOMCAT_HOME/common/endorsed/xmlParserAPIs.jar in Tomcat classloader, if Tomcat is running on JDK 1.5? This file would only be used on JDKK 1.4.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29949] New: - mod_jk2 ajp13 problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29949 mod_jk2 ajp13 problem Summary: mod_jk2 ajp13 problem Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Sometimes, I got such strange errors in Apache2 log files: [Wed Jul 07 14:27:52 2004] [error] ajp13.service() ajpGetReply recoverable error 3 [Wed Jul 07 14:28:06 2004] [error] ajp13.service() ajpGetReply recoverable error 3 [Wed Jul 07 14:28:06 2004] [error] ajp13.service() Error forwarding ajp13:vassil.sof.intercomponentware.com:4007 1 0 [Wed Jul 07 14:28:06 2004] [error] mod_jk2.handler() Error connecting to tomcat 3, status 500 [Wed Jul 07 15:49:15 2004] [error] ajp13.service() ajpGetReply recoverable error 3 [Wed Jul 07 15:49:15 2004] [error] ajp13.service() Error forwarding ajp13:vassil.sof.intercomponentware.com:4007 1 0 [Wed Jul 07 15:49:15 2004] [error] mod_jk2.handler() Error connecting to tomcat 3, status 200 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29950] New: - Omit special symbol combinations ( like \$ )
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29950. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29950 Omit special symbol combinations ( like \$ ) Summary: Omit special symbol combinations ( like \$ ) Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I noticed that Tomcat 5.0.25 when see such combination of characters \$ it removes the leading slash ( \ ). There is no such bug in Tomcat 4.1.30 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29526] - Cannot undeploy and deploy war file with on the same context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29526. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29526 Cannot undeploy and deploy war file with on the same context --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 14:35 --- tired of mickey mouse OS The same happened to me on AIX 5 with /webapps on a NFS mounted drive, with NFS lock files hanging around instead of the jars itself, thereby blocking removal of the directory. The really annoying part is that the Ant task claims success: wardeploymanager: [deploy] OK - Anwendung mit Kontext Pfad /bre entfernt [deploy] OK - Anwendung mit Kontext Pfad /bre entfernt [deploy] OK - Anwendung mit Kontext Pfad /bre installiert Isn't there a way to reliably detect that the webapp removal failed (for whatever reason)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29936] - XML parser loading problems by container
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29936 XML parser loading problems by container [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 14:49 --- If you don't know what 5.0.16 has and what it does not have, I think you need to check the CVS history. I really cannot see anything I'd like to test in this bug report (except the usual: we don't support replacing the XML provider, except using the JVM provided mechanism). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29950] - Omit special symbol combinations ( like \$ )
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29950. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29950 Omit special symbol combinations ( like \$ ) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Component|Catalina|Jasper Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 15:17 --- This is part of the jsp 2 spec. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29953] New: - redundancy in code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29953 redundancy in code Summary: redundancy in code Product: Tomcat 5 Version: 5.0.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, In the class 'org.apache.ajp.tomcat4.Ajp13Processor' on lines - 134 135 the method call - 'this.request.setConnector(connector);' is repeated. Any possible reason for doing the above??? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this Unfortunately, I'm against useless code in this branch. JSR 160 being brand new, you're going to need new software pretty much everywhere, but of course upgrading the JDK is not an option. Given the new branch changes the API rather significantly, I think it's not going to be a release people will be upgrading to. If it still doesn't make sense, then you can probably manage to cut paste a few lines of code from the JMX docs, right ? ;) sin I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? -- Jess Holle
Re: [5.next] Progress
Jess Holle wrote: I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? It's the exact opposite. With JDK 1.5, we need no pluggable something, no nothing. So this is why I really want to do that instead of bothering with more dead code. I'm ok with a special JDK 1.4 package full of optional components being put together (assuming none of the new syntax gets used, of course), which could contain your listener and other JARs (like Xerces). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29953] - redundancy in code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29953 redundancy in code [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 15:56 --- The org.apache.ajp. package is not supported. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ready for mod_jk 1.2.6 release?
Hi, the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. The 1.2 branch is still the preferred branch for combination with apache 1.3. Is there any volunteer to make an official 1.2.6 release? I do hope so ;-) Another good argument: The documentation of the new features is already there (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), so no additional work and furthermore, the documentation up to now does not mention, that all these features are still not available, because 1.2.6 has never been released. Many thanks to whoever wrote that document. I worked with a cvs build under solaris for some weeks without problems, but for production purposes people need an official release. The last changes in the native jk code is more then 6 weeks old and there is no code change activity at the moment. So this might be a good point in time to release mod_jk 1.2.6. Looking forward for positive feedback Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Jess Holle wrote: Though I also really like Java 5's [yep, another neat numbering change from Sun :-)] built-MBeans for JVM monitoring, I'd *really* like to see a JSR 160 solution in Tomcat that works in Java 1.4.x and Java 1.5 (aka 5). Is this the plan/hope? At a high level it does not look too nasty to do this Unfortunately, I'm against useless code in this branch. JSR 160 being brand new, you're going to need new software pretty much everywhere, but of course upgrading the JDK is not an option. Given the new branch changes the API rather significantly, I think it's not going to be a release people will be upgrading to. If it still doesn't make sense, then you can probably manage to cut paste a few lines of code from the JMX docs, right ? ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29936] - XML parser loading problems by container
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29936 XML parser loading problems by container --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 08:20 --- Also, I must set my web.xml for the web-app to : ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd version=2.4 instead of : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app Otherwise tomcat gives errors when compiling the jsp indicating that it can't find bean properties etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29953] - redundancy in code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29953 redundancy in code --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 16:16 --- But this package is used in Tomcat 5 right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: I'll play with this as I have time, but I'll be doing the same sort of thing with our own app first. As I see it (and I could be offbase, of course, as I've not had time to code this), one just needs a pluggable SPI sort of interface responsible for: 1. A singleton get-or-create MBeanServer method * Default to platform MBeanServer in 1.5, but allow use of mx4j or the like 2. An export MBeanServer for remote ops method * Details, e.g. protocols, ports / port ranges, etc, to be controlled by XML tags, of course Am I over-simplifying this? It's the exact opposite. With JDK 1.5, we need no pluggable something, no nothing. So this is why I really want to do that instead of bothering with more dead code. In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm ok with a special JDK 1.4 package full of optional components being put together (assuming none of the new syntax gets used, of course), which could contain your listener and other JARs (like Xerces). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java
remm2004/07/07 09:28:58
Modified:jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
Log:
- Add an extra flag to make development mode (the default) faster, which could be
useful (some are also
dynamically generating JSPs).
- Let me know if this causes problems.
Revision ChangesPath
1.38 +14 -0
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
Index: JspServletWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- JspServletWrapper.java24 May 2004 21:33:48 - 1.37
+++ JspServletWrapper.java7 Jul 2004 16:28:58 - 1.38
@@ -75,6 +75,7 @@
private int tripCount;
private JasperException compileException;
private long servletClassLastModifiedTime;
+private long lastModificationTest = 0L;
/*
* JspServletWrapper for JSP pages.
@@ -379,4 +380,17 @@
}
}
+/**
+ * @return Returns the lastModificationTest.
+ */
+public long getLastModificationTest() {
+return lastModificationTest;
+}
+/**
+ * @param lastModificationTest The lastModificationTest to set.
+ */
+public void setLastModificationTest(long lastModificationTest) {
+this.lastModificationTest = lastModificationTest;
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
remm2004/07/07 09:29:10
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
- Add an extra flag to make development mode (the default) faster, which could be
useful (some are also
dynamically generating JSPs).
- Let me know if this causes problems.
Revision ChangesPath
1.90 +7 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- Compiler.java 1 Jul 2004 09:44:27 - 1.89
+++ Compiler.java 7 Jul 2004 16:29:10 - 1.90
@@ -515,6 +515,11 @@
boolean outDated = false;
String jsp = ctxt.getJspFile();
+if ((jsw != null) ((jsw.getLastModificationTest() + 2000)
+ System.currentTimeMillis())) {
+return false;
+}
+
long jspRealLastModified = 0;
try {
URL jspUrl = ctxt.getResource(jsp);
@@ -560,7 +565,8 @@
if( jsw==null ) {
return outDated;
}
-
+jsw.setLastModificationTest(System.currentTimeMillis());
+
List depends = jsw.getDependants();
if (depends == null) {
return outDated;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29955] New: - servlet.getServletContext().getRequestDispatcher() returns null if supplied with a URI containing a semi-colon.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29955. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29955 servlet.getServletContext().getRequestDispatcher() returns null if supplied with a URI containing a semi-colon. Summary: servlet.getServletContext().getRequestDispatcher() returns null if supplied with a URI containing a semi- colon. Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] servlet.getServletContext().getRequestDispatcher() returns null if supplied with a URI containing a semi-colon. i.e. servlet.getServletContext().getRequestDispatcher(/test.jsp? message=colon;colon); Even if you use response.encodeURL() to encode the URL before passing it to getRequestDispatcher(), the semi-colon remains and confuses getRequestDispatcher (). Full test case available on request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java
remm2004/07/07 09:29:34 Modified:coyote/src/java/org/apache/coyote Request.java Log: - Remove deprecation by using Costin's factory pattern. Revision ChangesPath 1.28 +15 -15 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java Index: Request.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- Request.java 24 Feb 2004 08:54:29 - 1.27 +++ Request.java 7 Jul 2004 16:29:34 - 1.28 @@ -87,31 +87,31 @@ private int serverPort = -1; -private MessageBytes serverNameMB = new MessageBytes(); +private MessageBytes serverNameMB = MessageBytes.newInstance(); private String localHost; private int remotePort; private int localPort; -private MessageBytes schemeMB = new MessageBytes(); +private MessageBytes schemeMB = MessageBytes.newInstance(); -private MessageBytes methodMB = new MessageBytes(); -private MessageBytes unparsedURIMB = new MessageBytes(); -private MessageBytes uriMB = new MessageBytes(); -private MessageBytes decodedUriMB = new MessageBytes(); -private MessageBytes queryMB = new MessageBytes(); -private MessageBytes protoMB = new MessageBytes(); +private MessageBytes methodMB = MessageBytes.newInstance(); +private MessageBytes unparsedURIMB = MessageBytes.newInstance(); +private MessageBytes uriMB = MessageBytes.newInstance(); +private MessageBytes decodedUriMB = MessageBytes.newInstance(); +private MessageBytes queryMB = MessageBytes.newInstance(); +private MessageBytes protoMB = MessageBytes.newInstance(); // remote address/host -private MessageBytes remoteAddrMB = new MessageBytes(); -private MessageBytes localNameMB = new MessageBytes(); -private MessageBytes remoteHostMB = new MessageBytes(); -private MessageBytes localAddrMB = new MessageBytes(); +private MessageBytes remoteAddrMB = MessageBytes.newInstance(); +private MessageBytes localNameMB = MessageBytes.newInstance(); +private MessageBytes remoteHostMB = MessageBytes.newInstance(); +private MessageBytes localAddrMB = MessageBytes.newInstance(); private MimeHeaders headers = new MimeHeaders(); -private MessageBytes instanceId = new MessageBytes(); +private MessageBytes instanceId = MessageBytes.newInstance(); /** * Notes. @@ -143,8 +143,8 @@ private Cookies cookies = new Cookies(headers); private Parameters parameters = new Parameters(); -private MessageBytes remoteUser=new MessageBytes(); -private MessageBytes authType=new MessageBytes(); +private MessageBytes remoteUser=MessageBytes.newInstance(); +private MessageBytes authType=MessageBytes.newInstance(); private HashMap attributes=new HashMap(); private Response response; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapperValve.java StandardHostValve.java
remm2004/07/07 09:32:59
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapperValve.java StandardHostValve.java
Log:
- Among some of my changes, facading works differently now (I can't really remember
why this problem
appeared, though).
Revision ChangesPath
1.31 +6 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
Index: StandardWrapperValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- StandardWrapperValve.java 27 Jun 2004 23:56:22 - 1.30
+++ StandardWrapperValve.java 7 Jul 2004 16:32:59 - 1.31
@@ -187,8 +187,7 @@
ApplicationFilterFactory factory =
ApplicationFilterFactory.getInstance();
ApplicationFilterChain filterChain =
-factory.createFilterChain((ServletRequest) request,
- wrapper, servlet);
+factory.createFilterChain(request, wrapper, servlet);
// Call the filter chain for this request
// NOTE: This also calls the servlet's service() method
@@ -204,7 +203,8 @@
if (context.getSwallowOutput()) {
try {
SystemLogHandler.startCapture();
-filterChain.doFilter(request, response);
+filterChain.doFilter(request.getRequest(),
+response.getResponse());
} finally {
String log = SystemLogHandler.stopCapture();
if (log != null log.length() 0) {
@@ -212,7 +212,8 @@
}
}
} else {
-filterChain.doFilter(request, response);
+filterChain.doFilter
+(request.getRequest(), response.getResponse());
}
}
1.23 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
Index: StandardHostValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StandardHostValve.java23 Jun 2004 16:59:40 - 1.22
+++ StandardHostValve.java7 Jul 2004 16:32:59 - 1.23
@@ -350,7 +350,7 @@
request.getContext().getServletContext();
RequestDispatcher rd =
servletContext.getRequestDispatcher(errorPage.getLocation());
-rd.forward(request, response);
+rd.forward(request.getRequest(), response.getResponse());
// If we forward, the response is suspended again
response.setSuspended(false);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Request.java
remm2004/07/07 09:34:16
Modified:catalina/src/share/org/apache/catalina/connector
Request.java
Log:
- Restore the ability to easily access the internal session. Otherwise, internal
components would have to use the
manager, which is far less efficient and more complex.
Revision ChangesPath
1.5 +37 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Request.java 24 Jun 2004 16:20:21 - 1.4
+++ Request.java 7 Jul 2004 16:34:16 - 1.5
@@ -2072,7 +2072,12 @@
* if necessary.
*/
public HttpSession getSession() {
-return doGetSession(true);
+Session session = doGetSession(true);
+if (session != null) {
+return session.getSession();
+} else {
+return null;
+}
}
@@ -2083,7 +2088,12 @@
* @param create Create a new session if one does not exist
*/
public HttpSession getSession(boolean create) {
-return doGetSession(create);
+Session session = doGetSession(create);
+if (session != null) {
+return session.getSession();
+} else {
+return null;
+}
}
@@ -2195,10 +2205,30 @@
}
+/**
+ * Return the session associated with this Request, creating one
+ * if necessary.
+ */
+public Session getSessionInternal() {
+return doGetSession(true);
+}
+
+
+/**
+ * Return the session associated with this Request, creating one
+ * if necessary and requested.
+ *
+ * @param create Create a new session if one does not exist
+ */
+public Session getSessionInternal(boolean create) {
+return doGetSession(create);
+}
+
+
// -- Protected Methods
-protected HttpSession doGetSession(boolean create) {
+protected Session doGetSession(boolean create) {
// There cannot be a session if no context has been assigned yet
if (context == null)
@@ -2208,7 +2238,7 @@
if ((session != null) !session.isValid())
session = null;
if (session != null)
-return (session.getSession());
+return (session);
// Return the requested session if it exists and is valid
Manager manager = null;
@@ -2226,7 +2256,7 @@
session = null;
if (session != null) {
session.access();
-return (session.getSession());
+return (session);
}
}
@@ -2253,7 +2283,7 @@
if (session != null) {
session.access();
-return (session.getSession());
+return (session);
} else {
return (null);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java DigestAuthenticator.java BasicAuthenticator.java SSLAuthenticator.java AuthenticatorBase.java
remm2004/07/07 09:39:46
Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java DigestAuthenticator.java
BasicAuthenticator.java SSLAuthenticator.java
AuthenticatorBase.java
Log:
- Restore the ability to easily access the internal session. Otherwise, internal
components would have to use the
manager, which is far less efficient and more complex.
- Use that in the authenticators.
Revision ChangesPath
1.13 +9 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
Index: FormAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- FormAuthenticator.java24 Jun 2004 15:28:28 - 1.12
+++ FormAuthenticator.java7 Jul 2004 16:39:46 - 1.13
@@ -112,7 +112,7 @@
principal.getName() + ');
// Associate the session with any existing SSO session
if (ssoId != null)
-associate(ssoId, getSession(request, true));
+associate(ssoId, request.getSessionInternal(true));
return (true);
}
@@ -133,7 +133,7 @@
// Have we authenticated this user before but have caching disabled?
if (!cache) {
-session = getSession(request, true);
+session = request.getSessionInternal(true);
if (log.isDebugEnabled())
log.debug(Checking for reauthenticate in session + session);
String username =
@@ -162,7 +162,7 @@
// Is this the re-submit of the original request URI after successful
// authentication? If so, forward the *original* request instead.
if (matchRequest(request)) {
-session = getSession(request, true);
+session = request.getSessionInternal(true);
if (log.isDebugEnabled())
log.debug(Restore request from session ' + session.getId()
+ ');
@@ -198,7 +198,7 @@
// No -- Save this request and redirect to the form login page
if (!loginAction) {
-session = getSession(request, true);
+session = request.getSessionInternal(true);
if (log.isDebugEnabled())
log.debug(Save request in session ' + session.getId() + ');
saveRequest(request, session);
@@ -206,7 +206,7 @@
context.getServletContext().getRequestDispatcher
(config.getLoginPage());
try {
-disp.forward(request, response);
+disp.forward(request.getRequest(), response.getResponse());
response.finishResponse();
} catch (Throwable t) {
log.warn(Unexpected error forwarding to login page, t);
@@ -227,7 +227,7 @@
context.getServletContext().getRequestDispatcher
(config.getErrorPage());
try {
-disp.forward(request, response);
+disp.forward(request.getRequest(), response.getResponse());
} catch (Throwable t) {
log.warn(Unexpected error forwarding to error page, t);
}
@@ -238,7 +238,7 @@
log.debug(Authentication of ' + username + ' was successful);
if (session == null)
-session = getSession(request, false);
+session = request.getSessionInternal(false);
if (session == null) {
if (container.getLogger().isDebugEnabled())
container.getLogger().debug(User took so long to log on the
session expired);
@@ -283,7 +283,7 @@
protected boolean matchRequest(Request request) {
// Has a session been created?
- Session session = getSession(request, false);
+ Session session = request.getSessionInternal(false);
if (session == null)
return (false);
1.9 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
Index: DigestAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- DigestAuthenticator.java 24 Jun 2004 15:28:28 - 1.8
+++ DigestAuthenticator.java 7 Jul 2004 16:39:46 - 1.9
@@ -182,7 +182,7 @@
// to get
DO NOT REPLY [Bug 29953] - redundancy in code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29953 redundancy in code --- Additional Comments From [EMAIL PROTECTED] 2004-07-07 16:44 --- nope - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ready for mod_jk 1.2.6 release?
the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. +1 for releasing as son as possible; we missed already the last service pack on NetWare and had to ship cvs code... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Remy Maucherat wrote: Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Yep. I'm just anxious to see JMX RMI remoting support in Tomcat soon, i.e. in a stable shipping version that supports a stable, shipping JRE (i.e. 1.4.2). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29956] New: - Incorrect handling of negative timeout in SingleSignOn.sessionEvent()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29956.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29956
Incorrect handling of negative timeout in SingleSignOn.sessionEvent()
Summary: Incorrect handling of negative timeout in
SingleSignOn.sessionEvent()
Product: Tomcat 4
Version: 4.1.30
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When SingleSignOn.sessionEvent() is handling a destroyed session, it checks
whether the session is expiring because it timed out or because it was
explicitly logged out. This check fails to account for the negative timeout
case. To fix, at line 387, replace:
if (System.currentTimeMillis() - session.getLastAccessedTime() =
session.getMaxInactiveInterval() * 1000) {
with
if ((session.getMaxInactiveInterval() 0)
(System.currentTimeMillis() - session.getLastAccessedTime() =
session.getMaxInactiveInterval() * 1000) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Progress
Hello Jess, I have made a test with MX4J 2.0.1 and JSR 160 Connector. See my patches http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29259 Testet with MC4J Console and works very well. regards Peter Jess Holle schrieb: Remy Maucherat wrote: Jess Holle wrote: In my case even with 1.5 I need a pluggable (2) from above. Why? Because I need to work with port ranges and grab the first free port (with MBeans then proxied to a daemon with a consistent port #). 1.5 has no automatic machinery for this as best I can tell. It's true that (1) is simple getPlatformMbeanServer() [or whatever it is called again] in 1.5, but I believe it should be light and easy enough to stick something else under the covers here. I'm tired of interfaces, so I have to say I'm against this, especially for a specific purpose (I would tend to believe you can configure lots of stuff with JDK 1.5, though). You should simply use your own server listener (I think server lifecycle listeners are here to stay). Cool. As I said though, I've got my own processes to instrument first. I'd just like to see Tomcat progress in a similar fashion so that one monitor Tomcat in the same fashion sooner rather than later. Regardless on how the JMX connector is configured on the server side, it will work the same from the client's perspective. Yep. I'm just anxious to see JMX RMI remoting support in Tomcat soon, i.e. in a stable shipping version that supports a stable, shipping JRE (i.e. 1.4.2). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaService Tomcat4.1 or tomcat 5
Hey, I used successfull the Java Service Wrapper. see http://wrapper.tanukisoftware.org/doc/english/introduction.html Look at http://centaurus.sourceforge.net project to integrate tomcat with gui installer at Linux and Windows. Very good option to used Tomcat as service on different platforms regards Peter jean-frederic clere schrieb: Hi, It seems that www.alexandriasc.com does not work any more, does someone knows why? In Tomcat5 we are using procrun, should n't we do the same on Tomcat4? Cheers Jean-Frederic - 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: Ready for mod_jk 1.2.6 release?
+1 important features to help customers to have a stable loadbalancer... At Linux Suse 9.0 it works fine. regards Peter Rainer Jung schrieb: Hi, the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. The 1.2 branch is still the preferred branch for combination with apache 1.3. Is there any volunteer to make an official 1.2.6 release? I do hope so ;-) Another good argument: The documentation of the new features is already there (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), so no additional work and furthermore, the documentation up to now does not mention, that all these features are still not available, because 1.2.6 has never been released. Many thanks to whoever wrote that document. I worked with a cvs build under solaris for some weeks without problems, but for production purposes people need an official release. The last changes in the native jk code is more then 6 weeks old and there is no code change activity at the moment. So this might be a good point in time to release mod_jk 1.2.6. Looking forward for positive feedback Rainer Jung - 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: Ready for mod_jk 1.2.6 release?
Rainer Jung wrote: the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. I would like to see one. I am already using CVS to get the new features and bug fixes, but an official release would be nice. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Yahoo! À´ÐÅ×Ô¶¯»Ø¸´
´ËÓÊÏäÔÝʱֹͣʹÓÃ,[EMAIL PROTECTED]@hotmail.com ллÄãµÄÀ´ÐÅ.ÑîÏÈÉú Original Message: X-Rocket-Spam: 218.164.171.132 X-YahooFilteredBulk: 218.164.171.132 X-Rocket-Track: 3911564: 20 ; SERVER=202.43.216.218 Return-Path: [EMAIL PROTECTED] Received: from 218.164.171.132 (EHLO yahoo.com.cn) (218.164.171.132) by mta105.mail.cnb.yahoo.com with SMTP; Thu, 08 Jul 2004 09:06:48 +0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 5664ddff?$??§2 Date: Thu, 8 Jul 2004 09:06:46 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0010_6146.6414 X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --=_NextPart_000_0010_6146.6414 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit i am speachless about your document! --=_NextPart_000_0010_6146.6414 Content-Type: application/x-zip-compressed; name=image_mails.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=image_mails.zip _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29966] New: - the servlet code generated from jsp always have new line code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29966. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29966 the servlet code generated from jsp always have new line code Summary: the servlet code generated from jsp always have new line code Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] the servlet code generated from jsp always has \r\n Any setting in tomcat 5 can avoid adding this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
