DO NOT REPLY [Bug 41217] - SingleSignOn Cookie does not honor https access: Login Information Disclosure
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=41217. 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=41217 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 02:03 --- Thanks for the fix - I believe I did not see the Request method because I had no IDE environment ready for tomcat source and just browsed through the source in a simple text editor - it's a lot easier to miss methods there. Olaf -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] New: - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 Summary: JkOptions +ForwardDirectories with Apache's DirectoryIndex Product: Tomcat 5 Version: 5.5.0 Platform: PC OS/Version: Linux Status: NEW Severity: regression Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In apache-2.0.58 + apr-0.9.12 + mod_jk-1.1.20 + JBoss-4.0.5.GA (Tomcat 5.5), when a Tomcat webapp is published through an apache vhost and: - both JkOptions +ForwardDirectories and DirectoryIndex are specified; - Apache can't stat() the specified index file, since it is expected to be handled virtually by Tomcat (i.e.: it is index.jsf like in Java ServletFaces applications); then issuing a request on a directory entry to Apache (like, in example, http://www.domain.tld/) would not redirect the client to request the DirectoryIndex-specified resource (i.e. http://www.domain.tld/index.jsf) but would instead forward it up to Tomcat as-is. This results in displaing the directory content (or a 404 error), instead of the wanted index virtual file. Please note that up to mod_jk-1.1.19 the behaviour I was seing was the expected one: the client was redirected to request the virtual index resource regardless of the existance of such a file in the directory published by Apache. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41431] New: - Impact of the fore coming DST 2007
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=41431. 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=41431 Summary: Impact of the fore coming DST 2007 Product: Tomcat 3 Version: 3.2.x Nightly Platform: Sun OS/Version: SunOS Status: NEW Severity: major Priority: P2 Component: Webapps AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Impact of the fore coming Daylight Saving Time 2007, on the tomcat servers.There is a Daylight Saving fix for Java, like that any fixes available for tomcat. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41432] New: - Webdav servlet does not work correctly with Windows XP webdav redirector.
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=41432. 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=41432 Summary: Webdav servlet does not work correctly with Windows XP webdav redirector. Product: Tomcat 5 Version: 5.0.20 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Servlets:WebDAV AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat webdav servlet works fine with Office applications, that is, running WINWORD.EXE http://server/file.doc . However, if one enters file://server/directory in the Windows explorer, it does not work with Tomcat. The same test works successfully with Apache WebDAV server. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41431] - Impact of the fore coming DST 2007
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=41431. 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=41431 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 04:12 --- There is no impact on Tomcat. This is an OS / JVM issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 04:14 --- This might be related to the fix for bug 36121. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 04:30 --- How can I get that single patch? I would attempt rolling it back in my mod_jk- 1.1.20 and test if this is the cause, but it is not attached to http://issues.apache.org/bugzilla/show_bug.cgi?id=36121. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r498053 - in /tomcat/container/tc5.5.x/catalina: build.xml src/share/org/apache/catalina/core/StandardWrapper.java
Does this introduces a new dependency on the jsp-api - which could be a regression for people who embed tomcat without using jsp's. Also the checking is not that aggressive any more in the case of nested exceptions. This may leave the root cause still unexposed. This patch seems better: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java?r1=466608r2=496117diff_format=h -Tim [EMAIL PROTECTED] wrote: Author: markt Date: Fri Jan 19 19:07:36 2007 New Revision: 498053 URL: http://svn.apache.org/viewvc?view=revrev=498053 Log: Put the fix back for 39088 now the build is fixed. Sorry for the noise. Modified: tomcat/container/tc5.5.x/catalina/build.xml tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Congratulations to tomcat developers for the Comet API
There is now a standart way to break the one thread per connection limit, due to the current servlet specification, in tomcat. It took me less than 2 days (and 2 nights ;-) to update my product to make use of the Comet API (using 6.0.7 beta) while retaining previous behaviour for compatibility with other application servers and previous versions of tomcat. Yes, you can turn Tomcat into a scalable SSL VPN for mobile devices ... Comet is a really nice API since: - it allows to keep compatibility with non-comet servlet containers without modifying deployment descriptors. - it is simple. - its implementation works well. I only had to port the patches for http://issues.apache.org/bugzilla/show_bug.cgi?id=40960 and http://issues.apache.org/bugzilla/show_bug.cgi?id=37869 to version 6.0.7 and basic tests passed for my product in APR mode with Comet servlet. If you are interested by the v607 patches, I can provide them. Feedback on the Comet API: - There may be some ways to improve the documentation of the API: from what I saw (I got caught by this one :-), it seems that one need to call CometEvent.close() before throwing an exception in READ events or the event keeps coming back forever. I could not find a reference to this behaviour in documentation. - Is there a rationale for receiving READ events when request.getInputStream().available()==0 ? I will do some scalability/load testing on my product and I will be able to compare Comet-version versus previous version... Keep on the good work ! Christophe Pierret
Re: svn commit: r498053 - in /tomcat/container/tc5.5.x/catalina: build.xml src/share/org/apache/catalina/core/StandardWrapper.java
did you really wanna add in the JSP-API dependency?
Filip
[EMAIL PROTECTED] wrote:
Author: markt
Date: Fri Jan 19 19:07:36 2007
New Revision: 498053
URL: http://svn.apache.org/viewvc?view=revrev=498053
Log:
Put the fix back for 39088 now the build is fixed. Sorry for the noise.
Modified:
tomcat/container/tc5.5.x/catalina/build.xml
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Modified: tomcat/container/tc5.5.x/catalina/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/build.xml?view=diffrev=498053r1=498052r2=498053
==
--- tomcat/container/tc5.5.x/catalina/build.xml (original)
+++ tomcat/container/tc5.5.x/catalina/build.xml Fri Jan 19 19:07:36 2007
@@ -30,6 +30,7 @@
!-- Dependent JARs and files --
property name=ant.jar value=${ant.home}/lib/ant.jar/
property name=servlet-api.jar
value=${api.home}/jsr154/dist/lib/servlet-api.jar/
+ property name=jsp-api.jar
value=${api.home}/jsr152/dist/lib/jsp-api.jar/
property name=tomcat-util.jar
value=${tomcat-util.home}/build/lib/tomcat-util.jar/
property name=tomcat-coyote.jar
@@ -72,6 +73,7 @@
pathelement location=${mail.jar}/
pathelement location=${regexp.jar}/
pathelement location=${servlet-api.jar}/
+pathelement location=${jsp-api.jar}/
pathelement location=${xercesImpl.jar}/
pathelement location=${xml-apis.jar}/
pathelement location=${classes.dir}/
@@ -101,6 +103,7 @@
pathelement location=${mail.jar}/
pathelement location=${regexp.jar}/
pathelement location=${servlet-api.jar}/
+pathelement location=${jsp-api.jar}/
pathelement location=${xercesImpl.jar}/
pathelement location=${xml-apis.jar}/
pathelement location=${classes.dir}/
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java?view=diffrev=498053r1=498052r2=498053
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Fri Jan 19 19:07:36 2007
@@ -28,6 +28,8 @@
import java.security.AccessController;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
+import java.sql.SQLException;
+
import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
@@ -36,6 +38,7 @@
import javax.servlet.ServletResponse;
import javax.servlet.SingleThreadModel;
import javax.servlet.UnavailableException;
+import javax.servlet.jsp.JspException;
import javax.management.ListenerNotFoundException;
import javax.management.MBeanNotificationInfo;
import javax.management.Notification;
@@ -56,7 +59,6 @@
import org.apache.catalina.security.SecurityUtil;
import org.apache.catalina.util.Enumerator;
import org.apache.catalina.util.InstanceSupport;
-import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.log.SystemLogHandler;
import org.apache.commons.modeler.Registry;
@@ -632,23 +634,33 @@
* @param e The servlet exception
*/
public static Throwable getRootCause(ServletException e) {
-Throwable rootCause = e;
-Throwable rootCauseCheck = null;
-// Extra aggressive rootCause finding
-do {
-try {
-rootCauseCheck = (Throwable)IntrospectionUtils.getProperty
-(rootCause, rootCause);
-if (rootCause == rootCauseCheck)
-rootCauseCheck = null;
-else if (rootCauseCheck != null)
-rootCause = rootCauseCheck;
+Throwable rootCause = e.getRootCause();
+return findRootCause(e, rootCause);
+}
-} catch (ClassCastException ex) {
-rootCauseCheck = null;
-}
-} while (rootCauseCheck != null);
-return rootCause;
+/*
+ * Work through the root causes using specific methods for well known types
+ * and getCause() for the rest. Stop when the next rootCause is null or
+ * an exception is found that has itself as its own rootCause.
+ */
+private static final Throwable findRootCause(Throwable theException,
+Throwable theRootCause) {
+
+Throwable deeperRootCause = null;
+
+if (theRootCause == null || theRootCause == theException) {
+deeperRootCause = theException;
+} else if (theRootCause instanceof ServletException) {
+deeperRootCause = ((ServletException) theRootCause).getRootCause();
+} else if (theRootCause instanceof JspException)
Re: Congratulations to tomcat developers for the Comet API
Christophe Pierret wrote: I only had to port the patches for http://issues.apache.org/bugzilla/show_bug.cgi?id=40960 and http://issues.apache.org/bugzilla/show_bug.cgi?id=37869 These two patches have been merged in HEAD. Feedback on the Comet API: - There may be some ways to improve the documentation of the API: from what I saw (I got caught by this one :-), it seems that one need to call CometEvent.close() before throwing an exception in READ events or the event keeps coming back forever. I could not find a reference to this behaviour in documentation. Throw an exception like what ? If an exception is thrown by something in the event method, it should close the connection with an error without further problems (CoyoteAdapter.event will return false to the connector's event method, which does return a code asking for closing the socket - and more importantly, doesn't put it back in the poller). CometEvent.close() doesn't do much, so I don't understand how it can cause a different behavior. - Is there a rationale for receiving READ events when request.getInputStream().available()==0 ? There's a reason: the actual read will be done on the socket when you read on the Java input stream, so it's normal to have available == 0. The event guarantees that the blocking read will not block. Filip suggested having the read done before calling event, but I thought it added complexity. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r498793 - /tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Validator.java
Author: remm
Date: Mon Jan 22 12:49:02 2007
New Revision: 498793
URL: http://svn.apache.org/viewvc?view=revrev=498793
Log:
- isELEnabled may return true for a variety of reasons, so the actual value
should be checked.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Validator.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Validator.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Validator.java?view=diffrev=498793r1=498792r2=498793
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Validator.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Validator.java Mon Jan
22 12:49:02 2007
@@ -1051,7 +1051,8 @@
}
}
-boolean expression = runtimeExpression || (elExpression
!pageInfo.isELIgnored());
+boolean expression = runtimeExpression
+|| (elExpression (!pageInfo.isELIgnored() ||
(!true.equalsIgnoreCase(pageInfo.getIsELIgnored()) checkDeferred
deferred)));
for (int j = 0; tldAttrs != null j tldAttrs.length; j++) {
if (attrs.getLocalName(i).equals(tldAttrs[j].getName())
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 13:48 --- The original patch was: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diffr1=478743r2=478744pathrev=478744 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 13:49 --- Did you add index.jsf to the list of welcome pages in youe web.xml on the tomcat side? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 14:01 --- Yes, but it doesn't work: I can't get the auto-index working. It doesn't work even by connecting to the Tomcat's default http service port (8080), thereby by-passing the JK Connector. Please note I'm using jsf + facelets + seam + jboss, so, probably one of these components doesn't behave as expected with welcome-file-list. The fact is that I found a great solution to this in mod_jk and I'm actually depending on this. I could eventually backup implementing a filter, but this would at least mean that something is wrong in the JK docs regarding +ForwardDirectories + DirectoryIndex. About your patch. I just got back home and I'm going to roll it back from my copy of mod_jk-1.1.20. I'll tell you soon. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 14:27 --- Your might be is definitely right, Mark: that single-line change does matter... Reversing the patch to 1.1.20 restores mod_jk's previous behaviour. I don't completely get the matter of bug 36121. Do you think the two behaviours may be made somehow compatible in 1.1.21, or instead enforcing one would mean voiding the other? I would like to be prepared to the next mod_jk release... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5 SSL Configuration Documentation Errors
Here are some misc. doc errors for the Tomcat 5.5 SSL topic I noticed: The Connector configuration XML snippet has a semi-colon after secure=true. The Connector configuration XML snippet references minProcessors and maxProcessors. These parameters do not seem to be current parameters for the HTTP connector. They appear to have been deprecated for the AJP connector. It appears they are replaced with minSpareThreads and maxThreads would be the closest matches. debug= is referenced, but not documented in the standard Connector reference. The attribute for disableUploadTimeout is the default. Since it's the default, it's kind of redundant. This also applies to clientAuth, and sslProtocol. So, the corrected example would be: -- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -- !-- Connector port=8443 enableLookups=true maxThreads=75 acceptCount=100 scheme=https secure=true/ -- -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 16:02 --- http://marc.theaimsgroup.com/?l=tomcat-devm=116433303512441w=2 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41437] New: - The log API used and the log message is not corresponding.
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=41437. 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=41437 Summary: The log API used and the log message is not corresponding. Product: Tomcat 5 Version: 5.5.20 Platform: PC OS/Version: Windows XP Status: NEW Severity: trivial Priority: P4 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The message level is double but not same. In org.apache.catalina.startup.LocalStrings.properties. --- contextConfig.role.auth=WARNING: Security role name ... contextConfig.role.link=WARNING: Security role name ... contextConfig.role.runas=WARNING: Security role name ... --- In org.apache.catalina.startup.ContextConfig#validateSecurityRoles() --- log.info(sm.getString(contextConfig.role.auth, roles[j])); log.info(sm.getString(contextConfig.role.runas, runAs)); log.info(sm.getString(contextConfig.role.link, link)); --- I think it should be the following. ---LocalStrings.properties contextConfig.role.auth=Security role name ... contextConfig.role.link=Security role name ... contextConfig.role.runas=Security role name ... ---ContextConfig#validateSecurityRoles() log.warn(sm.getString(contextConfig.role.auth, roles[j])); log.warn(sm.getString(contextConfig.role.runas, runAs)); log.warn(sm.getString(contextConfig.role.link, link)); --- Regards, Yuichiro -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-01-22 16:41 --- Both behaviours are valid use cases. It should be possible to get mod_jk to handle both correctly but it might take someone with more mod_jk expertise than I to do it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r498053 - in /tomcat/container/tc5.5.x/catalina: build.xml src/share/org/apache/catalina/core/StandardWrapper.java
Tim Funk wrote: Does this introduces a new dependency on the jsp-api - which could be a regression for people who embed tomcat without using jsp's. Yes, it does add an additional dependency. I didn't consider the embedded use case. Also the checking is not that aggressive any more in the case of nested exceptions. This may leave the root cause still unexposed. My bad. I missed the recursion part of the patch. This patch seems better: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java?r1=466608r2=496117diff_format=h This issue that the OP raised with this patch is the unintended consequences of using introspection. To summarise: - the root cause could be a custom exception - this custom exception may have a getRootCause() method - since this method is not defined anywhere, it could do anything - therefore, calling getRootCause() on a random exception is dangerous The ErrorReportValve also only uses getRootCause() and ignores possibilities offered by getCause() I'll take another look at this with the following intentions: - removing the jsp-api dependency (probably a slightly ugly hack) - add the recursion part of the patch - continue to avoid using introspection to call getRootCause() Thoughts? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r498053 - in /tomcat/container/tc5.5.x/catalina: build.xml src/share/org/apache/catalina/core/StandardWrapper.java
I guess one could do this:
Create instance variable called JspException which is initialized to
protected jspExceptionClazz =
Class.forName(javax.servlet.jsp.JspException);
Then findRootCause could be this (missing the exception checking) - in
this version theRootCause is unneeded but can be kept for binary compat.
Sorry for the line wraps
private static final Throwable findRootCause(Throwable theException,
Throwable theRootCause) {
while (theException!=null) {
Throwable deeperRootCause = null;
if (theException == theException) {
return theException;
} else if (theException instanceof ServletException) {
deeperRootCause = ((ServletException) theException).getRootCause();
} else if (jspExceptionClazz!=null
jspExceptionClazz.isAssignableFrom(theException)) {
deeperRootCause =
(Throwable)IntrospectionUtils.getProperty(rootCause, rootCause);
}
if (deeperRootCause==null) {
return theException;
}
if (theException == deeperRootCause) {
return theException;
}
theException = deeperRootCause;
}
// In case theException was null in the first place
return theException;
}
-Tim
Mark Thomas wrote:
Tim Funk wrote:
Does this introduces a new dependency on the jsp-api - which could be a
regression for people who embed tomcat without using jsp's.
Yes, it does add an additional dependency. I didn't consider the
embedded use case.
Also the checking is not that aggressive any more in the case of nested
exceptions. This may leave the root cause still unexposed.
My bad. I missed the recursion part of the patch.
This patch seems better:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java?r1=466608r2=496117diff_format=h
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41438] New: - jsp:forward kicks in twice instead of once
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=41438. 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=41438 Summary: jsp:forward kicks in twice instead of once Product: Tomcat 5 Version: 5.5.19 Platform: Other OS/Version: Windows XP Status: NEW Severity: critical Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The forwarding page containing the tag jsp:forward page=destination.jsp/ is called TWICE when the destination.jsp contains a blank image tag such as img src= alt=logo/ This happens using the Firefox browser only and works fine(called ONCE) for IE. Below is the page content of the forwarding page % System.out.println(referer--- + request.getHeader(referer)); % jsp:forward page=destination.jsp jsp:param name=contentType value=html/ /jsp:forward Below is the page content of the destination page (note that the image src is blank) html body img src= alt=logo/ % System.out.println(Called); % /body /html Below is the output from the log referer---null Called referer---http://localhost:8080/hostingPanel/forwarder.jsp Called ---Notes If the img src=x alt=logo/ is sourced with any image say x here, the forwarder.jsp is called only once. However in lots of cases x may be dynamically obtained and by chance if it turns out blank the corresponding destination is called twice in the firefox browser. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
