RE: [PATCH] Prevent NPE if CLIENT-CERT auth fails
Sorry. Only just noticed the attachment was removed somewhere along the way.
Contents of patch below.
Index: http11/src/java/org/apache/coyote/http11/Http11Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/
http11/Http11Processor.java,v
retrieving revision 1.75
diff -u -r1.75 Http11Processor.java
--- http11/src/java/org/apache/coyote/http11/Http11Processor.java 19 Aug 2003
16:15:21 - 1.75
+++ http11/src/java/org/apache/coyote/http11/Http11Processor.java 20 Aug 2003
19:44:56 -
@@ -845,17 +845,17 @@
}
} else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
-
-try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
-if( sslO != null) {
-request.setAttribute
-(SSLSupport.CERTIFICATE_KEY, sslO);
+if (sslSupport != null) {
+try {
+Object sslO = sslSupport.getPeerCertificateChain(true);
+if( sslO != null) {
+request.setAttribute
+(SSLSupport.CERTIFICATE_KEY, sslO);
+}
+} catch (Exception e) {
+log.warn(Exception getting SSL Cert,e);
}
-} catch (Exception e) {
-log.warn(Exception getting SSL Cert,e);
}
-
}
}
On Wednesday, August 20, 2003 9:05 PM, Mark Thomas
[SMTP:[EMAIL PROTECTED] wrote:
A small patch.
If auth fails, SSL session is terminated. Subsequent call to
sslSupport.getPeerCertifcate() generates a NPE as sslSupport is null in this
case.
File: ATT0.txt
-
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 ApplicationContext.java ApplicationFilterChain.java StandardHostValve.java StandardPipeline.java
remm2003/08/29 16:11:31
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java ApplicationFilterChain.java
StandardHostValve.java StandardPipeline.java
Log:
- Avoid references leak: ckean up and recycle any TL resources.
- Reset the context CL after invoking the pipeline.
Revision ChangesPath
1.18 +12 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ApplicationContext.java 16 Aug 2003 00:35:32 - 1.17
+++ ApplicationContext.java 29 Aug 2003 23:11:31 - 1.18
@@ -478,8 +478,6 @@
if (mappingData == null) {
mappingData = new MappingData();
localMappingData.set(mappingData);
-} else {
-mappingData.recycle();
}
// Map the URI
@@ -497,11 +495,16 @@
return (null);
}
+Wrapper wrapper = (Wrapper) mappingData.wrapper;
+String wrapperPath = mappingData.wrapperPath.toString();
+String pathInfo = mappingData.pathInfo.toString();
+
+mappingData.recycle();
+
// Construct a RequestDispatcher to process this request
return (RequestDispatcher) new ApplicationDispatcher
-((Wrapper) mappingData.wrapper, uriCC.toString(),
- mappingData.wrapperPath.toString(),
- mappingData.pathInfo.toString(), queryString, null);
+(wrapper, uriCC.toString(), wrapperPath, pathInfo,
+ queryString, null);
}
1.7 +5 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
Index: ApplicationFilterChain.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ApplicationFilterChain.java 25 May 2003 14:27:01 - 1.6
+++ ApplicationFilterChain.java 29 Aug 2003 23:11:31 - 1.7
@@ -343,6 +343,7 @@
n = 0;
pos = 0;
servlet = null;
+support = null;
}
1.10 +7 -4
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.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- StandardHostValve.java16 Aug 2003 13:43:43 - 1.9
+++ StandardHostValve.java29 Aug 2003 23:11:31 - 1.10
@@ -206,6 +206,9 @@
status(request, response);
}
+Thread.currentThread().setContextClassLoader
+(StandardHostValve.class.getClassLoader());
+
}
1.14 +4 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardPipeline.java
Index: StandardPipeline.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardPipeline.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- StandardPipeline.java 23 Jul 2003 13:31:59 - 1.13
+++ StandardPipeline.java 29 Aug 2003 23:11:31 - 1.14
@@ -562,6 +562,7 @@
valveContext.set(basic, valves);
valveContext.invokeNext(request, response);
+valveContext.set(null, 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/loader WebappClassLoader.java
remm2003/08/29 16:05:50
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Release all logs associated with this CL when stopping the CL.
- Avoid NPE in toString after stop.
Revision ChangesPath
1.20 +10 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- WebappClassLoader.java17 Aug 2003 08:36:14 - 1.19
+++ WebappClassLoader.java29 Aug 2003 23:05:50 - 1.20
@@ -834,10 +834,12 @@
sb.append(delegate);
sb.append(\r\n);
sb.append( repositories:\r\n);
-for (int i = 0; i repositories.length; i++) {
-sb.append();
-sb.append(repositories[i]);
-sb.append(\r\n);
+if (repositories != null) {
+for (int i = 0; i repositories.length; i++) {
+sb.append();
+sb.append(repositories[i]);
+sb.append(\r\n);
+}
}
if (this.parent != null) {
sb.append(-- Parent Classloader:\r\n);
@@ -1520,6 +1522,7 @@
lastModifiedDates = null;
paths = null;
hasExternalRepositories = false;
+parent = null;
permissionList.clear();
loaderPC.clear();
@@ -1527,6 +1530,8 @@
if (loaderDir != null) {
deleteDir(loaderDir);
}
+
+org.apache.commons.logging.LogFactory.release(this);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 22328] - javax.management.ReflectionException:Cannot find method getClassName with this signature
IIRC - I think Amy submitted a patch to fix this. Can I resolve this as fixed? -Tim [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22328. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22328 javax.management.ReflectionException: Cannot find method getClassName with this signature [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED OS/Version|Windows NT/2K |Linux Priority|Other |High Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-08-29 18:37 --- Der Fehler passiert, wenn man die Valve org.apache.catalina.valves.AccessLogValve ffnet. Leider, kenne ich noch keine Abhilfe, auer der, die Valve zu machen. Ausgerechnet aber gerade diese Valve ist uerst wichtig! java.lang.NoSuchMethodException: org.apache.catalina.valves.AccessLogValve.getClassName() at java.lang.Class.getMethod0(Class.java:1756) at java.lang.Class.getMethod(Class.java:963) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:372) at org.apache.commons.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:238) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.getAttribute(InvokerMBeanServerInterceptor.java:242) . - 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]
removing log() from error processing in StandardWrapperValve.java??
In the use case of a servlet or filter throwing an ServletException, StandardWrapperValve will log the exception to its logger. If the error is an expected one (such as session timeout or browser compatibility check) and there is a configured error-page directive to handle the exception, StandardWrapperValve stills logs the message. This causes many useless stack traces in the logs for error handling that is already caught. Does it make sense to remove the log() statement? The the job of logging the exception belongs to either ErrorReportValve(?) or the user defined error handler? Just to be clear, this is only the log() in the catch (ServletException e) code that I wish to remove. Or I can my developer rewrite his code to use error handling for real errors. Advice? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22806] - Link to Tomcat Administration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22806. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22806 Link to Tomcat Administration --- Additional Comments From [EMAIL PROTECTED] 2003-08-29 23:03 --- You need to use gnutar. http://marc.theaimsgroup.com/?l=tomcat-userm=104978978819668w=2 covers this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19965] - mod_jk2 connection fails, workerEnv.init() create slot epStat.0 failed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19965. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19965 mod_jk2 connection fails, workerEnv.init() create slot epStat.0 failed [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Solaris |Linux Priority|Other |Low Platform|Sun |PC Version|4.1.24 |4.1.27 --- Additional Comments From [EMAIL PROTECTED] 2003-08-30 01:03 --- Daniel Excellent Recommendations! It works. Now to should someone fix the fact that the worker2.properties files should really be back in the $TOMCAT_HOME/conf directory. It is a bit confusing that the worker2.properties file *should* be in the apache Conf directory, but in reality needs to be in the SERVER_ROOT/conf directory - which aren't necessarily the same thing – I followed the instructions on http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/vhosthowto.html which state: ./configure -prefix=/usr/local/apache2.0.43 --sysconfdir=/etc/apache --localstatedir=/var --enable-so - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
billbarker2003/08/29 19:38:06
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Make certain that we are still in an https session before looking for certs.
Submitted By: Mark Thomas [EMAIL PROTECTED]
Revision ChangesPath
1.76 +9 -9
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -r1.75 -r1.76
--- Http11Processor.java 19 Aug 2003 16:15:21 - 1.75
+++ Http11Processor.java 30 Aug 2003 02:38:06 - 1.76
@@ -845,17 +845,17 @@
}
} else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
-
-try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
-if( sslO != null) {
-request.setAttribute
-(SSLSupport.CERTIFICATE_KEY, sslO);
+if( sslSupport != null) {
+try {
+Object sslO = sslSupport.getPeerCertificateChain(true);
+if( sslO != null) {
+request.setAttribute
+(SSLSupport.CERTIFICATE_KEY, sslO);
+}
+} catch (Exception e) {
+log.warn(Exception getting SSL Cert,e);
}
-} catch (Exception e) {
-log.warn(Exception getting SSL Cert,e);
}
-
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
billbarker2003/08/29 19:45:02
Modified:http11/src/java/org/apache/coyote/http11 Tag: coyote_10
Http11Processor.java
Log:
Port patch.
Submitted by: Mark Thomas [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.55.2.4 +9 -9
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.55.2.3
retrieving revision 1.55.2.4
diff -u -r1.55.2.3 -r1.55.2.4
--- Http11Processor.java 13 Jul 2003 21:53:07 - 1.55.2.3
+++ Http11Processor.java 30 Aug 2003 02:45:02 - 1.55.2.4
@@ -781,17 +781,17 @@
}
} else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
-
-try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
-if( sslO != null) {
-request.setAttribute
-(SSLSupport.CERTIFICATE_KEY, sslO);
+if( sslSupport != null) {
+try {
+Object sslO = sslSupport.getPeerCertificateChain(true);
+if( sslO != null) {
+request.setAttribute
+(SSLSupport.CERTIFICATE_KEY, sslO);
+}
+} catch (Exception e) {
+log.warn(Exception getting SSL Cert,e);
}
-} catch (Exception e) {
-log.warn(Exception getting SSL Cert,e);
}
-
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Prevent NPE if CLIENT-CERT auth fails
Patch committed. Thanks much!
Mark Thomas [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Sorry. Only just noticed the attachment was removed somewhere along the
way.
Contents of patch below.
Index: http11/src/java/org/apache/coyote/http11/Http11Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/
http11/Http11Processor.java,v
retrieving revision 1.75
diff -u -r1.75 Http11Processor.java
--- http11/src/java/org/apache/coyote/http11/Http11Processor.java 19 Aug
2003
16:15:21 - 1.75
+++ http11/src/java/org/apache/coyote/http11/Http11Processor.java 20 Aug
2003
19:44:56 -
@@ -845,17 +845,17 @@
}
} else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
-
-try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
-if( sslO != null) {
-request.setAttribute
-(SSLSupport.CERTIFICATE_KEY, sslO);
+if (sslSupport != null) {
+try {
+Object sslO =
sslSupport.getPeerCertificateChain(true);
+if( sslO != null) {
+request.setAttribute
+(SSLSupport.CERTIFICATE_KEY, sslO);
+}
+} catch (Exception e) {
+log.warn(Exception getting SSL Cert,e);
}
-} catch (Exception e) {
-log.warn(Exception getting SSL Cert,e);
}
-
}
}
On Wednesday, August 20, 2003 9:05 PM, Mark Thomas
[SMTP:[EMAIL PROTECTED] wrote:
A small patch.
If auth fails, SSL session is terminated. Subsequent call to
sslSupport.getPeerCertifcate() generates a NPE as sslSupport is null in
this
case.
File: ATT0.txt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j-t-c] Thread problem in jk_uri_worker_map.c
I'll put this one in in the interest of time, but Marc should be given karma (like any other Tomcat committer) to j-t-c, if he doesn't have it already. Marc Saegesser [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] G, the attachment got stripped from my last message. Here's the diff inline: Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.12 diff -u -r1.12 jk_connect.c --- jk_connect.c 29 Aug 2003 13:07:52 - 1.12 +++ jk_connect.c 29 Aug 2003 21:37:12 - @@ -101,6 +101,9 @@ #include apr_general.h #endif +#if defined(WIN32) +typedef u_long in_addr_t; +#endif /** resolve the host IP */ int jk_resolve(char *host, -- Marc -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 4:41 PM To: Tomcat Developers List Subject: RE: [j-t-c] Thread problem in jk_uri_worker_map.c The file common/jk_connect.c no longer compiles on Win32 because the in_addr_t type is not defined on that platform. The attached patch fixes the build problem, but there is probably a better way. -- Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:55 AM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c
billbarker2003/08/29 20:11:19 Modified:jk/native/common jk_connect.c Log: Define in_addr_t for Windows platform. Submitted by: Marc Saegesser Revision ChangesPath 1.13 +6 -1 jakarta-tomcat-connectors/jk/native/common/jk_connect.c Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- jk_connect.c 29 Aug 2003 13:07:52 - 1.12 +++ jk_connect.c 30 Aug 2003 03:11:19 - 1.13 @@ -101,6 +101,11 @@ #include apr_general.h #endif +#if defined(WIN32) +typedef u_long in_addr_t; +#endif + + /** resolve the host IP */ int jk_resolve(char *host, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connectorconnector.jsp
The AJP connector still lies, Can you tell me what the discrepancy is in AJP connector? I just followed the doc. All of my Connectors (http, https, ajp) show blanks for the Processors section (even for those that I've explicitly configured in 'server.xml'). What do you mean? There is no longer Processors section. I got rid of maxProcessor and minProcessor from the page since they're deprecated. Instead, admin now shows maxSpareThreads, maxThreads, and minSpareThreads. Thanks for the comments. :-) Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, August 29, 2003 8:36 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp The AJP connector still lies, Can you tell me what the discrepancy is in AJP connector? I just followed the doc. AJP has a separate config method (the $CATALINA_HOME/jk2.properties file) that will override server.xml. However, the Protocol won't report the correct values (due to Costin's design considerations). It's not an admin problem, it's a problem with the AJP Protocol. The patch belongs in the AJP Protocol, so I'll do this one (since Costin is currently AWOL ;-). Looking at the latest, you (or I, if I get the time) can remove the scheme, secure and Enable DNS Lookups rows for the AJP connector. They are all handled by the Apache configuration, and Tomcat ignores them (or, rather, trusts the values that it gets from Apache). It would be good for a future product to allow you to configure an AJP connector from the admin without requiring that you also configure jk2.properties. However, I can wait on this. All of my Connectors (http, https, ajp) show blanks for the Processors section (even for those that I've explicitly configured in 'server.xml'). What do you mean? There is no longer Processors section. I got rid of maxProcessor and minProcessor from the page since they're deprecated. Instead, admin now shows maxSpareThreads, maxThreads, and minSpareThreads. Thanks for the comments. :-) It seems that I co'ed too early. You are correct, and the http(s) Connector values all look good. Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - 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 ApplicationDispatcher.java
remm2003/08/30 01:40:27
Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
Log:
- The request dispatcher should also not log a client abort exception.
Revision ChangesPath
1.24 +10 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ApplicationDispatcher.java7 Aug 2003 00:56:25 - 1.23
+++ ApplicationDispatcher.java30 Aug 2003 08:40:27 - 1.24
@@ -92,6 +92,7 @@
import org.apache.catalina.Request;
import org.apache.catalina.Response;
import org.apache.catalina.Wrapper;
+import org.apache.catalina.connector.ClientAbortException;
import org.apache.catalina.connector.RequestFacade;
import org.apache.catalina.connector.ResponseFacade;
import org.apache.catalina.core.StandardWrapper;
@@ -755,6 +756,11 @@
request.removeAttribute(Globals.JSP_FILE_ATTR);
support.fireInstanceEvent(InstanceEvent.AFTER_DISPATCH_EVENT,
servlet, request, response);
+} catch (ClientAbortException e) {
+request.removeAttribute(Globals.JSP_FILE_ATTR);
+support.fireInstanceEvent(InstanceEvent.AFTER_DISPATCH_EVENT,
+ servlet, request, response);
+ioException = e;
} catch (IOException e) {
request.removeAttribute(Globals.JSP_FILE_ATTR);
support.fireInstanceEvent(InstanceEvent.AFTER_DISPATCH_EVENT,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: removing log() from error processing in StandardWrapperValve.java??
Tim Funk wrote: In the use case of a servlet or filter throwing an ServletException, StandardWrapperValve will log the exception to its logger. If the error is an expected one (such as session timeout or browser compatibility check) and there is a configured error-page directive to handle the exception, StandardWrapperValve stills logs the message. This causes many useless stack traces in the logs for error handling that is already caught. Does it make sense to remove the log() statement? The the job of logging the exception belongs to either ErrorReportValve(?) or the user defined error handler? Just to be clear, this is only the log() in the catch (ServletException e) code that I wish to remove. Or I can my developer rewrite his code to use error handling for real errors. Advice? It's a bit more complex than that. (ex: with the request dispatcher, which also logs everything) Since this is an uncaught exception, I would log it, personally. An IOException which occurs on a socket operation should now be ignored, however. That was the biggest offender. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.h jk_uri_worker_map.c
-Original Message- From: [EMAIL PROTECTED] Log: iSeries C compiler didn't like cast between const and non const. IMO the function prototype should stay const char* or modified to char** if the pointer needs to be changed, but since it isn't it should stay const char *. The problem is later in the code where the function param is assigned with local char * (uri = clean_uri;), and that is what should be changed, not the function call itself. Further more all the functions protos should be changed to const char *, that are now char *. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2003/08/30 03:35:50
Modified:.build.xml
Log:
- Copy additional, optional, jmx tools binaries (jmx remote has two additional
JARs).
Revision ChangesPath
1.153 +4 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.152
retrieving revision 1.153
diff -u -r1.152 -r1.153
--- build.xml 26 Aug 2003 08:42:38 - 1.152
+++ build.xml 30 Aug 2003 10:35:49 - 1.153
@@ -137,6 +137,10 @@
copy tofile=${tomcat.build}/common/lib/jmx.jar file=${jmx.jar} /
copy tofile=${tomcat.build}/common/lib/jmx-tools.jar
file=${jmx-tools.jar} /
+copy tofile=${tomcat.build}/common/lib/jmx-tools2.jar
+file=${jmx-tools2.jar} failonerror=false /
+copy tofile=${tomcat.build}/common/lib/jmx-tools3.jar
+file=${jmx-tools3.jar} failonerror=false /
copy todir=${tomcat.build}/server/lib file=${commons-logging.jar} /
copy todir=${tomcat.build}/server/lib file=${commons-modeler.jar} /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina build.xml
remm2003/08/30 06:19:40
Modified:catalina build.xml
Log:
- Remove license text.
Revision ChangesPath
1.55 +0 -1 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- build.xml 10 Aug 2003 09:59:15 - 1.54
+++ build.xml 30 Aug 2003 13:19:40 - 1.55
@@ -503,7 +503,6 @@
/target
target name=copy-jmx.jar if=copy.jmx.jar
copy tofile=${catalina.build}/common/lib/jmx.jar file=${jmx.jar}/
-copy todir=${catalina.build}/common/lib file=../etc/mx4j.license/
/target
target name=copy-launcher.jars if=copy.launcher.jars
copy todir=${catalina.build}/common/lib file=${ant.jar}/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Amy Paige-Hoien is out of the office.
I will be out of the office starting 08/28/2003 and will not return until 09/04/2003. I will respond to your message on Sept. 4th when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22833] New: - Generated SMAP looks wrong
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22833.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22833
Generated SMAP looks wrong
Summary: Generated SMAP looks wrong
Product: Tomcat 5
Version: 5.0.9
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In some cases the genereted SMAP seems wrong. If one looks at the JSR-45 and
compare it with the example below the SMAP seems wrong.
The Example is the same as in JSR-45.
File: Hello.jsp
HTML
HEAD
TITLEHello Example/TITLE
/HEAD
BODY
%@ include file=greeting.jsp %
/BODY
/HTML
File 2: greeting.jsp
Hello There!P
Goodbye on %= new java.util.Date() %
The output SMAP becomes:
Hello_jsp.java
JSP
*S JSP
*F
+ 0 /Hello.jsp
Hello.jsp
+ 1 /greeting.jsp
greeting.jsp
*L
1,2:45
3:47,2
4,2:49
1#1:51,2
2:52,2 = seems wrong.. Should't it be 2#1:52,2
6#0,3:54
*E
In all examples in JSR-45 they always use the file-id in the line info,
shouldn't Jasper do the same? Like the following
1#0,2:45
3#0:47,2
4#0,2:49
1#1:51,2
2#1:52,2
6#0,3:54
It also looks like SMAP for JSP-declarations does not work. If I add a
%!
void test() {
System.out.print(Hello there..);
}
%
first to Hello.jsp. The first SMAP-line mapping the declaration becomes 2,4:1
when should be 2,4:9 looking at the generated jsp.
First example of generated JSP:
package org.apache.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
public final class Hello_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {
private static java.util.Vector _jspx_dependants;
static {
_jspx_dependants = new java.util.Vector(1);
_jspx_dependants.add(/greeting.jsp);
}
public java.util.List getDependants() {
return _jspx_dependants;
}
public void _jspService(HttpServletRequest request, HttpServletResponse
response)
throws java.io.IOException, ServletException {
JspFactory _jspxFactory = null;
PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;
try {
_jspxFactory = JspFactory.getDefaultFactory();
response.setContentType(text/html);
pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
out.write(HTML\r\n);
out.write(HEAD\r\n);
out.write(TITLEHello Example);
out.write(/TITLE\r\n);
out.write(/HEAD\r\n);
out.write(BODY\r\n);
out.write(Hello There!);
out.write(P\r\nGoodbye on );
out.write(String.valueOf( new java.util.Date() ));
out.write(\r\n);
out.write(/BODY\r\n);
out.write(/HTML );
} catch (Throwable t) {
if (!(t instanceof javax.servlet.jsp.SkipPageException)){
out = _jspx_out;
if (out != null out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null) pageContext.handlePageException(t);
}
} finally {
if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: removing log() from error processing in StandardWrapperValve.java??
Remy Maucherat wrote: Tim Funk wrote: In the use case of a servlet or filter throwing an ServletException, StandardWrapperValve will log the exception to its logger. If the error is an expected one (such as session timeout or browser compatibility check) and there is a configured error-page directive to handle the exception, StandardWrapperValve stills logs the message. This causes many useless stack traces in the logs for error handling that is already caught. Does it make sense to remove the log() statement? The the job of logging the exception belongs to either ErrorReportValve(?) or the user defined error handler? Just to be clear, this is only the log() in the catch (ServletException e) code that I wish to remove. It's a bit more complex than that. (ex: with the request dispatcher, which also logs everything) Since this is an uncaught exception, I would log it, personally. An IOException which occurs on a socket operation should now be ignored, however. That was the biggest offender. Remy Doh! I thought it wasn't that simple. But the exception is caught (loosely speaking) by the error-page directives as defined in web.xml. It is my preference that it would be the job of the handler as user declared by error-page in web.xml to choose to log the exception. If no erroe-page directive is defined, than the existing logic is OK. But such logic might hurt a lot of users at this point due to not having things logged as they were before. So I'm content to do nothing or wait for a future major release. (like 4.2, or 5.2 if they are ever proposed) -Tim - 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 StandardServer.java
remm2003/08/30 11:19:39
Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
Log:
- Don't print the className if it's one of the standard implementations.
- Add some fields to the exception list.
Revision ChangesPath
1.20 +37 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java
Index: StandardServer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- StandardServer.java 29 Aug 2003 21:21:29 - 1.19
+++ StandardServer.java 30 Aug 2003 18:19:38 - 1.20
@@ -160,14 +160,20 @@
* be persisted because they are automatically calculated.
*/
private static String exceptions[][] = {
+{ org.apache.catalina.core.StandardEngine, domain },
+{ org.apache.catalina.core.StandardHost, domain },
{ org.apache.catalina.core.StandardContext, available },
{ org.apache.catalina.core.StandardContext, configured },
{ org.apache.catalina.core.StandardContext, distributable },
+{ org.apache.catalina.core.StandardContext, domain },
+{ org.apache.catalina.core.StandardContext, engineName },
{ org.apache.catalina.core.StandardContext, name },
{ org.apache.catalina.core.StandardContext, override },
{ org.apache.catalina.core.StandardContext, publicId },
{ org.apache.catalina.core.StandardContext, replaceWelcomeFiles },
{ org.apache.catalina.core.StandardContext, sessionTimeout },
+{ org.apache.catalina.core.StandardContext, startupTime },
+{ org.apache.catalina.core.StandardContext, tldScanTime },
{ org.apache.catalina.core.StandardContext, workDir },
{ org.apache.catalina.session.StandardManager, distributable },
{ org.apache.catalina.session.StandardManager, entropy },
@@ -216,6 +222,20 @@
/**
+ * The set of class names that are the standard implementations of
+ * components, and hence should not be persisted.
+ */
+private static String standardImplementations[] = {
+org.apache.catalina.core.StandardServer,
+org.apache.catalina.core.StandardService,
+org.apache.coyote.tomcat5.CoyoteConnector,
+org.apache.catalina.core.StandardEngine,
+org.apache.catalina.core.StandardHost,
+org.apache.catalina.core.StandardContext
+};
+
+
+/**
* ServerLifecycleListener classname.
*/
private static String SERVER_LISTENER_CLASS_NAME =
@@ -1048,11 +1068,21 @@
private void storeAttributes(PrintWriter writer, boolean include,
Object bean) throws Exception {
+// Render the relevant properties of this bean
+String className = bean.getClass().getName();
+
// Render a className attribute if requested
if (include) {
-writer.print( className=\);
-writer.print(bean.getClass().getName());
-writer.print(\);
+for (int i = 0; i standardImplementations.length; i++) {
+if (className.equals(standardImplementations[i])) {
+include = false;
+}
+}
+if (include) {
+writer.print( className=\);
+writer.print(bean.getClass().getName());
+writer.print(\);
+}
}
// Acquire the list of properties for this bean
@@ -1062,8 +1092,6 @@
descriptors = new PropertyDescriptor[0];
}
-// Render the relevant properties of this bean
-String className = bean.getClass().getName();
// Create blank instance
Object bean2 = bean.getClass().newInstance();
for (int i = 0; i descriptors.length; i++) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.h jk_uri_worker_map.c
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Saturday, August 30, 2003 2:46 AM Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.h jk_uri_worker_map.c -Original Message- From: [EMAIL PROTECTED] Log: iSeries C compiler didn't like cast between const and non const. IMO the function prototype should stay const char* or modified to char** if the pointer needs to be changed, but since it isn't it should stay const char *. The problem is later in the code where the function param is assigned with local char * (uri = clean_uri;), and that is what should be changed, not the function call itself. Further more all the functions protos should be changed to const char *, that are now char *. This one is a special case, due to the fact that in mod_jk, the jk_pools aren't thread-safe. Adding a sync to the jk_pool just for this function doesn't make a lot of sense, so (as discussed on the list) it was decided to change this function from const char * to char *, and handle the duplicating logic in the server-specific code. Henri was just cleaning up a file I forgot to change. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [j-t-c] Thread problem in jk_uri_worker_map.c
Thanks. I think I already do have karma for j-t-c. I've been away from the Jakarta projects for a long time, however, and I haven't been able to keep up with what all the details of what's going on. I didn't feel comfortable coming back out of nowhere and checking in code right away since I know that you are trying to get a release out. -- Marc -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 10:16 PM To: [EMAIL PROTECTED] Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c I'll put this one in in the interest of time, but Marc should be given karma (like any other Tomcat committer) to j-t-c, if he doesn't have it already. Marc Saegesser [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] G, the attachment got stripped from my last message. Here's the diff inline: Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.12 diff -u -r1.12 jk_connect.c --- jk_connect.c 29 Aug 2003 13:07:52 - 1.12 +++ jk_connect.c 29 Aug 2003 21:37:12 - @@ -101,6 +101,9 @@ #include apr_general.h #endif +#if defined(WIN32) +typedef u_long in_addr_t; +#endif /** resolve the host IP */ int jk_resolve(char *host, -- Marc -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 4:41 PM To: Tomcat Developers List Subject: RE: [j-t-c] Thread problem in jk_uri_worker_map.c The file common/jk_connect.c no longer compiles on Win32 because the in_addr_t type is not defined on that platform. The attached patch fixes the build problem, but there is probably a better way. -- Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:55 AM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/ROOT index.jsp
remm2003/08/30 13:00:02 Modified:webapps/ROOT index.jsp Log: - Update links to the lists. - Add a link to the open bugs. Revision ChangesPath 1.12 +3 -2 jakarta-tomcat-catalina/webapps/ROOT/index.jsp Index: index.jsp === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/ROOT/index.jsp,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- index.jsp 20 Aug 2003 09:47:00 - 1.11 +++ index.jsp 30 Aug 2003 20:00:02 - 1.12 @@ -99,8 +99,9 @@ td bgcolor=#FFDC75 bordercolor=#00 nowrap a href=http://jakarta.apache.org/tomcat/;Home Page/abr a href=http://jakarta.apache.org/tomcat/bugreport.html;Bug Database/abr -a href=http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/;Users Mailing List/abr -a href=http://www.mail-archive.com/tomcat-dev%40jakarta.apache.org/;Developers Mailing List/abr +a href=http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=REOPENEDamp;bug_status=RESOLVEDamp;resolution=LATERamp;resolution=REMINDamp;resolution=---amp;email1=amp;emailtype1=substringamp;emailassigned_to1=1amp;email2=amp;emailtype2=substringamp;emailreporter2=1amp;bugidtype=includeamp;bug_id=amp;changedin=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;product=Tomcat+5amp;short_desc=amp;short_desc_type=allwordssubstramp;long_desc=amp;long_desc_type=allwordssubstramp;bug_file_loc=amp;bug_file_loc_type=allwordssubstramp;keywords=amp;keywords_type=anywordsamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=amp;cmdtype=doitamp;order=%27Importance%27;Open Bugs/abr +a href=http://nagoya.apache.org/eyebrowse/SummarizeList?listId=88;Users Mailing List/abr +a href=http://nagoya.apache.org/eyebrowse/SummarizeList?listId=46;Developers Mailing List/abr a href=irc://irc.freenode.net/#tomcatIRC/abr nbsp; /td - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 RELEASE-NOTES
remm2003/08/30 14:03:51 Modified:.RELEASE-NOTES Log: - Update release notes. Revision ChangesPath 1.6 +9 -27 jakarta-tomcat-5/RELEASE-NOTES Index: RELEASE-NOTES === RCS file: /home/cvs/jakarta-tomcat-5/RELEASE-NOTES,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- RELEASE-NOTES 25 Aug 2003 18:43:44 - 1.5 +++ RELEASE-NOTES 30 Aug 2003 21:03:50 - 1.6 @@ -21,9 +21,7 @@ * Security manager URLs * Symlinking static resources * Enabling invoker servlet -* Container provided authentication -* Administration web application -* Deployment descriptors validation +* Privileged web applications and log4j * When all else fails @@ -205,31 +203,15 @@ is unsupported. -- -Container provided authentication: -- - -Support for the Servlet API PFD 3 specification may not be complete yet for -security constraint matching. This will be resolved in a future Tomcat beta -release. - - --- -Administration web application: --- - -Due to changes in the configuration file format, the administration web -application does not support editing hosts or connectors. This will be -resolved in a future Tomcat beta release. - +- +Privileged web applications and log4j: +- -- -Deployment descriptors validation: -- +Apache log4j, or other logging systems, cannot be used inside privileged web +applications, due to classloading problems caused by commons-logging. -Validation of Servlet 2.4 and JSP 2.0 deployment descriptors (using XML -schema for validation) does not properly work at this time. The cause of this -problem is investigated. +Note that privileged contexts are only useful to write web application which +extend the container functionality. --- - 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 SmapStratum.java
ecarmich2003/08/30 14:51:50
Modified:jasper2/src/share/org/apache/jasper/compiler
SmapStratum.java
Log:
Remove tabs
Revision ChangesPath
1.9 +159 -149
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapStratum.java
Index: SmapStratum.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapStratum.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SmapStratum.java 12 Aug 2003 16:19:52 - 1.8
+++ SmapStratum.java 30 Aug 2003 21:51:50 - 1.9
@@ -53,7 +53,7 @@
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
- */
+ */
package org.apache.jasper.compiler;
@@ -77,76 +77,78 @@
* a particular stratum.
*/
public static class LineInfo {
- private int inputStartLine = -1;
- private int outputStartLine = -1;
- private int lineFileID = 0;
- private int inputLineCount = 1;
- private int outputLineIncrement = 1;
- private boolean lineFileIDSet = false;
-
- /** Sets InputStartLine. */
- public void setInputStartLine(int inputStartLine) {
- if (inputStartLine 0)
- throw new IllegalArgumentException( + inputStartLine);
- this.inputStartLine = inputStartLine;
- }
-
- /** Sets OutputStartLine. */
- public void setOutputStartLine(int outputStartLine) {
- if (outputStartLine 0)
- throw new IllegalArgumentException( + outputStartLine);
- this.outputStartLine = outputStartLine;
- }
-
- /**
- * Sets lineFileID. Should be called only when different from
- * that of prior LineInfo object (in any given context) or 0
- * if the current LineInfo has no (logical) predecessor.
- * ttLineInfo/tt will print this file number no matter what.
- */
- public void setLineFileID(int lineFileID) {
- if (lineFileID 0)
- throw new IllegalArgumentException( + lineFileID);
- this.lineFileID = lineFileID;
- this.lineFileIDSet = true;
- }
-
- /** Sets InputLineCount. */
- public void setInputLineCount(int inputLineCount) {
- if (inputLineCount 0)
- throw new IllegalArgumentException( + inputLineCount);
- this.inputLineCount = inputLineCount;
- }
-
- /** Sets OutputLineIncrement. */
- public void setOutputLineIncrement(int outputLineIncrement) {
- if (outputLineIncrement 0)
- throw new IllegalArgumentException( + outputLineIncrement);
- this.outputLineIncrement = outputLineIncrement;
- }
+private int inputStartLine = -1;
+private int outputStartLine = -1;
+private int lineFileID = 0;
+private int inputLineCount = 1;
+private int outputLineIncrement = 1;
+private boolean lineFileIDSet = false;
+
+/** Sets InputStartLine. */
+public void setInputStartLine(int inputStartLine) {
+if (inputStartLine 0)
+throw new IllegalArgumentException( + inputStartLine);
+this.inputStartLine = inputStartLine;
+}
+
+/** Sets OutputStartLine. */
+public void setOutputStartLine(int outputStartLine) {
+if (outputStartLine 0)
+throw new IllegalArgumentException( + outputStartLine);
+this.outputStartLine = outputStartLine;
+}
+
+/**
+ * Sets lineFileID. Should be called only when different from
+ * that of prior LineInfo object (in any given context) or 0
+ * if the current LineInfo has no (logical) predecessor.
+ * ttLineInfo/tt will print this file number no matter what.
+ */
+public void setLineFileID(int lineFileID) {
+if (lineFileID 0)
+throw new IllegalArgumentException( + lineFileID);
+this.lineFileID = lineFileID;
+this.lineFileIDSet = true;
+}
+
+/** Sets InputLineCount. */
+public void setInputLineCount(int inputLineCount) {
+if (inputLineCount 0)
+throw new IllegalArgumentException( + inputLineCount);
+this.inputLineCount = inputLineCount;
+}
+
+/** Sets OutputLineIncrement. */
+public void setOutputLineIncrement(int outputLineIncrement) {
+if (outputLineIncrement 0)
+throw new IllegalArgumentException( + outputLineIncrement);
+this.outputLineIncrement = outputLineIncrement;
+}
/**
* Retrieves the current
cvs commit: jakarta-tomcat-5 build.xml
remm2003/08/30 15:13:27
Modified:.build.xml
Log:
- Rename the JMX related properties.
Revision ChangesPath
1.154 +5 -5 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.153
retrieving revision 1.154
diff -u -r1.153 -r1.154
--- build.xml 30 Aug 2003 10:35:49 - 1.153
+++ build.xml 30 Aug 2003 22:13:27 - 1.154
@@ -136,11 +136,11 @@
file=${commons-logging-api.jar} /
copy tofile=${tomcat.build}/common/lib/jmx.jar file=${jmx.jar} /
copy tofile=${tomcat.build}/common/lib/jmx-tools.jar
-file=${jmx-tools.jar} /
-copy tofile=${tomcat.build}/common/lib/jmx-tools2.jar
-file=${jmx-tools2.jar} failonerror=false /
-copy tofile=${tomcat.build}/common/lib/jmx-tools3.jar
-file=${jmx-tools3.jar} failonerror=false /
+file=${jmx-tools.jar} failonerror=false /
+copy tofile=${tomcat.build}/common/lib/jmx-remote.jar
+file=${jmx-remote.jar} failonerror=false /
+copy tofile=${tomcat.build}/common/lib/jmx-remote-tools.jar
+file=${jmx-remote-tools.jar} failonerror=false /
copy todir=${tomcat.build}/server/lib file=${commons-logging.jar} /
copy todir=${tomcat.build}/server/lib file=${commons-modeler.jar} /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
