DO NOT REPLY [Bug 15944] - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.
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=15944. 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=15944 Compiled JSP page includes default setContentType() Call when not specified in the JSP page. --- Additional Comments From [EMAIL PROTECTED] 2003-01-10 08:53 --- according to jsp spec 1.2, section 2.10.1: jsp pages always generate a setContentType that defaults to text/html;charset:iso-8859-1. Dynamic setting of content type relies on an underlying invocation on response.setContentType(). That method can be invoked as long as no content has been been sent to the response stream. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15950] New: - automatic assignment of context path leads to http 404 errors for servlets
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=15950. 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=15950 automatic assignment of context path leads to http 404 errors for servlets Summary: automatic assignment of context path leads to http 404 errors for servlets Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In /tomcat-docs/appdev/deployment.html a method is described to deploy a web app, ie: Copy unpacked directory hierarchy into a subdirectory in directory $CATALINA_HOME/webapps/. I'm a total newbie and there may be a way around this but I've spent 2 days trying to figure out why my servlets work when I put them in the examples folder but not when I put them into a folder created as above. It appears that the docbase Tomcat creates this way is an absolute path that is not recognized when trying to run any servlets in /WEB-INF/classes. It just gives HTTP 404 errors saying the requested resource is not available. When I edited server.xml to change docbase=F:\Tomcat\webapps\myProjects to just myProjects everything worked fine. Several folders created by Tomcat, including ROOT and tomcat-docs, also have absolute paths in server.xml and I could not get the servlets to work in these folders either until I changed to relative paths. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14391] - tomcat.exe Fails with an Application Exception (access violation)
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=14391. 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=14391 tomcat.exe Fails with an Application Exception (access violation) --- Additional Comments From [EMAIL PROTECTED] 2003-01-10 09:19 --- For information, I'm observing a similar problem with 4.1.18, Win2k and SP3. Can anyone shed any further light on this? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Fwd: Tomcat manager - Java client]
FYI. ---BeginMessage--- I've written a Java client that talks to the Tomcat servlet manager application. The program allows you to view, stop, start and reload servlet applications and acts as a visual front end to the Tomcat manager. The program isn't complete but is still useful in its current form. I'm wondering if you would have an interest in using or developing the application further. I'm happy to donate the source code. Attached you'll find an executable JAR file that has been tested under Windows (98 and NT). To run, you need to enter the URL of a server (local or remote), then Connect. It will prompt for authentication then display a list of servlet applications. Please let me know if the program is of interest. John Hamilton Teacher, Computing and Information Technology. Swinburne University, Technical and Further Education division. tcman.jar Description: PKZIP (compressed) files ---End Message--- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Calling into Servlet Container without HTTP
Kelly Chen wrote: Hi, there: I am looking for a way to invoke a Servlet without going through HTTP. I understand that this has to be container specific logic, so I would like to do this on Tomcat 4.1.18. The idea is to use JSP as a template system, but JSP has be to run inside a Servlet Container. So I would like to be able to invoke JSP through Tomcat and get result directly without going through HTTP. I just wonder if anyone has attempt the similar task or has some points to share. I don't see that much benefit in avoiding HTTP, as there's a lot of code there already, and the code is fast. What should be avoided are the socket operations, which are expensive. If you take a look at Coyote, you could write a new protocol handler which would read/write HTTP stuff in memory, while reusing the Http11Processor class. Alternately, you can create a brand new protocol handler. That would be the most efficient, and it's not that hard. You can use the JK and HTTP/1.1 handlers as examples (but no, there are no docs right now). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java
remm2003/01/10 02:21:34 Modified:coyote/src/java/org/apache/coyote ActionCode.java Log: - Fix code number. Revision ChangesPath 1.12 +1 -1 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java Index: ActionCode.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- ActionCode.java 4 Dec 2002 23:33:27 - 1.11 +++ ActionCode.java 10 Jan 2003 10:21:34 - 1.12 @@ -134,7 +134,7 @@ * Callback for lazy evaluation - extract the SSL-certificate * (including forcing a re-handshake if necessary) */ -public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(14); +public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(15); // --- Constructors -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
I was unable to reproduce a collision too. I took ManagerBase and
converted it to a standalone java program (by stripping out code) to see
if I might get duplicates. But I keep running out of memory near 1
million sessions.
java Collide 1
Generates 1 ids. (Change the number to change the number of sessions
to create)
In case someone is really bored ...
-Tim
Remy Maucherat wrote:
Schnitzer, Jeff wrote:
I've already patched the 4.1.12 version we are running with the fix that
is currently in CVS. Unfortunately our only notification of when the
problem occurs is when users notice (which they probably wouldn't unless
they acquired an administrative session) and choose to inform us. I
won't know the fix worked without waiting some number of weeks.
You could icrement a variable to list the number of duplicates detected.
The patch should guarantee uniqueness of the ids, and this is supposed
to fix the issue.
One thing to contemplate is that if you have 100,000 sessions and you
get 10 new sessions created every second, that's the equivalent of 1
million inadvertent hack attempts every single second. Granted that's
still small compared to the total size of a truly randomly generated
128-bit number, but I wouldn't run a banking application on it.
In theory, the odds are so small it just cannot happen. I can't
reproduce an id collision so far.
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
import java.io.IOException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Random;
public class Collide {
protected MessageDigest digest = null;
protected String entropy = null;
protected Random random = null;
protected String randomClass = java.security.SecureRandom;
protected static final String DEFAULT_ALGORITHM = MD5;
protected static final int SESSION_ID_BYTES = 16;
protected String algorithm = DEFAULT_ALGORITHM;
/**
* Return the MessageDigest object to be used for calculating
* session identifiers. If none has been created yet, initialize
* one the first time this method is called.
*/
public
Proposal: CanAccessLink(..) test
Its cool having authorisation restrictions enforced when accessing a page but it would also be useful to query these restrictions when choosing to offer a link in other pages. I have an implementation which offers this query capability based on a hack of Tomcat authorisation code. The method signature is: boolean canIAccess(String url, String method, HttpServletRequest currentRequest, ServletContext context) Is this sort of thing worth rolling into Tomcat somewhere? Without such a feature you effectively end up declaring security restrictions twice - once in web.xml declarations and once in pages that choose to offer links to these secured pages. Cheers Mark Harwood -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Duplicate session IDs are *common*
On Thu, 9 Jan 2003, Schnitzer, Jeff wrote: One thing to contemplate is that if you have 100,000 sessions and you get 10 new sessions created every second, that's the equivalent of 1 million inadvertent hack attempts every single second. Granted that's still small compared to the total size of a truly randomly generated 128-bit number, but I wouldn't run a banking application on it. Am I right to understand that what is needed is only: - an unguessible ID ? - which is unique within a certain realm ? If that is the case one can tailor the ID to do exactly that. And, espcially, not a bit more. Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal: CanAccessLink(..) test
Hi Marki, see inline Mark Harwood wrote: Its cool having authorisation restrictions enforced when accessing a page but it would also be useful to query these restrictions when choosing to offer a link in other pages. I have an implementation which offers this query capability based on a hack of Tomcat authorisation code. The method signature is: boolean canIAccess(String url, String method, HttpServletRequest currentRequest, ServletContext context) Is this sort of thing worth rolling into Tomcat somewhere? Without such a feature you effectively end up declaring security restrictions twice - once in web.xml declarations and once in pages that choose to offer links to these secured pages. -1 for portable reason. The security mechanism will not work the same way if I define my web app using Tomcat and then moving it under another Servlet container. Some user may think their application are secure under Tomcat, and then move it to another container (security issue). If you think that every Servlet container should support your method, you can submit your proposal to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] If other tomcat-dev are interested to your proposal, at least make that behaviour optional and turned off by default :-) -- Jeanfrancois Cheers Mark Harwood -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Duplicate session IDs are *common*
Note that you would need 1 million sessions that are active at the same time - if a session expires and the id is reused there is no harm. If I leave my browser open and go for lunch and someone else gets my expired session id, I return and continue browsing, wouldn't that cause problems? Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Here's a follow-up on the bug report I submitted that started this thread. 1) We confirmed the problem is a duplicate session id. Luckily we were logging session id's. It took a lot of hunting through access logs, but we did indeed find two sessions which were started a couple of minutes apart, with a number of intervening sessions, which had duplicate session id's. The pair of sessions corresponded to the user report of seeing someone else's session data. We're using 4.1.12. 2) I don't believe this is *common* The problem hasn't been duplicated in our app, so I'm not sure I'd call this a common problem, but that's a subjective term. 3) I believe this is a serious vulnerability There should probably be some sort of an alert delivered to tomcat users to let them know of this problem. 4) A simple patch is available It is not necessary to use the head version of tomcat to fix the problem. Simply install your own manager class, which subclasses StandardManager, which has the duplicate session id checking implemented. In other words, a simple patch on an existing tomcat installation can fix this. 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. The head revision now includes such a check, so I believe the problem has been solved. Even the weakest of PRNG's would generate a collision only rarely, so I wouldn't worry about improving its strength. - Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15959] New: - Confusing Error Message with jsp:forward
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=15959. 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=15959 Confusing Error Message with jsp:forward Summary: Confusing Error Message with jsp:forward Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a user added an invalid attribute to jsp:param in a jsp:forward tag they got an error org.apache.jasper.JasperException: /fixedData/cpEdit.jsp(21,3) Param action: Invalid attribute, type. The code is below... jsp:forward page=%=CPBean.getReturnTo()% jsp:param name=cpId value= / jsp:param name=cpType value= / jsp:param type=hidden name=appDesc value= / jsp:param type=hidden name=balFacType value= / jsp:param type=hidden name=balFacId value= / /jsp:forward Could it not say jsp:param does not accept attribute 'type'. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15961] New: - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.
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=15961. 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=15961 getBodyContent() is not returning null when the action has only jsp:attribute actions within the body. Summary: getBodyContent() is not returning null when the action has only jsp:attribute actions within the body. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JSP.5.11 states: If one or more jsp:attribute elements appear in the body of a tag invocation but no jsp:body element appears, it is the equivalent of the tag having an empty body Consider the following example using a tag handler that extends BodyTagSupport and implements DynamicAttributes body:cemptybody jsp:attribute name=attr1value1/jsp:attribute jsp:attribute name=attr2value2/jsp:attribute /body:cemptybody The cemptybody action attempts to validate that a call to getBodyContent() returns null. Keep in mind that the javadocs state that setBodyContent() will not be invoked for an empty tag. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Glenn Olander [EMAIL PROTECTED] writes: 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. This doesn't seem to me to be a plausible position in view of the fact that all of our security mechanisms absolutely depend on statistical uniqueness of randomly generated large numbers. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15962] New: - New option to create the package name based on the jsp directory structure
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=15962. 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=15962 New option to create the package name based on the jsp directory structure Summary: New option to create the package name based on the jsp directory structure Product: Tomcat 4 Version: 4.1.12 Platform: PC URL: http://www.mail-archive.com/tomcat- [EMAIL PROTECTED]/msg37375.html OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Excerpted from http://www.mail-archive.com/tomcat- [EMAIL PROTECTED]/msg37375.html I'd like to propose a change to org.apache.jasper.JspC in Tomcat4.1.12. Specifically, I'd like to introduce a new command line argument: -pp to apply a package name prefix and create the package name based on the jsp directory structure. Tomcat4's -p option applies the package name prefix, but creates all the jsps in the same package. This leads to duplicate class problems if two jsps in different directories share the same name. I would also like to see this enhancement made to jspc. Please see the above URL for a complete description of the problem and a proposed solution (source code included). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr154/src/share/dtd jsp_2_0.xsd
kinman 2003/01/10 10:17:03
Modified:jsr152/src/share/dtd jsp_2_0.xsd
jsr152/src/share/javax/servlet/jsp/tagext TagInfo.java
VariableInfo.java
jsr154/src/share/dtd jsp_2_0.xsd
Log:
- Patch by Mark Roth:
Fixes leading up to the second proposed final draft
release of the specification.
jsr152/src/share/dtd/jsp_2_0.xsd
- Updated comments for jsp-property-groupType
jsr154/src/share/dtd/jsp_2_0.xsd
- Updated comments for jsp-property-groupType
jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java
- Fixed typo: 'the the'
jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java
- Fixed typo: 'AT_NESTED' -- 'NESTED'
- Fixed table - AT_BEGIN and NESTED should be synchronized
after doStartTag() if EVAL_BODY_INCLUDE is returned.
Revision ChangesPath
1.6 +4 -4 jakarta-servletapi-5/jsr152/src/share/dtd/jsp_2_0.xsd
Index: jsp_2_0.xsd
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr152/src/share/dtd/jsp_2_0.xsd,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jsp_2_0.xsd 8 Nov 2002 21:30:20 - 1.5
+++ jsp_2_0.xsd 10 Jan 2003 18:17:02 - 1.6
@@ -8,7 +8,7 @@
version=2.0
xsd:annotation
xsd:documentation
-@(#)jsp_2_0.xsds 1.14 11/06/02
+@(#)jsp_2_0.xsds 1.15 01/02/03
/xsd:documentation
/xsd:annotation
@@ -136,10 +136,10 @@
All files so described are deemed to be JSP files. The
following additional properties can be described:
-- Control enabling of EL evaluation.
-- Control enabling of Scripting elements.
+- Control whether EL is ignored
+- Control whether scripting elements are invalid
- Indicate pageEncoding information.
-- Indicating that a resource is a JSP document
+- Indicate that a resource is a JSP document (XML)
- Prelude and Coda automatic includes.
/xsd:documentation
1.5 +1 -1
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java
Index: TagInfo.java
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TagInfo.java 4 Nov 2002 17:44:24 - 1.4
+++ TagInfo.java 10 Jan 2003 18:17:02 - 1.5
@@ -268,7 +268,7 @@
*
* @param data TagData describing this action.
* @return if a TagExtraInfo object is associated with this TagInfo, the
- * the result of getTagExtraInfo().getVariableInfo( data ), otherwise
+ * result of getTagExtraInfo().getVariableInfo( data ), otherwise
* null if the tag has no id attribute or new VariableInfo[] {
* new VariableInfo( data.getId(), java.lang.Object, true,
* VariableInfo.NESTED ) } if an id attribute is present.
1.7 +5 -2
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java
Index: VariableInfo.java
===
RCS file:
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- VariableInfo.java 18 Dec 2002 18:35:37 - 1.6
+++ VariableInfo.java 10 Jan 2003 18:17:02 - 1.7
@@ -193,9 +193,9 @@
* tr
* td valign=top bgcolor=#c0c0c0bBodyTagbr
* /b/td
- * td valign=top align=center bgcolor=#ffbr
+ * td valign=top align=center bgcolor=#ffAT_BEGIN,
NESTEDsup1/supbr
* /td
- * td valign=top align=center bgcolor=#ffAT_BEGIN, AT_NESTEDbr
+ * td valign=top align=center bgcolor=#ffAT_BEGIN,
NESTEDsup1/supbr
* /td
* td valign=top align=center bgcolor=#ffAT_BEGIN, NESTEDbr
* /td
@@ -220,6 +220,9 @@
* /tr
* /tbody
* /table
+ * sup1/sup Called after codedoStartTag()/code if
+ * codeEVAL_BODY_INCLUDE/code is returned, or after
+ * codedoInitBody()/code otherwise.
* /blockquote
*
* pBVariable Information in the TLD/B
1.6 +4 -4 jakarta-servletapi-5/jsr154/src/share/dtd/jsp_2_0.xsd
Index: jsp_2_0.xsd
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr154/src/share/dtd/jsp_2_0.xsd,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jsp_2_0.xsd 8 Nov 2002 21:30:21 - 1.5
+++ jsp_2_0.xsd 10 Jan 2003 18:17:03 - 1.6
@@ -8,7 +8,7 @@
version=2.0
xsd:annotation
xsd:documentation
-@(#)jsp_2_0.xsds 1.14 11/06/02
cvs commit: jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2 jsp2-example-taglib.tld
kinman 2003/01/10 10:21:38 Modified:jsr152/examples/WEB-INF/jsp2 jsp2-example-taglib.tld Log: - Patch by Jan Luehe: jsp-version has always been mandatory, but is only now being enforced. Revision ChangesPath 1.2 +1 -0 jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2/jsp2-example-taglib.tld Index: jsp2-example-taglib.tld === RCS file: /home/cvs/jakarta-servletapi-5/jsr152/examples/WEB-INF/jsp2/jsp2-example-taglib.tld,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jsp2-example-taglib.tld 7 Sep 2002 00:47:59 - 1.1 +++ jsp2-example-taglib.tld 10 Jan 2003 18:21:38 - 1.2 @@ -6,6 +6,7 @@ version=2.0 descriptionA tag library exercising SimpleTag handlers./description tlib-version1.0/tlib-version +jsp-version2.0/jsp-version short-nameSimpleTagLibrary/short-name uri/SimpleTagLibrary/uri tag -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15964] New: - Wrong source paths in generated SMAP file entries
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=15964. 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=15964 Wrong source paths in generated SMAP file entries Summary: Wrong source paths in generated SMAP file entries Product: Tomcat 5 Version: 5.0.0 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] One of the new features of Jasper in Tomcat 5 is that it attaches a Source Map attribute to class files to describe the file name and line number mapping from a JSP source file to the generated Java source file. According to JSR-45, each file entry in the SMAP defines a source name, and optionally, a source path. The SMAP that I see in the class files generated by Jasper doesn't specify a source path. This means that the source path defaults to a subdirectory based on the package of the class file. In other words, for class files generated by Jasper, the source path ends up being org/apache/jsp. This is the source path for both the JSP stratum and the Java stratum. The problem is that this source path is wrong for both strata, given how Jasper stores files. An example would help explain this. Say the user wants to debug the numguess.jsp file that's part of the jsp-examples web application that comes with Tomcat. I've written a debugger that allows the user to enter directory names that the debugger should search for source files. Other debuggers have pretty much the same technique for finding source files. For this discussion, let's call this the debugger's search path. Let's say the entries in the search path are A and B. When a debugger wants to locate a source file corresponding to a particular location in a class, it uses the Java Debugging Interface (JDI) API to read the source name and source path for the stratum it intends to use for the display. Let's assume for the moment it wants to use the JSP stratum. So the debugger first looks for the file A/org/apache/jsp/numguess.jsp, then for B/org/apache/jsp/numguess.jsp. You get the idea. The problem is that there's no directory that the user could specify in the debugger's search path that allows the debugger to find the file, because the jsp file doesn't reside in a org/apache/jsp subdirectory of any directory. Instead, it resides in the TH/webapps/jsp-examples/num directory, where TH is the Tomcat home directory. One possibility would be for Jasper to specify . (just a dot, meaning the current directory) as the source path in the SMAP for the JSP stratum. Then the user could enter TH/webapps/jsp-examples/num as the path to search. The debugger would be able to locate the file, since it would then be looking for TH/webapps/jsp-examples/num/./numguess.jsp. But I have a better suggestion: How about specifying the subdirectory of the directory in which the web application is expanded? Continuing the example, this means specifying the source path num for the file numguess.jsp. The user would then enter TH/webapps/jsp-examples into the debugger's search path. When the debugger tries to locate the file, it will paste together these three pieces and come up with TH/webapps/jsp-examples/num/numguess.jsp, successfully finding the file. The advantage of this approach is that the user need only enter the top directory of the web application into the debugger's search path and the debugger will then be able to locate any JSP file for the web application. If . were used, the user would need to enter every directory under the web application's top directory that contains a JSP to be debugged into the debugger's search path. A similar problem exists for the Java stratum. If the user of the debugger wanted to debug the JSP using the Java stratum, the debugger would try to locate the numguess_jsp.java file by searching the subdirectories of the debugger's search path. But again, the debugger would be unable to find the java file because it doesn't reside in a org/apache/jsp subdirectory of any directory. Just poking around, Jasper seems to put the Java source file under the TH/work directory, in my case in the directory TH/work/Standalone/localhost/jsp-examples/num. The solution here isn't as simple as for the JSP stratum, however, since I don't think it's possible to change the source path for a file in the Java stratum in the SMAP. In other words, the source path for numguess_jsp.java is stuck being org/apache/jsp, since that's the package the class is in. So, I can think of only two solutions: 1. Put the java file into the expected hierarchy. Perhaps designate that the jsp subdirectory of the web application's work
Re: Duplicate session IDs are *common*
Jim Jagielski [EMAIL PROTECTED] writes: Eric Rescorla wrote: Glenn Olander [EMAIL PROTECTED] writes: 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. This doesn't seem to me to be a plausible position in view of the fact that all of our security mechanisms absolutely depend on statistical uniqueness of randomly generated large numbers. These are 2 different points I think. If you randomly generate numbers between 1 and 1,000,000 you will, after a point in time, have duplicate numbers. Yes, but if you randomly generate numbers between 1 and 2^128, you'll have to generate roughly 2^64 random numbers to have a good chance of getting a duplicate. Sure, over time you'll get a duplicate, but in this context over time needs to be measured over a time scale far in excess of the time scale that is interesting. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Catalina.java
costin 2003/01/10 10:48:49 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java Log: Some versions of digester ( head ? ) seem to require the classloader to be set. It doesn't hurt to set it explicitely. Revision ChangesPath 1.12 +6 -7 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java Index: Catalina.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- Catalina.java 5 Dec 2002 15:57:48 - 1.11 +++ Catalina.java 10 Jan 2003 18:48:49 - 1.12 @@ -70,13 +70,11 @@ import java.io.IOException; import java.io.OutputStream; import java.net.Socket; -import java.util.Stack; import org.apache.catalina.Container; import org.apache.catalina.Lifecycle; import org.apache.catalina.LifecycleException; -import org.apache.catalina.LifecycleListener; import org.apache.catalina.Server; -import org.apache.catalina.Loader; +import org.apache.catalina.core.StandardServer; import org.apache.catalina.security.SecurityConfig; import org.apache.commons.digester.Digester; import org.apache.commons.digester.Rule; @@ -289,6 +287,7 @@ if (debug0) digester.setDebug(debug); digester.setValidating(false); +digester.setClassLoader(StandardServer.class.getClassLoader()); // Configure the actions we will be using digester.addObjectCreate(Server, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15966] New: - Jasper parser is incorrectly handling empty jsp:body elements
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=15966. 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=15966 Jasper parser is incorrectly handling empty jsp:body elements Summary: Jasper parser is incorrectly handling empty jsp:body elements Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Given the following productions: JspBodyBody ::= (S? JspBodyEmptyBody) | (S '' (JspBodyBodyContent - '') '/jsp:boyd' and JspBodyEmptyBody ::= '/' | '/jsp:body' | TRANSLATION_ERROR Jasper generates a translation error with the error message of lt;jsp:bodygt; must not have any attributes When it encounters something like: ctm:action jsp:body / ctm:action For the following code snippet: ctm:action jsp:body/jsp:body cts:action This error message is generated at translation time: Empty body not allowed for lt;jsp:bodygt; which is incorrect according to the grammar. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java
costin 2003/01/10 10:55:58
Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
Log:
Use commons-logging. Most of the code here should disapear as we
add it in the core objects ( remember - we voted that 5.0 will require and
use jmx )
Revision ChangesPath
1.6 +190 -192
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ServerLifecycleListener.java 10 Dec 2002 18:49:06 - 1.5
+++ ServerLifecycleListener.java 10 Jan 2003 18:55:57 - 1.6
@@ -66,15 +66,9 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
-import java.io.File;
-import java.io.InputStream;
-import java.net.URL;
-import java.util.Collection;
-import java.util.Iterator;
import java.util.StringTokenizer;
import javax.management.MBeanException;
-import javax.management.MBeanServer;
-import javax.management.ObjectName;
+
import org.apache.catalina.Connector;
import org.apache.catalina.Container;
import org.apache.catalina.ContainerEvent;
@@ -84,12 +78,12 @@
import org.apache.catalina.Engine;
import org.apache.catalina.Globals;
import org.apache.catalina.Host;
-import org.apache.catalina.Loader;
-import org.apache.catalina.Logger;
-import org.apache.catalina.Manager;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;
+import org.apache.catalina.Loader;
+import org.apache.catalina.Logger;
+import org.apache.catalina.Manager;
import org.apache.catalina.Realm;
import org.apache.catalina.Server;
import org.apache.catalina.ServerFactory;
@@ -104,7 +98,8 @@
import org.apache.catalina.deploy.ContextResource;
import org.apache.catalina.deploy.ContextResourceLink;
import org.apache.catalina.deploy.NamingResources;
-import org.apache.catalina.deploy.ResourceParams;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
/**
@@ -120,6 +115,9 @@
public class ServerLifecycleListener
implements ContainerListener, LifecycleListener, PropertyChangeListener {
+private static Log log = LogFactory.getLog(ServerLifecycleListener.class);
+
+
// - Properties
@@ -193,7 +191,7 @@
(Valve) event.getData());
}
} catch (Exception e) {
-log(Exception processing event + event, e);
+log.error(Exception processing event + event, e);
}
}
@@ -223,7 +221,7 @@
try {
MBeanUtils.createRMIAdaptor(adaptor);
} catch (Exception e) {
-log(createAdaptor: Exception, e);
+log.error(createAdaptor: Exception, e);
}
}
@@ -292,7 +290,7 @@
event.getOldValue(),
event.getNewValue());
} catch (Exception e) {
-log(Exception handling Container property change, e);
+log.error(Exception handling Container property change, e);
}
} else if (event.getSource() instanceof DefaultContext) {
try {
@@ -302,7 +300,7 @@
event.getOldValue(),
event.getNewValue());
} catch (Exception e) {
-log(Exception handling DefaultContext property change, e);
+log.error(Exception handling DefaultContext property change, e);
}
} else if (event.getSource() instanceof NamingResources) {
try {
@@ -312,7 +310,7 @@
event.getOldValue(),
event.getNewValue());
} catch (Exception e) {
-log(Exception handling NamingResources property change, e);
+log.error(Exception handling NamingResources property change, e);
}
} else if (event.getSource() instanceof Server) {
try {
@@ -321,7 +319,7 @@
event.getOldValue(),
event.getNewValue());
} catch (Exception e) {
-log(Exception handing Server property change, e);
+
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans GlobalResourcesLifecycleListener.java
costin 2003/01/10 10:57:06
Modified:catalina/src/share/org/apache/catalina/mbeans
GlobalResourcesLifecycleListener.java
Log:
If no java: naming is found - report it but don't be too verbose.
Revision ChangesPath
1.2 +6 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/GlobalResourcesLifecycleListener.java
Index: GlobalResourcesLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/GlobalResourcesLifecycleListener.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- GlobalResourcesLifecycleListener.java 18 Jul 2002 16:47:58 - 1.1
+++ GlobalResourcesLifecycleListener.java 10 Jan 2003 18:57:06 - 1.2
@@ -166,9 +166,8 @@
try {
context = (Context) (new InitialContext()).lookup(java:/);
} catch (NamingException e) {
-e.printStackTrace();
-throw new IllegalStateException
-(No global naming context defined for server);
+log(No global naming context defined for server);
+return;
}
// Recurse through the defined global JNDI resources context
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappLoader.java
costin 2003/01/10 10:59:50
Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
Log:
Some info for the jmx console. It's nice to see the repositories.
It would also be nice to have a method to display info about how
a class will be loaded ( from parent or what repo ) as well as last mod time.
I'll try to use WebppLoader as a basis for a loader to be used in modeler -
and merge it with the StandardLoader ( i.e. support both filesystem and
jndi sources ).
Having more JMX support in the loader will help track a lot of problems.
Wish I had more time...
Revision ChangesPath
1.6 +16 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- WebappLoader.java 16 Oct 2002 16:08:29 - 1.5
+++ WebappLoader.java 10 Jan 2003 18:59:50 - 1.6
@@ -545,6 +545,18 @@
}
+public String[] getRepositories() {
+return ((String[])repositories.clone());
+}
+
+public String getRepositoriesString() {
+StringBuffer sb=new StringBuffer();
+for( int i=0; irepositories.length ; i++ ) {
+sb.append( repositories[i]).append(:);
+}
+return sb.toString();
+}
+
/**
* Has the internal repository associated with this Loader been modified,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
At 10:42 AM -0800 1/10/03, Eric Rescorla wrote: Jim Jagielski [EMAIL PROTECTED] writes: Eric Rescorla wrote: Glenn Olander [EMAIL PROTECTED] writes: 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. This doesn't seem to me to be a plausible position in view of the fact that all of our security mechanisms absolutely depend on statistical uniqueness of randomly generated large numbers. These are 2 different points I think. If you randomly generate numbers between 1 and 1,000,000 you will, after a point in time, have duplicate numbers. Yes, but if you randomly generate numbers between 1 and 2^128, you'll have to generate roughly 2^64 random numbers to have a good chance of getting a duplicate. Sure, over time you'll get a duplicate, but in this context over time needs to be measured over a time scale far in excess of the time scale that is interesting. Of course, as you said, it depends on the range and the timespan. But it doesn't change the fact that randomness != uniqueness, which is what Glenn's point was I think. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
The check will verify that the session id doesn't duplicate another active session. If the session expires - it is still possible ( even if extremely unlikely ) that a user will reuse the same browser window and get into someone's else session. I think this is as likely as someone using a random session ID ( for any decent random generator, the fact that a number has been generated before shouldn't affect the probability of having it generated again - AFAIK ) We could completely eliminate this chance by including the time - so each sessionID will have the start time included in it ( that may be used for other purpose eventually ). Costin Glenn Olander wrote: Here's a follow-up on the bug report I submitted that started this thread. 1) We confirmed the problem is a duplicate session id. Luckily we were logging session id's. It took a lot of hunting through access logs, but we did indeed find two sessions which were started a couple of minutes apart, with a number of intervening sessions, which had duplicate session id's. The pair of sessions corresponded to the user report of seeing someone else's session data. We're using 4.1.12. 2) I don't believe this is *common* The problem hasn't been duplicated in our app, so I'm not sure I'd call this a common problem, but that's a subjective term. 3) I believe this is a serious vulnerability There should probably be some sort of an alert delivered to tomcat users to let them know of this problem. 4) A simple patch is available It is not necessary to use the head version of tomcat to fix the problem. Simply install your own manager class, which subclasses StandardManager, which has the duplicate session id checking implemented. In other words, a simple patch on an existing tomcat installation can fix this. 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. The head revision now includes such a check, so I believe the problem has been solved. Even the weakest of PRNG's would generate a collision only rarely, so I wouldn't worry about improving its strength. - Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Eric Rescorla wrote: Jim Jagielski [EMAIL PROTECTED] writes: Eric Rescorla wrote: Glenn Olander [EMAIL PROTECTED] writes: 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. This doesn't seem to me to be a plausible position in view of the fact that all of our security mechanisms absolutely depend on statistical uniqueness of randomly generated large numbers. These are 2 different points I think. If you randomly generate numbers between 1 and 1,000,000 you will, after a point in time, have duplicate numbers. Yes, but if you randomly generate numbers between 1 and 2^128, you'll have to generate roughly 2^64 random numbers to have a good chance of getting a duplicate. Sure, over time you'll get a duplicate, but in this context over time needs to be measured over a time scale far in excess of the time scale that is interesting. Adding the startup time doesn't hurt. Or enough bits of the startup time to guarantee a duplicate won't happen in our life. We'll still have the probability that 2 random number generated at the same time ( same millis ) will be identical. :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
On Fri, 10 Jan 2003, Jim Jagielski wrote: But it doesn't change the fact that randomness != uniqueness, which is what Glenn's point was I think. Just as an example; doing on issue syncronized count++; id = count.ipaddr add port if you must :-) gives you a rather unique (but predictable) session id. The uniqueness of the ipaddres obviously relies on the registry function of iana/ripe/et.al. combined with your site/provider IP management. or if it must be un-prediable do something like: on init seed = true-rand... or config-file-entry on issue id = md5( seed . count . ipaddr ); or if you do not trust md5's or find them too expensive id = hash(seed.count.ipaddr).count.ipaddr with hash = md4, md5, sha1, crypt, .. as long as it is one way -and- seed is truly random or manually choosen to be proper. OR if you want to check a session id prior to spending (lookup) cycles on them to counter DoS0-s then do something like id = hash(seed.count.hisip.ipaddr).count.ipaddr.hisip and on accept do hisip = from-accept-stack-info() s,c,i1,i2 = splice(id) i2 == hisip ? i1 == myip ? hash(seed.c.hisip.myip) == s ? now do the expensive stuff add a time-of-issue if needed if you are worried about that. Obviously now the seed -must- be a config secret; as otherwise you cannot restart your server without blowing all sessions out of the water. Dw. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
I think you may have misunderstood. I'm just pointing out that, from a user's perspective, a good solution requires two elements: 1) a good PRNG, such as secureRandom 2) a uniqueness guarantee I'm not saying a PRNG is unneeded. I'm just saying a good one like PRNG is good enough as long as it is accompanied by a uniqueness guarantee. Are you saying you want to remove the uniqueness guarantee? - Glenn Eric Rescorla [EMAIL PROTECTED] writes: Glenn Olander [EMAIL PROTECTED] writes: 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. This doesn't seem to me to be a plausible position in view of the fact that all of our security mechanisms absolutely depend on statistical uniqueness of randomly generated large numbers. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Jim Jagielski [EMAIL PROTECTED] writes: Of course, as you said, it depends on the range and the timespan. But it doesn't change the fact that randomness != uniqueness, which is what Glenn's point was I think. Perhaps not from a theoretical persective, but from a practical perspective it does. With a sufficiently large session ID, the probability of a collision can be made vastly less than the probability that some sort of programming error (or a hardware error) making an invalid session appear valid. As I said previously, the entire practice of modern security depends on this. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Glenn Olander [EMAIL PROTECTED] writes: I think you may have misunderstood. I'm just pointing out that, from a user's perspective, a good solution requires two elements: 1) a good PRNG, such as secureRandom 2) a uniqueness guarantee I'm not saying a PRNG is unneeded. I'm just saying a good one like PRNG is good enough as long as it is accompanied by a uniqueness guarantee. Are you saying you want to remove the uniqueness guarantee? I'm saying that a strong PRNG with a sufficiently wide session ID provides a statistical probability of collision so low that there is no need to explicitly check for uniqueness. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Costin Manolache [EMAIL PROTECTED] writes: Eric Rescorla wrote: Jim Jagielski [EMAIL PROTECTED] writes: Eric Rescorla wrote: Glenn Olander [EMAIL PROTECTED] writes: 5) The strength of the PRNG is largely irrelevant As a user, I wouldn't trust any solution which lacks a check for duplicate session id's, regardless of the strength of the PRNG. This doesn't seem to me to be a plausible position in view of the fact that all of our security mechanisms absolutely depend on statistical uniqueness of randomly generated large numbers. These are 2 different points I think. If you randomly generate numbers between 1 and 1,000,000 you will, after a point in time, have duplicate numbers. Yes, but if you randomly generate numbers between 1 and 2^128, you'll have to generate roughly 2^64 random numbers to have a good chance of getting a duplicate. Sure, over time you'll get a duplicate, but in this context over time needs to be measured over a time scale far in excess of the time scale that is interesting. Adding the startup time doesn't hurt. Or enough bits of the startup time to guarantee a duplicate won't happen in our life. No, it doesn't hurt. I just don't think it adds much value. Why not use a simple counter, though? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15967] New: - IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated.
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=15967. 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=15967 IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated. Summary: IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to the javadocs for HttpSession.getLastAccessedTime() will throw an IllegalStateException if called against a method that has been invalidated. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
I saw another problem that had similar symptoms to duplicate session ID's. My application was getting collisions between different users having the same session ID using tomcat 4.0.5. I found that the request headers were not being cleared out when they were recycled so that cookies from a current request were added to the cookies on the previous request. Since only the first JSESSIONID cookie is used to obtain the session id both users ended up with the same session id. I solved this in my application by using rewritten URLs instead of cookies. I was unable to find a bug in examining the tomcat code. I did not check the mod_jk code. Steve __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
On Fri, 10 Jan 2003, Glenn Olander wrote: 1) a good PRNG, such as secureRandom Why does it need to be securely random; surely unpredicatable is good enough ? 2) a uniqueness guarantee count++ +:+myip+:+myport is also quite unqiue :-) DW. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
ID provides a statistical probability of collision so low that there is no need to explicitly check for uniqueness. Or just add a syncronized i++ to make sure. Dw. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Dirk-Willem van Gulik [EMAIL PROTECTED] writes: On Fri, 10 Jan 2003, Glenn Olander wrote: 1) a good PRNG, such as secureRandom Why does it need to be securely random; surely unpredicatable is good enough ? Securely random and unpredictable are effectively the same thing. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Dirk-Willem van Gulik [EMAIL PROTECTED] writes: ID provides a statistical probability of collision so low that there is no need to explicitly check for uniqueness. Or just add a syncronized i++ to make sure. Yes. There's nothing wrong with what you propose, but it's sort of like saying maybe I should wear a helmet at all times because a meteor might drop on my head. Sure, it could happen, btu it's not the thing I'd worry about. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Securely random and unpredictable are effectively the same thing. Depends on your definition; one-way-function((count++) + (secret)) is quite unpredictable; expcet for those knowing the secret. Secure random generators give you a value which is unpredictable for all. And are a lot more expensive generally. Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
On 10 Jan 2003, Eric Rescorla wrote: There's nothing wrong with what you propose, but it's sort of like saying maybe I should wear a helmet at all times because a meteor might drop on my head. Sure, it could happen, btu it's not the thing I'd worry about. Except that hash( i++ . secret).i is generally a lot cheaper and easier to code cross platform than using a true cryptographic random generator with the right tie in with hardware. And it happens to have a hard-hat aspect thrown in as a freebee. Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15974] New: - Original stack trace is lost
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=15974.
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=15974
Original stack trace is lost
Summary: Original stack trace is lost
Product: Tomcat 4
Version: 4.1.18
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi,
It seems that when an exception reaches the Jasper from an application, the
component throws the root cause's stack trace away, keeping only the
exception's message, which in some cases is not sufficient for the programmer
to find the problem.
I believe this change (possibly a bug) has been made since early versions of
Tomcat 4.x, as the Tomcat 3.3a shows the complete stack trace.
To isolate and demonstrate the problem, I've created a simple application,
which consists of a Java class, and a JSP:
-- Java class source code --
package com.test;
public class StackTraceTest {
public static void throwError() throws Exception {
if (1 == 1) throw new Exception(just testing);
}
}
--
-- JSP source code --
% com.test.StackTraceTest.throwError(); %
--
On Tomcat 4.1.18 (think early versions of 4.x does the same), it produces the
following content, in the browser and in the log:
--
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from
fulfilling this request.
exception
org.apache.jasper.JasperException: just testing
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:248)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:493)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:432)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/res LocalStrings.properties LocalStrings_fr.properties
remm2003/01/10 12:22:38
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
util/java/org/apache/tomcat/util/net/res
LocalStrings.properties LocalStrings_fr.properties
Log:
- Refactor the server socket restart code.
Revision ChangesPath
1.12 +76 -55
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
Index: PoolTcpEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- PoolTcpEndpoint.java 1 Jan 2003 13:55:22 - 1.11
+++ PoolTcpEndpoint.java 10 Jan 2003 20:22:37 - 1.12
@@ -122,6 +122,7 @@
ThreadPoolRunnable listener;
private volatile boolean running = false;
private boolean initialized = false;
+private boolean reinitializing = false;
static final int debug=0;
ThreadPool tp;
@@ -311,28 +312,34 @@
if (running) {
tp.shutdown();
running = false;
- try {
- // Need to create a connection to unlock the accept();
- Socket s;
- if (inet == null) {
- s=new Socket(127.0.0.1, port );
- }else{
- s=new Socket(inet, port );
+if (serverSocket != null) {
+closeServerSocket();
+}
+ }
+}
+
+protected void closeServerSocket() {
+try {
+// Need to create a connection to unlock the accept();
+Socket s;
+if (inet == null) {
+s=new Socket(127.0.0.1, port );
+}else{
+s=new Socket(inet, port );
// setting soLinger to a small value will help shutdown the
// connection quicker
-s.setSoLinger(true, 0);
- }
- s.close();
- } catch(Exception e) {
-log.error(Caught exception trying to unlock accept., e);
- }
- try {
- serverSocket.close();
- } catch(Exception e) {
-log.error(Caught exception trying to close socket., e);
- }
- serverSocket = null;
- }
+s.setSoLinger(true, 0);
+}
+s.close();
+} catch(Exception e) {
+log.error(Caught exception trying to unlock accept., e);
+}
+try {
+serverSocket.close();
+} catch(Exception e) {
+log.error(Caught exception trying to close socket., e);
+}
+serverSocket = null;
}
// Private methods
@@ -362,49 +369,62 @@
}
catch (IOException e) {
-if (running) {
+String msg = null;
-String msg = sm.getString(endpoint.err.nonfatal,
+if (running) {
+msg = sm.getString(endpoint.err.nonfatal,
serverSocket, e);
log.error(msg, e);
+}
-if (accepted != null) {
-try {
-accepted.close();
-accepted = null;
-} catch(Exception ex) {
-msg = sm.getString(endpoint.err.nonfatal,
-accepted, ex);
-log.warn(msg, ex);
-}
+if (accepted != null) {
+try {
+accepted.close();
+accepted = null;
+} catch(Exception ex) {
+msg = sm.getString(endpoint.err.nonfatal,
+ accepted, ex);
+log.warn(msg, ex);
}
-// Restart endpoint when getting an IOException during accept
-synchronized (threadSync) {
+}
+
+reinitializing = true;
+// Restart endpoint when getting an IOException during accept
+synchronized (threadSync) {
+if (reinitializing) {
+reinitializing = false;
+// 1) Attempt to close server socket
+closeServerSocket();
+initialized = false;
+// 2) Reinit endpoint (recreate server socket)
try {
-serverSocket.close();
-} catch(Exception ex) {
+msg = sm.getString(endpoint.warn.reinit);
+log.warn(msg);
+
Re: Duplicate session IDs are *common*
Eric Rescorla wrote: Dirk-Willem van Gulik [EMAIL PROTECTED] writes: ID provides a statistical probability of collision so low that there is no need to explicitly check for uniqueness. Or just add a syncronized i++ to make sure. Yes. There's nothing wrong with what you propose, but it's sort of like saying maybe I should wear a helmet at all times because a meteor might drop on my head. Sure, it could happen, btu it's not the thing I'd worry about. I find it amazing that 2 people reported beeing hit by meteors (duplicate session ids ) in the same week. You're right - a counter is better than time. It'll duplicate the counter if tomcat is restarted - so probably the initial value of the counter should be random or derived from time. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Costin Manolache wrote: I find it amazing that 2 people reported beeing hit by meteors (duplicate session ids ) in the same week. I find it odd that it actually happened ... You're right - a counter is better than time. It'll duplicate the counter if tomcat is restarted - so probably the initial value of the counter should be random or derived from time. Yes, since sessions are saved and then reloaded by Tomcat on restart. Anyway, as far as I am concerned, I don't see any security problem so far, so I won't make any security bulletin. I'll compile the list of changes since 4.1.18 early next week, for maybe a new alpha release. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
trouble with jk2 vs. Apache2 on OSX 10.2.3: Segmentation fault$HTTPD -k $ARGV
i've successfully installed Apache2 Tomcat on OSX 10.2.3 both run great in standalone . but Apache2 + Coyote jk2 refuses to launch/function Apache2 is a CVS build, server-info is: Server Version: Apache/2.1.0-dev (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 PHP/4.4.0-dev mod_auth_pgsql/2.0b6 DAV/2 Server Built: Jan 6 2003 00:37:56 API Version: 20020903:0 Hostname/port: testserver.internal.blakers.net:80 Timeouts: connection: 300keep-alive: 300 MPM Name: Worker MPM Information: Max Daemons: 1 Threaded: yes Forked: yes Server Root: /usr Config File: /etc/apache2/httpd.conf Tomcat is binary: jakarta-tomcat-4.1.18 jk2 is built/installed from CVS (timestamp: 01/10/03 01:18:27) LoadModule jk2_module libexec/apache2/mod_jk2.so is added to httpd.conf tomcat starts as usual -- fine with/without tomcat running, an attempt to launch apache (apachectl start) results in: apachectl start /usr/sbin/apachectl: line 87: 1601 Segmentation fault $HTTPD -k $ARGV removing the jk2 LoadModule makes the error go away . Apache's error_log is: [Fri Jan 10 12:34:39 2003] [info] mod_unique_id: using ip addr 172.30.10.3 [Fri Jan 10 12:34:40 2003] [info] mod_unique_id: using ip addr 172.30.10.3 [Fri Jan 10 12:34:41 2003] [notice] Digest: generating secret for digest authentication ... [Fri Jan 10 12:34:41 2003] [notice] Digest: done [Fri Jan 10 12:34:41 2003] [notice] Apache/2.1.0-dev (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 PHP/4.4.0-dev mod_auth_pgsql/2.0b6 DAV/2 configured -- re [Fri Jan 10 12:34:41 2003] [info] Server built: Jan 6 2003 00:37:56 [Fri Jan 10 12:34:41 2003] [debug] worker.c(1736): AcceptMutex: posixsem (default: posixsem) [Fri Jan 10 12:35:47 2003] [info] removed PID file /var/run/httpd.pid (pid=1587) [Fri Jan 10 12:35:47 2003] [notice] caught SIGTERM, shutting down [Fri Jan 10 12:35:50 2003] [info] mod_unique_id: using ip addr 172.30.10.3 my first surmise is that there is a problem with the jk2 connector build, but i'm not sure, and haven't the foggiest as to how to check/where to begin thoughts/suggestion? richard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Proposal: RUNNING.TXT classpath update
It seems many people are frustrated because Tomcat doesn't work right away, which is mainly because of faulty classpath settings, a lack in the setup documentation. I'd suggest someone add to the RUNNING.TXT doc at the end of the part (1) Download and Install the Tomcat 4.0 Binary Distribution, a couple of helpful lines like -- * Configure your classpath: Update your environment variable CLASSPATH to contain at least the following entries (of course, adapted to your operating system and paths): .; E:\java\j2sdk14\lib; F:\Servlet\Jakarta\server\lib; F:\Servlet\Jakarta\lib; F:\servlet\jakarta\common\lib\servlet.jar; E:\java\j2sdk14\lib\tools.jar; F:\servlet\jakarta\lib\jasper-runtime.jar; Especially check that servlet.jar, tools.jar, and jasper-runtime.jar path names are specified correctly. Without these, Tomcat can not start. --- (I'd do this myself if i had ever used CVS, but... ;) cheers, - Jan -- * high voltage at http://www.hut.fi/~jwagner/tesla Jan OH2GHR -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Combining two messages... Dirk-Willem van Gulik [EMAIL PROTECTED] writes: Securely random and unpredictable are effectively the same thing. Depends on your definition; one-way-function((count++) + (secret)) is quite unpredictable; expcet for those knowing the secret. Secure random generators give you a value which is unpredictable for all. And are a lot more expensive generally. ... Securely random and unpredictable are effectively the same thing. Depends on your definition; one-way-function((count++) + (secret)) is quite unpredictable; expcet for those knowing the secret. Secure random generators give you a value which is unpredictable for all. And are a lot more expensive generally. What you've just described is a form of cryptographically secure PRNG called a message digest in counter mode. This isn't exactly what I would use but it's roughly equivalent. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Costin Manolache [EMAIL PROTECTED] writes: Eric Rescorla wrote: Dirk-Willem van Gulik [EMAIL PROTECTED] writes: ID provides a statistical probability of collision so low that there is no need to explicitly check for uniqueness. Or just add a syncronized i++ to make sure. Yes. There's nothing wrong with what you propose, but it's sort of like saying maybe I should wear a helmet at all times because a meteor might drop on my head. Sure, it could happen, btu it's not the thing I'd worry about. I find it amazing that 2 people reported beeing hit by meteors (duplicate session ids ) in the same week. I do too. Something is wrong but I don't know what it is yet. However, the solution isn't to add a bandaid, but rather to examine the code and figure out what's broken. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver
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=15672. 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=15672 DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver --- Additional Comments From [EMAIL PROTECTED] 2003-01-10 22:23 --- Hello, I am having the same problem with the MySQL driver (connector/j 3.0.4). I checked that the BasicDatasource instance is created. I did not check whether the description is there but the important parameters (driver, url, username, pass) were not there. I am not attaching my sever.xml and web.xml files as they are alomst identical except the driverClassName is com.mysql.jdbc.Driver and the url is mysql specific. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
costin 2003/01/10 14:36:43
Added: coyote/src/java/org/apache/coyote BaseHook.java
Log:
Added a base implementation of ActionHook - with some small additions :-)
First, there is a getNext/setNext to allow multiple hooks to be chained.
Both recursive and iterative will be supported - you can call next directly or
just return it ( still need to tune this - only recursive works now )
In addition, the hook implements MBeanRegistration ( again: we did vote on
JMX dependency ). Tomcat3.3 may be a problem ( since it's using the same code),
but if someone wants to use the new connector he can also add jmx in the
path. If anyone has a problem with that - please let me know, I can hack
some conditional compilation, but I would like to keep it simple.
I'll change the 2 hook implementations to extend this after it settles down.
Feel free to make changes - or ask for changes or just say -1.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
Index: BaseHook.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.coyote;
import javax.management.MBeanRegistration;
import javax.management.ObjectName;
import javax.management.MBeanServer;
/**
* Action hook.
*
* @author Remy Maucherat
* @author Costin Manolache
*/
public class BaseHook implements ActionHook, MBeanRegistration {
protected BaseHook next;
/**
* Send an action to the connector.
* Both recursive and iterative invocation is possible - the
* hook may call itself the next hook ( like catalina ) or the
* controller may call the next.
*
* @param param Action parameter
* @return A hook that can be executed next.
*/
public BaseHook action(int code, Object param) {
if( next==null ) return next;
return next.action( code, param );
};
/** Backward compat
*
* @param actionCode
* @param param
*/
public void action( ActionCode actionCode, Object param) {
DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver
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=15672. 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=15672 DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver --- Additional Comments From [EMAIL PROTECTED] 2003-01-10 22:44 --- I have been able to get Oracle's JDBC Driver working just fine with Tomcat 4.1.18. Below are my specifics from server.xml. Are you sure that classes12.jar is in $CATALINA_HOME/common/lib? Resource name=jdbc/mydatabase auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/mydatabase parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter parameter namemaxActive/name value50/value /parameter parameter namemaxIdle/name value10/value /parameter parameter namemaxWait/name value1/value /parameter parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter parameter namedriverClassName/name valueoracle.jdbc.driver.OracleDriver/value /parameter parameter nameurl/name valuejdbc:oracle:thin:@host:1521:database/value /parameter parameter nameremoveAbandoned/name valuetrue/value /parameter parameter nameremoveAbandonedTimeout/name value60/value /parameter parameter namelogAbandoned/name valuetrue/value /parameter /ResourceParams -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JNDIRealm feature enhancements
After setting up a JNDIRealm for the Manager app, I noticed after a while the connection times out and returns NULL automatically. I was wondering, if instead of returning NULL, JNDIRealm to try to reconnect and then authenticate, and then return NULL, if a failure results from that attempt, otherwise return the JNDIRealm.User object. Also Ive notice there is no method for specifying an alternate connection URL in the event the URL specified in connectionURL is not available. So, I took the liberty of adding an attribute alternateURL to specify a secondary URL. When the JNDIRealm opens a connection it will attempt the primary, and, upon failure, then attempt to connect to the alternate URL. If this should fail, the JNDIRealm fails as it did before. In both features the first exception is logged before the second attempt to connect proceeds. I have attached the CVS diff between my copy of JNDIRealm and the current HEAD version of JNDIRealm. Brad Handy Programmer/Analyst Spring Arbor University JNDI.diff Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Email Rejected: Unknown or disallowed attachment type
Received: from [198.76.25.3] (HELO nns.voyanttech.com)
by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
with SMTP id 3430066 for [EMAIL PROTECTED]; Fri, 10 Jan 2003 16:06:16 -0700
Received: from exchange.sun.com (exchange.sun.com [192.18.33.10])
by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id QAA26144
for [EMAIL PROTECTED]; Fri, 10 Jan 2003 16:54:21 -0500 (EST)
Received: (qmail 28659 invoked by uid 97); 10 Jan 2003 23:07:29 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Post: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 28643 invoked by uid 98); 10 Jan 2003 23:07:28 -
X-Antivirus: nagoya (v4218 created Aug 14 2002)
From: Bradley M. Handy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: JNDIRealm feature enhancements
Date: Fri, 10 Jan 2003 18:06:02 -0500
Message-ID: 000a01c2b8fc$d8a77e00$[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==_NextPart_000_000B_01C2B8D2.EFD17600
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by AMaViS perl-10
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
--=_NextPart_000_000B_01C2B8D2.EFD17600
Content-Type: multipart/alternative;
boundary==_NextPart_001_000C_01C2B8D2.EFD17600
--=_NextPart_001_000C_01C2B8D2.EFD17600
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
After setting up a JNDIRealm for the Manager app, I noticed after a
while the connection times out and returns NULL automatically. I was
wondering, if instead of returning NULL, JNDIRealm to try to reconnect
and then authenticate, and then return NULL, if a failure results from
that attempt, otherwise return the JNDIRealm.User object.
Also I've notice there is no method for specifying an alternate
connection URL in the event the URL specified in connectionURL is not
available. So, I took the liberty of adding an attribute alternateURL
to specify a secondary URL. When the JNDIRealm opens a connection it
will attempt the primary, and, upon failure, then attempt to connect to
the alternate URL. If this should fail, the JNDIRealm fails as it did
before.
In both features the first exception is logged before the second attempt
to connect proceeds.
I have attached the CVS diff between my copy of JNDIRealm and the
current HEAD version of JNDIRealm.
Brad Handy
Programmer/Analyst
Spring Arbor University
--=_NextPart_001_000C_01C2B8D2.EFD17600
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:o=3Durn:schemas-microsoft-com:office:office =
xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns=3Dhttp://www.w3.org/TR/REC-html40;
head
META HTTP-EQUIV=3DContent-Type CONTENT=3Dtext/html; =
charset=3Dus-ascii
meta name=3DProgId content=3DWord.Document
meta name=3DGenerator content=3DMicrosoft Word 10
meta name=3DOriginator content=3DMicrosoft Word 10
link rel=3DFile-List href=3Dcid:[EMAIL PROTECTED];
!--[if gte mso 9]xml
o:OfficeDocumentSettings
o:DoNotRelyOnCSS/
/o:OfficeDocumentSettings
/xml![endif]--!--[if gte mso 9]xml
w:WordDocument
w:SpellingStateClean/w:SpellingState
w:GrammarStateClean/w:GrammarState
w:DocumentKindDocumentEmail/w:DocumentKind
w:EnvelopeVis/
w:Compatibility
w:BreakWrappedTables/
w:SnapToGridInCell/
w:ApplyBreakingRules/
w:WrapTextWithPunct/
w:UseAsianBreakRules/
/w:Compatibility
w:BrowserLevelMicrosoftInternetExplorer4/w:BrowserLevel
/w:WordDocument
/xml![endif]--
style
!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:;
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Times New Roman;
mso-fareast-font-family:Times New Roman;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;
text-underline:single;}
span.EmailStyle17
{mso-style-type:personal-compose;
mso-style-noshow:yes;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
font-family:Arial;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:windowtext;}
span.SpellE
{mso-style-name:;
mso-spl-e:yes;}
span.GramE
{mso-style-name:;
mso-gram-e:yes;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
DO NOT REPLY [Bug 15982] New: - jdbc realm - digest for cleartext pw does not work
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=15982. 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=15982 jdbc realm - digest for cleartext pw does not work Summary: jdbc realm - digest for cleartext pw does not work Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] i just tried to create an additional jdbc realm and i thought its enough to enter nothing into the digest field (inside the administration webapp) after storing the new server.xml, this file contains one empty attribute called digest (digest=) inside the realm tag the problem now is, that its impossible to start tomcat 4.1.18 .. its possible to start without such digest attribute, and its also possible to start tomcat with values like digest=MD5, but its impossible to start tomcat with digest= the only problem is, that its impossible to create realm elements without the digest attribute by means of your administration tool (this means its impossible to create unencrypted jdbc realms using your adminstration tool) cybi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote build.xml
costin 2003/01/10 16:03:01
Modified:coyote build.xml
Log:
Add the jmx dependency.
Add a separate target that just builds for tomcat5, to avoid
all the detection.
Revision ChangesPath
1.16 +12 -1 jakarta-tomcat-connectors/coyote/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- build.xml 6 Jan 2003 18:35:20 - 1.15
+++ build.xml 11 Jan 2003 00:03:01 - 1.16
@@ -78,6 +78,7 @@
path id=compile.classpath
pathelement location=${build.home}/classes/
pathelement location=../util/build/classes/
+pathelement location=${jmx.jar}/
pathelement location=${tomcat-util.jar}/
pathelement location=${catalina.home}/server/lib/catalina.jar/
pathelement location=${servlet.jar}/
@@ -211,6 +212,16 @@
copytodir=${build.home}/classes filtering=on
fileset dir=${source.home} excludes=**/*.java/
/copy
+ /target
+
+ target name=jar.tomcat5 depends=compile.shared,compile.tomcat5
+jar jarfile=${tomcat-coyote.jar}
+ basedir=${build.home}/classes
+ manifest=${conf.home}/MANIFEST.MF
+ excludes=**/tomcat3/*
+ include name=org/apache/coyote/*.class /
+ include name=org/apache/coyote/tomcat5/** /
+/jar
/target
target name=compile.tomcat4 if=tomcat4.detect
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors gump.xml
costin 2003/01/10 16:05:10 Modified:.gump.xml Log: Add jmx deps in gump. Revision ChangesPath 1.10 +23 -1 jakarta-tomcat-connectors/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/gump.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- gump.xml 13 Nov 2002 00:12:49 - 1.9 +++ gump.xml 11 Jan 2003 00:05:10 - 1.10 @@ -32,12 +32,15 @@ project name=jakarta-tomcat-coyote packageorg.apache.coyote/package ant basedir=coyote + property name=jmx.home reference=home project=jmx/ + property name=jmx.jar project=jmx path=jmx/lib/jmxri.jar / property name=catalina.home reference=home project=tomcat-catalina/ /ant depend project=jakarta-ant/ depend project=xml-xerces/ +depend project=jmx/ depend project=jakarta-tomcat-util/ depend project=jakarta-servletapi-4/ depend project=tomcat-catalina/ @@ -53,12 +56,15 @@ project name=jakarta-tomcat-coyote_tc5 packageorg.apache.coyote/package ant basedir=coyote + property name=jmx.home reference=home project=jmx/ + property name=jmx.jar project=jmx path=jmx/lib/jmxri.jar / property name=catalina.home reference=home project=jakarta-tomcat-catalina/ property name=tomcat33.home value=/ /ant depend project=jakarta-ant/ +depend project=jmx/ depend project=xml-xerces/ depend project=jakarta-tomcat-util/ depend project=jakarta-servletapi-5-servlet/ @@ -75,11 +81,14 @@ packageorg.apache.jk/package ant basedir=jk + property name=jmx.home reference=home project=jmx/ + property name=jmx.jar project=jmx path=jmx/lib/jmxri.jar / property name=jsse.home reference=home project=jsse/ /ant depend project=jakarta-ant/ depend project=commons-logging/ +depend project=jmx/ depend project=jakarta-tomcat-util/ depend project=xml-xerces/ depend project=jakarta-tomcat-coyote/ @@ -93,10 +102,23 @@ from=Craig McClanahan lt;[EMAIL PROTECTED]gt;/ /project + project name=jakarta-tomcat-jk-ant +ant basedir=jk/jkant target=all +/ant + +depend project=jakarta-ant / + +jar name=build/lib/jkant.jar/ + /project + project name=jakarta-tomcat-jk2-native -ant basedir=jk/native2 target=all +ant basedir=jk/native2 target=main /ant + depend project=jakarta-ant / +depend project=jakarta-tomcat-jk-ant / +depend project=ant-contrib-cpptasks / + /project /module -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_fr.properties messages_ja.properties
kinman 2003/01/10 16:11:06
Modified:jasper2/src/share/org/apache/jasper/compiler Node.java
Parser.java TagPluginManager.java
jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
Log:
- Fix 15851: nested jsp:attribute should be disallowed.
Revision ChangesPath
1.52 +11 -8
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- Node.java 8 Jan 2003 18:42:43 - 1.51
+++ Node.java 11 Jan 2003 00:11:06 - 1.52
@@ -1333,11 +1333,14 @@
}
childInfo = new ChildInfo();
name = this.getAttributeValue(name);
- localName = name;
- int index = name.indexOf(':');
- if (index != -1) {
- prefix = name.substring(0, index);
- localName = name.substring(index+1);
+if (name != null) {
+// Mandatary attribute name will be checked in Validator
+ localName = name;
+ int index = name.indexOf(':');
+ if (index != -1) {
+ prefix = name.substring(0, index);
+ localName = name.substring(index+1);
+}
}
}
1.54 +7 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- Parser.java 9 Jan 2003 23:54:40 - 1.53
+++ Parser.java 11 Jan 2003 00:11:06 - 1.54
@@ -1568,6 +1568,10 @@
err.jspError( reader.mark(), jsp.error.not.in.template,
Expression language );
} else if (reader.matches(jsp:)) {
+if ((parent instanceof Node.NamedAttribute)
+reader.matches(attribute)) {
+err.jspError(reader.mark(), jsp.error.nested.jspattribute);
+}
err.jspError( reader.mark(), jsp.error.not.in.template,
Standard actions );
} else if (parseCustomTag(parent)) {
1.10 +5 -8
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagPluginManager.java
Index: TagPluginManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagPluginManager.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- TagPluginManager.java 1 Jan 2003 12:25:58 - 1.9
+++ TagPluginManager.java 11 Jan 2003 00:11:06 - 1.10
@@ -99,12 +99,9 @@
page.visit(new Node.Visitor() {
public void visit(Node.CustomTag n)
-throws JasperException {
+throws JasperException {
invokePlugin(n);
-Node.Nodes body = n.getBody();
-if (body != null) {
-body.visit(this);
-}
+visitBody(n);
}
});
1.78 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- messages.properties 9 Jan 2003 23:54:40 - 1.77
+++ messages.properties 11 Jan 2003 00:11:06 - 1.78
@@ -350,3 +350,4 @@
jsp.error.tagfile.illegalPath=Illegal tag file path: {0}, must start with
\/WEB-INF/tags\ or \/META-INF/tags\
jsp.error.plugin.wrongRootElement=Name of root element in {0} different from {1}
jsp.error.attribute.invalidPrefix=The attribute prefix {0} does not correspond to
any imported tag library
+jsp.error.nested.jspattribute=a jsp:attribute standard action cannot be nested
within another jsp:attribute standard action
1.27 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
Index: messages_es.properties
===
RCS file:
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Parser.java
luehe 2003/01/10 16:51:36
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
Log:
Fixed 15966: Jasper parser is incorrectly handling empty jsp:body elements
Revision ChangesPath
1.55 +11 -29
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- Parser.java 11 Jan 2003 00:11:06 - 1.54
+++ Parser.java 11 Jan 2003 00:51:36 - 1.55
@@ -1597,38 +1597,20 @@
}
/*
- * JspBodyBody ::= ( S? ''
- *( ( ScriptlessBody
- *| Body
- *| TagDependentBody
- * ) - ''
- *) '/jsp:body'
- * )
- * | ( ATTR[ !value ] S? JspBodyEmptyBody )
- *
- * JspBodyEmptyBody ::= '/'
- * | '/jsp:body'
- * | TRANSLATION_ERROR
- *
+ * Parses jsp:body action.
*/
private void parseJspBody(Node parent, String bodyType)
throws JasperException
{
Mark start = reader.mark();
-reader.skipSpaces();
-
-if (!reader.matches()) {
- err.jspError(reader.mark(),
- jsp.error.attributes.not.allowed,
- lt;jsp:bodygt; );
- }
-
Node bodyNode = new Node.JspBody(start, parent);
- if( reader.matches( /jsp:body ) ) {
- // Body was empty. This is illegal, according to the grammar.
- err.jspError(reader.mark(),jsp.error.empty.body.not.allowed,
- lt;jsp:bodygt; );
- } else {
+
+ reader.skipSpaces();
+ if (!reader.matches(/)) {
+ if (!reader.matches()) {
+ err.jspError(start, jsp.error.unterminated,
+ lt;jsp:body);
+ }
parseBody( bodyNode, jsp:body, bodyType );
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java Node.java
luehe 2003/01/10 16:52:14
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java
Log:
Fixed 15961: getBodyContent() is not returning null when the action
has only jsp:attribute actions within the body.
Revision ChangesPath
1.147 +6 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.146
retrieving revision 1.147
diff -u -r1.146 -r1.147
--- Generator.java8 Jan 2003 22:15:56 - 1.146
+++ Generator.java11 Jan 2003 00:52:14 - 1.147
@@ -1958,7 +1958,7 @@
syncScriptingVars(n, VariableInfo.AT_BEGIN);
}
- if (n.getBody() != null) {
+ if (!n.hasEmptyBody()) {
out.printin(if ();
out.print(tagEvalVar);
out.println( != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {);
@@ -2003,7 +2003,7 @@
String tagHandlerVar,
String tagEvalVar) {
- if (n.getBody() != null) {
+ if (!n.hasEmptyBody()) {
if (n.implementsIterationTag()) {
out.printin(int evalDoAfterBody = );
out.print(tagHandlerVar);
@@ -2120,7 +2120,7 @@
* and pass it to tag handler's setJspBody(), unless tag body
* is empty
*/
- if (n.getBody() != null) {
+ if (!n.hasEmptyBody()) {
out.printin(tagHandlerVar);
out.print(.setJspBody();
generateJspFragment(n, tagHandlerVar);
1.53 +34 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- Node.java 11 Jan 2003 00:11:06 - 1.52
+++ Node.java 11 Jan 2003 00:52:14 - 1.53
@@ -1265,6 +1265,37 @@
}
return n;
}
+
+ /**
+ * Returns true if this custom action has an empty body, and false
+ * otherwise.
+ *
+ * A custom action is considered to have an empty body if the
+ * following holds true:
+ * - getBody() returns null, or
+ * - all immediate children are jsp:attribute actions, or
+ * - the action's jsp:body is empty.
+ */
+ public boolean hasEmptyBody() {
+ boolean hasEmptyBody = true;
+ Nodes nodes = getBody();
+ if (nodes != null) {
+ int numChildNodes = nodes.size();
+ for (int i=0; inumChildNodes; i++) {
+ Node n = nodes.getNode(i);
+ if (!(n instanceof NamedAttribute)) {
+ if (n instanceof JspBody) {
+ hasEmptyBody = (n.getBody() == null);
+ } else {
+ hasEmptyBody = false;
+ }
+ break;
+ }
+ }
+ }
+
+ return hasEmptyBody;
+ }
}
/**
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15961] - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.
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=15961. 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=15961 getBodyContent() is not returning null when the action has only jsp:attribute actions within the body. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15966] - Jasper parser is incorrectly handling empty jsp:body elements
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=15966. 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=15966 Jasper parser is incorrectly handling empty jsp:body elements [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/manager build.xml
glenn 2003/01/10 17:16:59
Modified:webapps/manager build.xml
Log:
Fix build, images were not being copied
Revision ChangesPath
1.10 +1 -1 jakarta-tomcat-4.0/webapps/manager/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/manager/build.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- build.xml 10 Jan 2003 15:52:19 - 1.9
+++ build.xml 11 Jan 2003 01:16:59 - 1.10
@@ -52,7 +52,7 @@
!-- Images Subdirectory --
copy todir=${webapps.build}/${webapp.name}/images
fileset dir=../tomcat-docs/images
-include name=jakarta-logo.gif,tomcat.gif/
+exclude name=printer.gif/
/fileset
/copy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets HTMLManagerServlet.java
glenn 2003/01/10 17:17:31
Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java
Log:
Fix file upload install on Windows, reformat code to 80 col
Revision ChangesPath
1.14 +40 -19
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
Index: HTMLManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- HTMLManagerServlet.java 10 Jan 2003 15:52:18 - 1.13
+++ HTMLManagerServlet.java 11 Jan 2003 01:17:31 - 1.14
@@ -94,7 +94,7 @@
* application deployment descriptor. However, this requirement can be
* relaxed during testing.
* p
-* The difference between this codeManagerServlet/code and this
+* The difference between the codeManagerServlet/code and this
* Servlet is that this Servlet prints out a HTML interface which
* makes it easier to administrate.
* p
@@ -105,6 +105,7 @@
*
* @author Bip Thelin
* @author Malcolm Edgar
+* @author Glenn L. Nielsen
* @version $Revision$, $Date$
* @see ManagerServlet
*/
@@ -165,7 +166,7 @@
}
/**
- * Process a GET request for the specified resource.
+ * Process a POST request for the specified resource.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
@@ -225,15 +226,25 @@
}
while(true) {
if (warUpload == null) {
-message =
sm.getString(htmlManagerServlet.installUploadNoFile);
+message = sm.getString
+(htmlManagerServlet.installUploadNoFile);
break;
}
war = warUpload.getName();
if (!war.toLowerCase().endsWith(.war)) {
-message =
sm.getString(htmlManagerServlet.installUploadNotWar,war);
+message = sm.getString
+(htmlManagerServlet.installUploadNotWar,war);
break;
}
-// Identify the appBase of the owning Host of this Context (if any)
+// Get the filename if uploaded name includes a path
+if (war.lastIndexOf('\\') = 0) {
+war = war.substring(war.lastIndexOf('\\') + 1);
+}
+if (war.lastIndexOf('/') = 0) {
+war = war.substring(war.lastIndexOf('/') + 1);
+}
+// Identify the appBase of the owning Host of this Context
+// (if any)
String appBase = null;
File appBaseDir = null;
appBase = ((Host) context.getParent()).getAppBase();
@@ -244,7 +255,8 @@
}
File file = new File(appBaseDir,war);
if (file.exists()) {
-message =
sm.getString(htmlManagerServlet.installUploadWarExists,war);
+message = sm.getString
+(htmlManagerServlet.installUploadWarExists,war);
break;
}
warUpload.write(file.getCanonicalPath());
@@ -261,6 +273,7 @@
} catch(Exception e) {
message = sm.getString
(htmlManagerServlet.installUploadFail, e.getMessage());
+log(message, e);
} finally {
if (warUpload != null) {
warUpload.delete();
@@ -387,7 +400,8 @@
}
args[2] = new Boolean(context.getAvailable());
args[3] = response.encodeURL
-(request.getContextPath() + /html/sessions?path= +
displayPath);
+(request.getContextPath() +
+ /html/sessions?path= + displayPath);
args[4] =
new Integer(context.getManager().findSessions().length);
writer.print
@@ -395,16 +409,20 @@
args = new Object[8];
args[0] = response.encodeURL
-(request.getContextPath() + /html/start?path= + displayPath);
+(request.getContextPath() +
+ /html/start?path= + displayPath);
args[1] = appsStart;
args[2] = response.encodeURL
-(request.getContextPath() + /html/stop?path= + displayPath);
+(request.getContextPath() +
+ /html/stop?path= + displayPath);
args[3] = appsStop;
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/images printer.gif
glenn 2003/01/10 17:18:17 Added: webapps/tomcat-docs/images printer.gif Log: Add a printer image for when we make printer friendly docs Revision ChangesPath 1.1 jakarta-tomcat-4.0/webapps/tomcat-docs/images/printer.gif Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyoteBaseHook.java
Hi Costin, (you beat me on the proposal :-) )
what about having a concept of a chain somewhere (meaning hooks chain
(handler :-) ). This way handler doesn't need to know which comes next
(or previous), but the handler chain knows it. What I was having in mind
was being able to define somewhere:
handler-configuration
module name=org.apache.coyote
handlerChain className=org.apache.coyote.CoyoteHandlerChain
params
param
param-name key/param-name
param-value value/param-value
/param
/params
handlers
handler
className=org.apache.coyote.tomcat5.ActionHookHandler
params
param
param-name babla /param-name
param-value babla /param-value
/param
/params
/handler
/handlers
handler-chain
handler-configuration
Using that information, an HandlerChainDispatcher can generically load
that information and then instanciate the proper HandlerChain/Handler.
In the code, that will result in
public interface HandlerChain{
public void addHandler(Handler);
public void addHandler(int index, Handler);
public boolean contains(Handler);
public boolean handle(HandlerChainContext);
// remove handler(Handler)
}
public interface Handler{
public boolean handle(HandlerContext);
public void setHandlerInfo(HandlerInfo); // Same as ActionCode
public HandlerInfo getHandlerInfo(HandlerInfo);
public void init();
public void destroy()
public void recycle();
}
public interface HandlerContext(){
public Object putAttribute(String,Object);
public Object getAttribute(String);
public Map getAttributes();
public void removeAttribute(String);
public void clear();
}
Example:
[-- In CoyoteAdapter...
postParseRequest(req, request, res, response);
// Calling the container
connector.getContainer().invoke(request, response);
response.finishResponse();
req.action( ActionCode.ACTION_POST_REQUEST , null);
--]
We can easily replace those calls by something like:
...
HandlerChainContext context = new HandlerChainContext()
context.putAttribute(ACTION_POST_REQUEST);
coyoteHandlerChain.handle(context);
That will easily map to the current Pipeline/Valve architecture. We will
define basic HandlerChain (ex: AuthenticationChain, AuthorizationChain,
CoyoteChain, XercesChain (broken by default...just kidding ;-), etc.)
and then module can get inserted in those HandlerChain using something
like the xml format decribed above. A module will have to implement
Handler (or HandlerChain).
Finally, that looks like a small proposal ;-)
--Jeanfrancois
[EMAIL PROTECTED] wrote:
costin 2003/01/10 14:36:43
Added: coyote/src/java/org/apache/coyote BaseHook.java
Log:
Added a base implementation of ActionHook - with some small additions :-)
First, there is a getNext/setNext to allow multiple hooks to be chained.
Both recursive and iterative will be supported - you can call next directly or
just return it ( still need to tune this - only recursive works now )
In addition, the hook implements MBeanRegistration ( again: we did vote on
JMX dependency ). Tomcat3.3 may be a problem ( since it's using the same code),
but if someone wants to use the new connector he can also add jmx in the
path. If anyone has a problem with that - please let me know, I can hack
some conditional compilation, but I would like to keep it simple.
I'll change the 2 hook implementations to extend this after it settles down.
Feel free to make changes - or ask for changes or just say -1.
Revision ChangesPath
1.1 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
Index: BaseHook.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs realm-howto.xml
glenn 2003/01/10 17:47:13
Modified:.RELEASE-NOTES-4.1.txt
catalina/src/share/org/apache/catalina/realm JNDIRealm.java
webapps/tomcat-docs realm-howto.xml
Log:
Apply JNDIRealm patch to add alternateURL provided by Brad Handy
Revision ChangesPath
1.45 +6 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
Index: RELEASE-NOTES-4.1.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- RELEASE-NOTES-4.1.txt 10 Jan 2003 15:52:17 - 1.44
+++ RELEASE-NOTES-4.1.txt 11 Jan 2003 01:47:13 - 1.45
@@ -111,6 +111,11 @@
A new Realm implementation which can use a JNDI named JDBC
DataSource has been added.
+[4.1.19] JNDIRealm:
+ Added support for using an alternateURL if a socket connection
+ can not be made to the provider at the connectionURL.
+
+
---
Jasper New Features:
---
1.11 +115 -16
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
Index: JNDIRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JNDIRealm.java19 Nov 2002 01:26:38 - 1.10
+++ JNDIRealm.java11 Jan 2003 01:47:13 - 1.11
@@ -70,6 +70,7 @@
import java.util.Hashtable;
import java.util.List;
import javax.naming.Context;
+import javax.naming.CommunicationException;
import javax.naming.NameNotFoundException;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
@@ -98,6 +99,10 @@
* element in the top level codeDirContext/code that is accessed
* via the codeconnectionURL/code property./li
*
+ * liIf a socket connection can not be made to the codeconnectURL/code
+ * an attempt will be made to use the codealternateURL/code if it
+ * exists./li
+ *
* liEach user element has a distinguished name that can be formed by
* substituting the presented username into a pattern configured by the
* codeuserPattern/code property./li
@@ -337,6 +342,16 @@
*/
protected boolean roleSubtree = false;
+/**
+ * An alternate URL, to which, we should connect if connectionURL fails.
+ */
+protected String alternateURL;
+
+/**
+ * The number of connection attempts. If greater than zero we use the
+ * alternate url.
+ */
+protected int connectionAttempt = 0;
// - Properties
@@ -716,6 +731,28 @@
}
+/**
+ * Getter for property alternateURL.
+ *
+ * @return Value of property alternateURL.
+ */
+public String getAlternateURL() {
+
+return this.alternateURL;
+
+}
+
+/**
+ * Setter for property alternateURL.
+ *
+ * @param alternateURL New value of property alternateURL.
+ */
+public void setAlternateURL(String alternateURL) {
+
+this.alternateURL = alternateURL;
+
+}
+
// -- Realm Methods
@@ -736,15 +773,41 @@
public Principal authenticate(String username, String credentials) {
DirContext context = null;
+Principal principal = null;
try {
// Ensure that we have a directory context available
context = open();
-
-// Authenticate the specified username if possible
-Principal principal = authenticate(context,
- username, credentials);
+
+// Occassionally the directory context will timeout. Try one more
+// time before giving up.
+try {
+
+// Authenticate the specified username if possible
+principal = authenticate(context, username, credentials);
+
+} catch (CommunicationException e) {
+
+// If not a Socket closed. error then rethrow.
+if (e.getMessage().indexOf(Socket closed) 0)
+throw(e);
+
+// log the exception so we know it's there.
+log(sm.getString(jndiRealm.exception), e);
+
+// close the connection so we know it will be reopened.
+if (context
cvs commit: jakarta-tomcat-catalina/webapps/docs tomcat-docs.xsl
glenn 2003/01/10 17:52:21 Modified:webapps/docs tomcat-docs.xsl Added: webapps/docs/images printer.gif Log: Add support for generating printer friendly docs Revision ChangesPath 1.1 jakarta-tomcat-catalina/webapps/docs/images/printer.gif Binary file 1.2 +8 -6 jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl Index: tomcat-docs.xsl === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/tomcat-docs.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- tomcat-docs.xsl 18 Jul 2002 16:48:31 - 1.1 +++ tomcat-docs.xsl 11 Jan 2003 01:52:21 - 1.2 @@ -19,7 +19,7 @@ xsl:paramname=home-logoselect='/images/jakarta-logo.gif'/ xsl:paramname=relative-pathselect='.'/ xsl:paramname=void-image select='/images/void.gif'/ - + xsl:paramname=project-menu select='menu'/ !-- Defined variables (non-overrideable) -- xsl:variable name=body-bg select='#ff'/ @@ -99,10 +99,12 @@ tr -xsl:commentLEFT SIDE NAVIGATION/xsl:comment -td width=20% valign=top nowrap=true - xsl:apply-templates select=project/body/menu/ -/td +xsl:if test=$project-menu = 'menu' + xsl:commentLEFT SIDE NAVIGATION/xsl:comment + td width=20% valign=top nowrap=true +xsl:apply-templates select=project/body/menu/ + /td +/xsl:if xsl:commentRIGHT SIDE MAIN BODY/xsl:comment td width=80% valign=top align=left -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs realm-howto.xml
glenn 2003/01/10 17:57:39
Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java
webapps/docs realm-howto.xml
Log:
Port JNDIRealm alternateURL patch to Tomcat 5
Revision ChangesPath
1.4 +122 -30
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
Index: JNDIRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JNDIRealm.java19 Nov 2002 01:27:59 - 1.3
+++ JNDIRealm.java11 Jan 2003 01:57:39 - 1.4
@@ -70,6 +70,7 @@
import java.util.Hashtable;
import java.util.List;
import javax.naming.Context;
+import javax.naming.CommunicationException;
import javax.naming.NameNotFoundException;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
@@ -98,6 +99,10 @@
* element in the top level codeDirContext/code that is accessed
* via the codeconnectionURL/code property./li
*
+ * liIf a socket connection can not be made to the codeconnectURL/code
+ * an attempt will be made to use the codealternateURL/code if it
+ * exists./li
+ *
* liEach user element has a distinguished name that can be formed by
* substituting the presented username into a pattern configured by the
* codeuserPattern/code property./li
@@ -188,13 +193,11 @@
// - Instance Variables
-
/**
* The type of authentication to use
*/
protected String authentication = null;
-
/**
* The connection username for the server we will contact.
*/
@@ -244,15 +247,15 @@
* The protocol that will be used in the communication with the directory
server.
*/
protected String protocol = null;
-
-
+
+
/**
* How should we handle referrals? Microsoft Active Directory can't handle
* the default case, so an application authenticating against AD must
* set referrals to follow.
*/
protected String referrals = null;
-
+
/**
* The base element for user searches.
@@ -339,11 +342,19 @@
*/
protected boolean roleSubtree = false;
-
+/**
+ * An alternate URL, to which, we should connect if connectionURL fails.
+ */
+protected String alternateURL;
+
+/**
+ * The number of connection attempts. If greater than zero we use the
+ * alternate url.
+ */
+protected int connectionAttempt = 0;
// - Properties
-
/**
* Return the type of authentication to use.
*/
@@ -353,7 +364,6 @@
}
-
/**
* Set the type of authentication to use.
*
@@ -364,8 +374,7 @@
this.authentication = authentication;
}
-
-
+
/**
* Return the connection username for this Realm.
*/
@@ -463,7 +472,6 @@
}
-
/**
* Set the protocol for this Realm.
*
@@ -491,7 +499,7 @@
public void setReferrals (String referrals) {
this.referrals = referrals;
}
-
+
/**
* Return the base element for user searches.
@@ -723,6 +731,28 @@
}
+/**
+ * Getter for property alternateURL.
+ *
+ * @return Value of property alternateURL.
+ */
+public String getAlternateURL() {
+
+return this.alternateURL;
+
+}
+
+/**
+ * Setter for property alternateURL.
+ *
+ * @param alternateURL New value of property alternateURL.
+ */
+public void setAlternateURL(String alternateURL) {
+
+this.alternateURL = alternateURL;
+
+}
+
// -- Realm Methods
@@ -743,15 +773,41 @@
public Principal authenticate(String username, String credentials) {
DirContext context = null;
+Principal principal = null;
try {
// Ensure that we have a directory context available
context = open();
-
-// Authenticate the specified username if possible
-Principal principal = authenticate(context,
- username, credentials);
+
+// Occassionally the directory context will timeout. Try one more
+// time before giving up.
+try {
+
+//
Re: JNDIRealm feature enhancements
I have applied your patch and updated the realm-howto.xml docs in both Tomcat 4 and Tomcat 5. Thanks for the patch. Glenn Bradley M. Handy wrote: After setting up a JNDIRealm for the Manager app, I noticed after a while the connection times out and returns NULL automatically. I was wondering, if instead of returning NULL, JNDIRealm to try to reconnect and then authenticate, and then return NULL, if a failure results from that attempt, otherwise return the JNDIRealm.User object. Also I?ve notice there is no method for specifying an alternate connection URL in the event the URL specified in connectionURL is not available. So, I took the liberty of adding an attribute ?alternateURL? to specify a secondary URL. When the JNDIRealm opens a connection it will attempt the primary, and, upon failure, then attempt to connect to the alternate URL. If this should fail, the JNDIRealm fails as it did before. In both features the first exception is logged before the second attempt to connect proceeds. I have attached the CVS diff between my copy of JNDIRealm and the current HEAD version of JNDIRealm. Brad Handy Programmer/Analyst Spring Arbor University -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs realm-howto.xml
glenn 2003/01/10 18:02:20 Modified:webapps/docs realm-howto.xml Log: Port addition of menu to realm docs Revision ChangesPath 1.6 +29 -0 jakarta-tomcat-catalina/webapps/docs/realm-howto.xml Index: realm-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/realm-howto.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- realm-howto.xml 11 Jan 2003 01:57:39 - 1.5 +++ realm-howto.xml 11 Jan 2003 02:02:20 - 1.6 @@ -14,6 +14,32 @@ body +section name=Table of Contents + +p +a href=#Quick StartQuick Start/abr / +blockquote +a href=#What is a Realm?What is a Realm?/abr / +a href=#Configuring a RealmConfiguring a Realm/abr / +/blockquote +a href=#Standard Realm Implementations +Standard Realm Implementations/abr / +blockquote +a href=#JDBCRealmJDBCRealm/abr / +a href=#DataSourceRealmDataSourceRealm/abr / +a href=#JNDIRealmJNDIRealm/abr / +a href=#MemoryRealmMemoryRealm/abr / +/blockquote +a href=#Common FeaturesCommon Features/abr / +blockquote +a href=#Digested PasswordsDigested Passwords/abr / +a href=#Example ApplicationExample Application/abr / +a href=#Manager ApplicationManager Application/abr / +/blockquote +/p + +/section + section name=Quick Start pThis document describes how to configure Tomcat to support emcontainer @@ -66,6 +92,9 @@ Three standard plug-ins are provided, supporting connection to three different sources of authentication information:/p ul +lia href=#DataSourceRealmDataSourceRealm/a - Accesses authentication +information stored in a relational database, accessed via a named JNDI +JDBC DataSource./li lia href=#JDBCRealmJDBCRealm/a - Accesses authentication information stored in a relational database, accessed via a JDBC driver./li lia href=#JNDIRealmJNDIRealm/a - Accesses authentication information -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session LocalStrings.properties LocalStrings_fr.properties StandardSession.java
jfarcand2003/01/10 18:50:06
Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties LocalStrings_fr.properties
StandardSession.java
Log:
According to the javadocs for HttpSession.getLastAccessedTime(), and
IllegalStateException will be thrown if the session has been invalidated.
PR: Bugzilla #15967
Revision ChangesPath
1.3 +1 -0
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LocalStrings.properties 31 Dec 2002 12:54:04 - 1.2
+++ LocalStrings.properties 11 Jan 2003 02:50:06 - 1.3
@@ -39,6 +39,7 @@
standardSession.getAttribute.ise=getAttribute: Session already invalidated
standardSession.getAttributeNames.ise=getAttributeNames: Session already invalidated
standardSession.getCreationTime.ise=getCreationTime: Session already invalidated
+standardSession.getLastAccessedTime.ise=getLastAccessedTime: Session already
invalidated
standardSession.getMaxInactiveInterval.ise=getMaxInactiveInterval: Session already
invalidated
standardSession.getValueNames.ise=getAttributeNames: Session already invalidated
standardSession.notSerializable=Cannot serialize session attribute {0} for session
{1}
1.3 +2 -0
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings_fr.properties
Index: LocalStrings_fr.properties
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings_fr.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LocalStrings_fr.properties31 Dec 2002 12:54:04 - 1.2
+++ LocalStrings_fr.properties11 Jan 2003 02:50:06 - 1.3
@@ -61,3 +61,5 @@
persistentManager.processSwaps=Recherche de sessions à basculer vers stockage (swap
out), {0} sessions actives en mémoire
persistentManager.activeSession=La session {0} a été en attente durant {1} secondes
persistentManager.swapIn=Basculement depuis le stockage (swap in) de la session {0}
+
+standardSession.getLastAccessedTime.ise=getLastAccessedTime: Session
d\u00E9j\u00E0 invalid\u00E9e
1.11 +8 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- StandardSession.java 31 Dec 2002 12:53:45 - 1.10
+++ StandardSession.java 11 Jan 2003 02:50:06 - 1.11
@@ -441,7 +441,11 @@
* a value associated with the session, do not affect the access time.
*/
public long getLastAccessedTime() {
+if ( !isValid ) {
+throw new IllegalStateException(
+sm.getString(standardSession.getLastAccessedTime));
+}
return (this.lastAccessedTime);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15967] - IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated.
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=15967. 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=15967 IllegalStateException not thrown by HttpSession.getLastAccessedTime() if session has been invalidated. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-11 02:51 --- I have added the proper exception. Thanks :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java
billbarker2003/01/10 19:00:07
Modified:src/share/org/apache/tomcat/core Request.java
Log:
Make certain that the session still belong to us before returning it.
If the Servlet invalidates the session, and then later requests a new one, it is
possible for the one we have to be valid because it is now being used by somebody
else. Thus we have to make certain that it still belongs to us before returning it.
Real Fix for bug #15894
Reported By: Christian Wicke [EMAIL PROTECTED]
Revision ChangesPath
1.116 +2 -0 jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.115
retrieving revision 1.116
diff -u -r1.115 -r1.116
--- Request.java 27 Apr 2002 03:45:18 - 1.115
+++ Request.java 11 Jan 2003 03:00:06 - 1.116
@@ -714,6 +714,8 @@
public ServerSession getSession(boolean create) {
if (serverSession!=null !serverSession.isValid())
serverSession=null;
+ if (serverSession != null !serverSession.getId().equals(sessionId) )
+ serverSession=null;
if( ! create || serverSession!=null )
return serverSession;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
Jeanfrancois Arcand wrote:
Hi Costin, (you beat me on the proposal :-) )
Actually - this is a different story ( JMX-enabling different componets).
I'll check in similar additions to ValveBase, BaseContainer,
CoyoteConnector.
The idea is for each component to be aware of its name and domain,
and to bridge whatever notification/hook mechanism into JMX
notifications.
I don't think we need an additional extension mechansim - for all
that I need I think JMX notifications are good enough. I don't
know how hard ( or usefull ) it is to bridge all existing extension
points, but at least the connector should be able to send JMX notifications
and it can easily use this model for its own needs.
what about having a concept of a chain somewhere (meaning hooks chain
(handler :-) ). This way handler doesn't need to know which comes next
(or previous), but the handler chain knows it. What I was having in mind
was being able to define somewhere:
I'm ok with that too. Valves have a Next - and I assumed many people
preffer this model ( and it involves fewer interfaces :-).
My only requirement is to be able to use it in iterative mode too
( I don't like the long stack traces and I feel better with iterative).
For configuration: I would be -1 for any new API / tomcat-specific config
format.
All configuration should be done using JMX. I have no doubt about
it ( well, JMX has its limitations, but the general model of
manageable components with light coupling is essential ).
Instead of param-name/value - use JMX attributes. The handler is a JMX
component. For registration - I think we should use the standard JMX
notifications ( or your proposed API if JMX proves too complicated or
we can't get around its limitations )
We could use a Chain MBean component where you declare ( as attributes )
the various hooks in the chain. ActionCode will correspond to a Chain.
That may be very nice - allowing hooks to be inserted at runtime, etc.
handler-configuration
module name=org.apache.coyote
...
handler-chain
handler-configuration
Using that information, an HandlerChainDispatcher can generically load
that information and then instanciate the proper HandlerChain/Handler.
In the code, that will result in
public interface HandlerChain{
public void addHandler(Handler);
public void addHandler(int index, Handler);
public boolean contains(Handler);
public boolean handle(HandlerChainContext);
// remove handler(Handler)
}
+0 - sounds good, but I would rather use NotificationBroadcaster :-)
( or some specialized version in modeler - to get around Filters ).
public interface Handler{
public boolean handle(HandlerContext);
public void setHandlerInfo(HandlerInfo); // Same as ActionCode
public HandlerInfo getHandlerInfo(HandlerInfo);
public void init();
public void destroy()
public void recycle();
}
Again - I would rather use
interface javax.management.NotificationListener {
handleNotification( Notification n, Object handBack );
}
And normal JMX for init/destroy/etc.
public interface HandlerContext(){
public Object putAttribute(String,Object);
public Object getAttribute(String);
public Map getAttributes();
public void removeAttribute(String);
public void clear();
}
That's a tricky one - besides String-based attributes
I think we need to use the notes ( i.e. index based ).
But I think the HandlerContext should just be an instance
of Notification ( with added notes and an int notification
code for faster dispatch ).
Finally, that looks like a small proposal ;-)
My preference is to try to just use JMX.
It is not perfect - but I think it's good enough and we'll
benefit more by using a standard and well-known API.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
Dirk-Willem van Gulik wrote: On 10 Jan 2003, Eric Rescorla wrote: There's nothing wrong with what you propose, but it's sort of like saying maybe I should wear a helmet at all times because a meteor might drop on my head. Sure, it could happen, btu it's not the thing I'd worry about. Except that hash( i++ . secret).i is generally a lot cheaper and easier to code cross platform than using a true cryptographic random generator with the right tie in with hardware. And it happens to have a hard-hat aspect thrown in as a freebee. Dw Unfortunately, hashing blows away guaranteed uniqueness (one-way = not 1-1), so if your last step is a hash, you will need to keep the meteor helmets handy. The uniqueness bits need to be either left alone or encrypted to preserve uniqueness of the result. I strongly agree with Eric, however, that it is *incredibly* unlikely that the multiple reports of apparent collisions are in fact due to Tomcat's (unpatched) session key generation algorithm. I ran some tests last year on an algorithm very similar to what Tomcat uses (using SHA-1 instead of MD5 after adding some other stuff to the bytes from SecureRandom) and I found that the empirical probablility distribution of the number of matching bytes in pairs of generated strings followed the expected binomial distribution almost exactly. Among other things, this implies that the probability of an exact match among two such strings really is 1/2^n where n is the number of bits in the strings. It also supports the expectation that if you generate m strings, the probability that any two of them are identical is less than C(m,2)/2^n (where C(m,2) = m(m-1)/2 -- the number of pairs that you can make among the m strings). To illustrate how silly the helmets look, here are some examples: n = 128, m = 1 = p(collision) 1.5 E-31 n = 128, m = 10 = p(collision) 1.5 E-29 n = 128, m = 100 = p(collision) 1.5 E-27 n = 64, m = 100 = p(collision) 2.7 E-8 ... n = 128, m = 2^64 ~ 3.4 E+38 = p(collision) .5 (Eric's reasonable chance threshold) If end users are reporting session collisions, this means that they must be happening with frequency too large to reasonably attribute to chance. Therefore, either the applications or Tomcat itself must have some concurrency problems independent of the session ID generation. -Phil -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 10, 2003 8:16 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
Jeanfrancois Arcand wrote:
Hi Costin, (you beat me on the proposal :-) )
Actually - this is a different story ( JMX-enabling different componets).
I'll check in similar additions to ValveBase, BaseContainer,
CoyoteConnector.
I currently have custom Valves in 4.1.x that *don't* extend ValveBase (I
feel strongly that my code shouldn't depend on anything other than
o.a.catalina), which work quite well with JMX. I'd really hate to lose
this for 5.x.
Of course, the current JDK1.4.x dependency of 5.x prevents me from even
thinking about using it ;-).
The idea is for each component to be aware of its name and domain,
and to bridge whatever notification/hook mechanism into JMX
notifications.
I don't think we need an additional extension mechansim - for all
that I need I think JMX notifications are good enough. I don't
know how hard ( or usefull ) it is to bridge all existing extension
points, but at least the connector should be able to send JMX
notifications
and it can easily use this model for its own needs.
what about having a concept of a chain somewhere (meaning hooks chain
(handler :-) ). This way handler doesn't need to know which comes next
(or previous), but the handler chain knows it. What I was having in mind
was being able to define somewhere:
I'm ok with that too. Valves have a Next - and I assumed many people
preffer this model ( and it involves fewer interfaces :-).
My only requirement is to be able to use it in iterative mode too
( I don't like the long stack traces and I feel better with iterative).
For configuration: I would be -1 for any new API / tomcat-specific config
format.
All configuration should be done using JMX. I have no doubt about
it ( well, JMX has its limitations, but the general model of
manageable components with light coupling is essential ).
Instead of param-name/value - use JMX attributes. The handler is a JMX
component. For registration - I think we should use the standard JMX
notifications ( or your proposed API if JMX proves too complicated or
we can't get around its limitations )
We could use a Chain MBean component where you declare ( as attributes )
the various hooks in the chain. ActionCode will correspond to a Chain.
That may be very nice - allowing hooks to be inserted at runtime, etc.
handler-configuration
module name=org.apache.coyote
...
handler-chain
handler-configuration
Using that information, an HandlerChainDispatcher can generically load
that information and then instanciate the proper HandlerChain/Handler.
In the code, that will result in
public interface HandlerChain{
public void addHandler(Handler);
public void addHandler(int index, Handler);
public boolean contains(Handler);
public boolean handle(HandlerChainContext);
// remove handler(Handler)
}
+0 - sounds good, but I would rather use NotificationBroadcaster :-)
( or some specialized version in modeler - to get around Filters ).
public interface Handler{
public boolean handle(HandlerContext);
public void setHandlerInfo(HandlerInfo); // Same as ActionCode
public HandlerInfo getHandlerInfo(HandlerInfo);
public void init();
public void destroy()
public void recycle();
}
Again - I would rather use
interface javax.management.NotificationListener {
handleNotification( Notification n, Object handBack );
}
And normal JMX for init/destroy/etc.
public interface HandlerContext(){
public Object putAttribute(String,Object);
public Object getAttribute(String);
public Map getAttributes();
public void removeAttribute(String);
public void clear();
}
That's a tricky one - besides String-based attributes
I think we need to use the notes ( i.e. index based ).
But I think the HandlerContext should just be an instance
of Notification ( with added notes and an int notification
code for faster dispatch ).
Finally, that looks like a small proposal ;-)
My preference is to try to just use JMX.
It is not perfect - but I think it's good enough and we'll
benefit more by using a standard and well-known API.
Costin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSR77 names for Context ( and ServletWrapper )
I'm not very familiar with the /admin - how difficult would it be to change the naming format for Contexts ? JSR77 defines some pretty clear names for Context and Servet - and I think we should use that where possible. Another issue I have is the name of the Valves, which uses the hashcode of the valve object. I would preffer to have an easier form - a counter indicating the position of the valve in the chain ( unique for the container where the valve is attached ). Again - need help with the /admin. Finally, the issue of domain. In JSR77 ( and in general ) the domain can be used to create separate namespaces - and I think the domain should match the engine name and the jsrRoute. That would simplify a lot: - a domain represents a particular tomcat Engine. - each engine must have a unique identifier - this will be used for load balancing ( as jvmRoute - no longer separate config ) - it will also be visible in the JMX console. Assuming remote-JMX is supported - each tomcat will be visible in a separate domain. - you can have multiple Engines in the same VM ( just like today ), but each will have a separate domain and will be completely separated from each other. Not sure if the /admin is using the domain somehere. Opinions ? Anyone willing to help ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ContainerBase.java
costin 2003/01/10 21:07:50
Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java
Log:
Let ContainerBase know its own name ( and domain )
We can't change the Container interface ( that would break backward
compat ), but there is no need - all tomcat containers extend
ContainerBase and external containers can do their own JMX interaction.
Revision ChangesPath
1.3 +51 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
Index: ContainerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ContainerBase.java5 Nov 2002 21:31:14 - 1.2
+++ ContainerBase.java11 Jan 2003 05:07:50 - 1.3
@@ -1,8 +1,4 @@
/*
- * $Header$
- * $Revision$
- * $Date$
- *
*
*
* The Apache Software License, Version 1.1
@@ -76,13 +72,16 @@
import java.util.Iterator;
import javax.servlet.ServletException;
import javax.naming.directory.DirContext;
+import javax.management.ObjectName;
+import javax.management.MBeanRegistration;
+import javax.management.MBeanServer;
+
import org.apache.naming.resources.ProxyDirContext;
import org.apache.catalina.Cluster;
import org.apache.catalina.Container;
import org.apache.catalina.ContainerEvent;
import org.apache.catalina.ContainerListener;
import org.apache.catalina.Lifecycle;
-import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Loader;
@@ -160,8 +159,10 @@
*/
public abstract class ContainerBase
-implements Container, Lifecycle, Pipeline {
+implements Container, Lifecycle, Pipeline, MBeanRegistration {
+private static org.apache.commons.logging.Log log=
+org.apache.commons.logging.LogFactory.getLog( ContainerBase.class );
/**
* Perform addChild with the permissions of this class.
@@ -1460,7 +1461,48 @@
}
-private static org.apache.commons.logging.Log log=
-org.apache.commons.logging.LogFactory.getLog( ContainerBase.class );
+// JMX and Registration
+protected String domain;
+protected String suffix;
+protected ObjectName oname;
+protected MBeanServer mserver;
+
+public ObjectName getObjectName() {
+return oname;
+}
+
+public String getDomain() {
+return domain;
+}
+
+public String getJSR77Suffix() {
+return suffix;
+}
+
+public ObjectName preRegister(MBeanServer server,
+ ObjectName name) throws Exception {
+oname=name;
+mserver=server;
+domain=name.getDomain();
+String j2eeApp=name.getKeyProperty(J2EEApplication);
+String j2eeServer=name.getKeyProperty(J2EEServer);
+if( j2eeApp==null ) {
+j2eeApp=none;
+}
+if( j2eeServer==null ) {
+j2eeServer=none;
+}
+suffix=,J2EEApplication= + j2eeApp + ,J2EEServer= + j2eeServer;
+return name;
+}
+
+public void postRegister(Boolean registrationDone) {
+}
+
+public void preDeregister() throws Exception {
+}
+
+public void postDeregister() {
+}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves AccessLogValve.java
costin 2003/01/10 21:12:48
Modified:catalina/src/share/org/apache/catalina/valves
AccessLogValve.java
Log:
I did that long ago - it just add %D to display the time in millis
( like in apache )
Usefull for people with fast servlets :-)
Revision ChangesPath
1.3 +13 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java
Index: AccessLogValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AccessLogValve.java 22 Nov 2002 22:23:44 - 1.2
+++ AccessLogValve.java 11 Jan 2003 05:12:48 - 1.3
@@ -118,7 +118,8 @@
* lib%u/b - Remote user that was authenticated
* lib%U/b - Requested URL path
* lib%v/b - Local server name
- * /ul
+ * lib%D/b - Time taken to process the request, in millis
+ * /ul
* pIn addition, the caller can specify one of the following aliases for
* commonly utilized patterns:/p
* ul
@@ -506,8 +507,13 @@
throws IOException, ServletException {
// Pass this request on to the next valve in our pipeline
+long t1=System.currentTimeMillis();
+
context.invokeNext(request, response);
+long t2=System.currentTimeMillis();
+long time=t2-t1;
+
Date date = getDate();
StringBuffer result = new StringBuffer();
@@ -617,10 +623,10 @@
} else {
//D'oh - end of string - pretend we never did this
//and do processing the old way
-result.append(replace(ch, date, request, response));
+result.append(replace(ch, date, request, response,
time));
}
} else {
-result.append(replace(ch, date, request, response));
+result.append(replace(ch, date, request, response,time ));
}
replace = false;
} else if (ch == '%') {
@@ -756,7 +762,7 @@
* @param response Response being processed
*/
private String replace(char pattern, Date date, Request request,
- Response response) {
+ Response response, long time) {
String value = null;
@@ -798,6 +804,8 @@
value = ;
} else if (pattern == 'p') {
value = + req.getServerPort();
+} else if (pattern == 'D') {
+value = + time;
} else if (pattern == 'q') {
String query = null;
if (hreq != null)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
Bill Barker wrote: Jeanfrancois Arcand wrote: Hi Costin, (you beat me on the proposal :-) ) Actually - this is a different story ( JMX-enabling different componets). I'll check in similar additions to ValveBase, BaseContainer, CoyoteConnector. I currently have custom Valves in 4.1.x that *don't* extend ValveBase (I feel strongly that my code shouldn't depend on anything other than o.a.catalina), which work quite well with JMX. I'd really hate to lose this for 5.x. I think it's ok. You can either implement MBeanRegistration - or just do nothing. The main purpose of this addition is to have a consistent getObjectName and getDomain, as well as access to the mbean server. I would also like to use the attributes from the name - and attach the valve to the right component in preRegister(). Not sure if it's worth it - but it could be usefull. The problem with interfaces is that if you add a method, all implementations will need to be changed. Of course, the current JDK1.4.x dependency of 5.x prevents me from even thinking about using it ;-). Do we still have a 1.4 dependency ? We should fix that. I just run it with JDK1.3 - and seemed fine. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPoolMX.java
costin 2003/01/10 22:52:27
Added: util/java/org/apache/tomcat/util/threads ThreadPoolMX.java
Log:
Added a JMX extension to threadpool.
This will keep the ThreadPool independent of JMX.
Also added few informative methods to display the threads and
the status of each thread. ( I need to commit few changes in
http and jk connector to take provide this info )
Revision ChangesPath
1.1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoolMX.java
Index: ThreadPoolMX.java
===
/*
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.util.threads;
import java.util.*;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.commons.modeler.Registry;
/**
* Manageable thread pool
*
* @author Costin Manolache
*/
public class ThreadPoolMX extends ThreadPool {
static Log log = LogFactory.getLog(ThreadPoolMX.class);
Registry reg;
protected String domain;
protected String name;
public ThreadPoolMX() {
super();
}
public void setDomain(String domain) {
this.domain=domain;
}
public String getDomain() {
return domain;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name=name;
reg=Registry.getRegistry();
try {
reg.registerComponent(this, domain, ThreadPool,
name= + name);
} catch( Exception ex ) {
log.error( Error registering thread pool, ex );
}
}
public synchronized void start() {
super.start();
}
public void addThread( Thread t, ControlRunnable cr ) {
threads.put( t, cr );
for( int i=0; ilisteners.size(); i++ ) {
ThreadPoolListener tpl=(ThreadPoolListener)listeners.elementAt(i);
tpl.threadStart(this, t);
}
}
public void removeThread( Thread t ) {
threads.remove(t);
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadWithAttributes.java
costin 2003/01/10 22:53:43
Added: util/java/org/apache/tomcat/util/threads
ThreadWithAttributes.java
Log:
Moved ThreadWithAttribute out of ThreadPool.
All attribute operations are guarded by ThreadPool - if an application
has a reference to ThreadPool, it can get/set attributes.
The cost is one cast and a method access.
Revision ChangesPath
1.1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadWithAttributes.java
Index: ThreadWithAttributes.java
===
package org.apache.tomcat.util.threads;
import java.util.Hashtable;
/** Special thread that allows storing of attributes and notes.
* A guard is used to prevent untrusted code from accessing the
* attributes.
*
* This avoids hash lookups and provide something very similar
* with ThreadLocal ( but compatible with JDK1.1 and faster on
* JDK 1.4 ).
*
* The main use is to store 'state' for monitoring ( like processing
* request 'GET /' ).
*/
public class ThreadWithAttributes extends Thread {
private Object control;
public static int MAX_NOTES=16;
private Object notes[]=new Object[MAX_NOTES];
private Hashtable attributes=new Hashtable();
private String currentStage;
private Object param;
public ThreadWithAttributes(Object control, Runnable r) {
super(r);
this.control=control;
}
/** Notes - for attributes that need fast access ( array )
* The application is responsible for id management
*/
public final void setNote( Object control, int id, Object value ) {
if( this.control != control ) return;
notes[id]=value;
}
/** Information about the curent performed operation
*/
public final String getCurrentStage(Object control) {
if( this.control != control ) return null;
return currentStage;
}
/** Information about the current request ( or the main object
* we are processing )
*/
public final Object getParam(Object control) {
if( this.control != control ) return null;
return param;
}
public final void setCurrentStage(Object control, String currentStage) {
if( this.control != control ) return;
this.currentStage = currentStage;
}
public final void setParam( Object control, Object param ) {
if( this.control != control ) return;
this.param=param;
}
public final Object getNote(Object control, int id ) {
if( this.control != control ) return null;
return notes[id];
}
/** Generic attributes. You'll need a hashtable lookup -
* you can use notes for array access.
*/
public final Hashtable getAttributes(Object control) {
return attributes;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
costin 2003/01/10 22:55:24
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
Update ThreadPool.
Revision ChangesPath
1.7 +20 -51
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ThreadPool.java 24 Dec 2002 17:02:54 - 1.6
+++ ThreadPool.java 11 Jan 2003 06:55:24 - 1.7
@@ -147,6 +147,18 @@
stopThePool = false;
}
+
+public static ThreadPool createThreadPool() {
+try {
+Class.forName( org.apache.commons.modeler.Registry);
+Class tpc=Class.forName( org.apache.tomcat.util.threads.ThreadPoolMX);
+ThreadPool res=(ThreadPool)tpc.newInstance();
+return res;
+} catch( Exception ex ) {
+}
+return new ThreadPool();
+}
+
public synchronized void start() {
stopThePool=false;
currentThreadCount = 0;
@@ -295,7 +307,7 @@
}
}
-// If we are here it means that there is a free thred. Take it.
+// If we are here it means that there is a free thread. Take it.
c = pool[currentThreadCount - currentThreadsBusy - 1];
currentThreadsBusy++;
}
@@ -371,7 +383,9 @@
return;
}
+// atomic
currentThreadsBusy--;
+
pool[currentThreadCount - currentThreadsBusy - 1] = c;
notify();
}
@@ -424,6 +438,10 @@
}
}
+/** Create missing threads.
+ *
+ * @param toOpen Total number of threads we'll have open
+ */
protected void openThreads(int toOpen) {
if(toOpen maxThreads) {
@@ -636,10 +654,7 @@
* @param toRun
*/
public synchronized void runIt(ThreadPoolRunnable toRun) {
- if( toRun == null ) {
- throw new NullPointerException(No Runnable);
- }
-this.toRun = toRun;
+ this.toRun = toRun;
// Do not re-init, the whole idea is to run init only once per
// thread - the pool is supposed to run a single task, that is
// initialized once.
@@ -659,52 +674,6 @@
public synchronized void terminate() {
shouldTerminate = true;
this.notify();
-}
-}
-
-/** Special thread that allows storing of attributes and notes.
- * A guard is used to prevent untrusted code from accessing the
- * attributes.
- *
- * This avoids hash lookups and provide something very similar
- * with ThreadLocal ( but compatible with JDK1.1 and faster on
- * JDK 1.4 ).
- *
- * The main use is to store 'state' for monitoring ( like processing
- * request 'GET /' ).
- */
-public static class ThreadWithAttributes extends Thread {
-private Object control;
-public static int MAX_NOTES=16;
-private Object notes[]=new Object[MAX_NOTES];
-private Hashtable attributes=new Hashtable();
-private String currentStage;
-
-public ThreadWithAttributes(Object control, Runnable r) {
-super(r);
-this.control=control;
-}
-
-public void setNote( Object control, int id, Object value ) {
-if( this.control != control ) return;
-notes[id]=value;
-}
-
-public String getCurrentStage() {
-return currentStage;
-}
-
-public void setCurrentStage(String currentStage) {
-this.currentStage = currentStage;
-}
-
-public Object getNote(Object control, int id ) {
-if( this.control != control ) return null;
-return notes[id];
-}
-
-public Hashtable getAttributes(Object control) {
-return attributes;
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java
costin 2003/01/10 23:08:33
Modified:coyote/src/java/org/apache/coyote BaseHook.java
Log:
Added NotificationListener.
JMX notifications are not as flexible - I really don't know
what is the best solution here. Less flexibility might be very
good - it can keep things simpler.
I'll add a BaseNotification to modeler - with an int code,
notes, etc. And then I'll try to find a way to use standard
notifications side-by-side with the native mechanism ( ActionCode ).
Opinions ?? I'm not very sure...
Revision ChangesPath
1.2 +26 -4
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java
Index: BaseHook.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/BaseHook.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- BaseHook.java 10 Jan 2003 22:36:43 - 1.1
+++ BaseHook.java 11 Jan 2003 07:08:33 - 1.2
@@ -61,6 +61,8 @@
import javax.management.MBeanRegistration;
import javax.management.ObjectName;
import javax.management.MBeanServer;
+import javax.management.NotificationListener;
+import javax.management.Notification;
/**
@@ -69,21 +71,33 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class BaseHook implements ActionHook, MBeanRegistration {
+public class BaseHook
+implements ActionHook, MBeanRegistration, NotificationListener
+ {
protected BaseHook next;
/**
+ * XXX DO WE REALLY NEED THIS ? handleNotification should be enough !!
+ *
* Send an action to the connector.
* Both recursive and iterative invocation is possible - the
* hook may call itself the next hook ( like catalina ) or the
* controller may call the next.
- *
+ *
+ * The call pattern for this is:
+ * while( hook!=null ) {
+ * hook=action( code, param );
+ * }
+ * If the hooks has special needs - it can call next itself and decide
+ * to return null or whatever the next hook returned.
+ *
+ * The reason for iterative calls - smaller stacks ( and stack traces ).
+ *
* @param param Action parameter
* @return A hook that can be executed next.
*/
public BaseHook action(int code, Object param) {
-if( next==null ) return next;
-return next.action( code, param );
+return next;
};
/** Backward compat
@@ -134,5 +148,13 @@
public void postDeregister() {
}
+// Notification listener
+
+public void handleNotification(Notification notification, Object handback) {
+// we need a special CoyoteNotification that will include the code
+// and param.
+
+// It would be better to use a generic class in modeler.
+}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors KEYS
mturk 2003/01/10 23:59:11 Modified:.KEYS Log: Change my PGP Signing key Revision ChangesPath 1.10 +27 -27jakarta-tomcat-connectors/KEYS Index: KEYS === RCS file: /home/cvs/jakarta-tomcat-connectors/KEYS,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- KEYS 27 Nov 2002 08:20:30 - 1.9 +++ KEYS 11 Jan 2003 07:59:11 - 1.10 @@ -166,35 +166,35 @@ -END PGP PUBLIC KEY BLOCK- Type Bits/KeyID Date User ID -pub 1024D/881EBC94 2002/11/27 Mladen Turk [EMAIL PROTECTED] +pub 1024D/564C17A3 2003-01-11 Mladen Turk [EMAIL PROTECTED] -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.0.6 (MingW32) -mQGiBD3kfmsRBAD02S+HNaMX+TNdMIFs1PEEwSBOxoFd8Mh51nt8eS5Kp9+v747Q -lQIUPgmhOWWQa33HGapTe3b9CQuc9mGf1eR0NyRK5S2hjoYkEb7oPVNL5PMDcJ5M -uwBSU7pG1LossNUuhsTgEQdFR4gci+ElPilQtUriv1O579YkNNVwRDUBtwCg9fcq -DNvStKj67bvzGIRrr99w2MMEAOxCHKBd69uFzPkL0+7lFoJY/IyW6xJaCXWQGE8g -P9ZgWtfYDLliuUhsmGP10JxuAYEOk3cMGy84a7ez589GWqGXXutpJmX3lY/cr8G+ -fyIT0MWxCDkKpyxz5k3XaCYigKbxrrJ+HhP7R9cZsC9kj18q9mWdku24sLEdhA+g -ewNcBADPghjTG6HOFCJb3xS6r3dbI3JVREyVPOSCWJY+A6RrRHfY4Ohw0zTt9zLi -OpuBdrpNE64bh3ftQhXg33A61fdJ19WS6YJ2WdwKlQtUiA60m8/D9qAwebuJ+1yM -LaUw3UUA5c38BiOgGND3bQp09fOR/JL5rYMopnZngByokc1AwbQ9TWxhZGVuIFR1 -cmsgKE1sYWRlbiBUdXJrIFNpZ25pbmcgS2V5KSA8bXR1cmtAbWFwcGluZ3NvZnQu -Y29tPohdBBMRAgAdBQI95H5rBQkSz/eABQsHCgMEAxUDAgMWAgECF4AACgkQ0gmc -8IgevJSonACfRTku5Y3bBbpG7stbMv2TiojjKxAAoJq170XCq4kvBiJHhfqcKL0v -v9c9uQINBD3kfngQCADen9IZs4qYqkBZ0Hq3Qk0sMClrsSBnh6bKYXUlmjb3YMo8 -i9m7CiwYIowElHvBRBw/0KFWIvwGAk2hcRuSN6nmR3Lnt8iw9Q68zJBAN8SeD0FP -pQ2Riv9tKeVfQyyOt4hzANLGV2JTk47eOrIyAskRfgR2RdMv5sn/gv8LjDBTE7rE -X4UW1xrtHI9mLQ7kbPLErLBA03S3HZX/dZQUF7+rd1oZYIfo54SgCu3YWwCA1zqb -fQXjcKjgRBf62AlvDAjHdVDGd9uGU8w64zs8yyQSFM0mJ91Gn3YUE2qEF7yV7NKT -fgiSTXlCWCp/IRQBwSj9qhbt08zbE9/LLfLD4ZMvAAMHCADCPYBsfyRdYdoeruFw -4Zf5Vh14jzHH2PJmKQgEmgIEMIAaU6vU/skHMFz9e7NXCBS7YXkjG6trLG/BGb7R -kI/lZpIQ9za/NeHQuxaOHCJuP9vcNpjeSWToF40C39Bdnu6I6Lf68DJQo5zxqfnD -XBRXQEB62S9irNEn/BP5pXjPrqWBJEkUVo/JnEDL+ljUfYXR1oqul35pvVa2XOrV -0VsWkkEQn/ZmYhmnt+HDWmne+CZi8N9n6uoO9YZSMneBIBbN7j8SFlzmrXLZlwRU -sPE74k9kxWWSvvIX+JZVs03oRARrNbVvoArWSlWPhGmqgva3N04m+sWYECfFWU68 -YB2OiEwEGBECAAwFAj3kfngFCRLP94AACgkQ0gmc8IgevJT9PACfZbZeXuiTvTWc -ECLcb/hHsrA+NEMAoOvwi2DsvrSry/4HC6WaNx7xlIes -=PiR7 +mQGiBD4fwXIRBAC7WRS8PYxi2YH0T1mX4HCYsF8aHoqxBzMnyFR4J896m1s96vGM +BTSAwH2NKbiVqtfLokTbQkUVxtrgrF2HMB5NfYBg/JzT7pZL/Q2ThWUS7SJQQA4f +a7/DpiLiHalp6iX45om6JTdIWEyXv26csIVhmtlkGBEPRhNRX8X4//BM0wCg7wcA +yQ7c5NmoOJLVs+uHsRrnHo0D/R/dMyuWt7/o0eGIEuRlDl2q+YL8xLuVyJMXQBnd +jo7jKpQ+Q1zl93aVTzsJa7mP2zZ7jqaJ855sdz6rvwyhGF1/qYMtm6zrmgBy2XPm +J+57sfwSZr0bhIeMpCWjIw98z9sObq0v2r2oA3+J9E3Na/BZsCVTZVb3ew7ILmEp +F5D7A/4zvjY41dakCAJsD1Xo8TS6hSqJf4zq9vX3ayJVvUjeo8n4sHNOwcbEnnui +9zZaUH3F0x+3cDo7mS1Y4pD8THuqCZoSbSkiHnlved6nLXsKbqvVrVo+esEhfZCn +Iji3gp+2TVNwdHXGM+4BAzMJCLsdXjByO6SNzB9a+H8RsRlZKrQ8TWxhZGVuIFR1 +cmsgKCoqKiBERUZBVUxUIFNJR05JTkcgS0VZICoqKikgPG10dXJrQGFwYWNoZS5v +cmc+iF0EExECAB0FAj4fwXIFCRLP94AFCwcKAwQDFQMCAxYCAQIXgAAKCRAcUGQH +VkwXo0jxAKCgHzXPIB4IAgoD7GMAohPQfX7j2QCeL6pAsf4pPufmPvbrrpDp6rQH +GOS5Ag0EPh/BhhAIAKWzq7+/+nNYGpc7sXGkDNo9xncxcx/KbbJVT0rBteuaonQ4 +vYar1ITjIhOPmF9yPmpUddNrqgQTSO+Or+ZrVOndn+qC1gdY3qpKIN3KTjXloW38 +0Y84ezwdRLznQNkhgXwNcB55l/Z9kLaW2MS8CJzOuYSQT1CYbXg7XP3684ZmV1KC +cGgcUt9VkIGqwsa2RFDNGvMbySedSkJ/70Q+PJlkXN+W86f8hi3HTjw2MCkNa5NL ++Byg8FEAm95YWrO6kCY3qaJYV7NRt9oVd+2V/NNzwYp3Or/QoYofvfNerupfwBmU +GEXPyZCqqNH6nDv6chscsWvEA9KzhsWnsdKhmHsAAwUH/R6LwfWgtpaO42dQI4ZS +VRBmCeWrXCuyVk0d13Yz0xLi5Z5m4g3MON3d+cRVUiyNX+hbDGpi2mkbsnL559Ef +iqmzDmSz5GQHDutolhOPtLxLrC537ODn2q7hnYQwIQYYIUtYD5sYlzfGYC8olGCB +IcKIdlGRWcxxiFCIJm5CX/jnSBsyDRpanlSrdkxhzAGsifqj4NQ19ayoeNoZg2ZP +9SLIY7vbmOxJeHEYkx8AG25xOY1PLotb/0buSXPB8e71zb/DCV1rAhhUxAr/2JOQ +RqlZBq6PfcHKLRitXRCeVvfldRxuWBIzhuTLUfRPYR6phjP50EzZPlbJzIvGwsOI +RheITAQYEQIADAUCPh/BhgUJEs/3gAAKCRAcUGQHVkwXoy0JAJ9WTfqfYzW/F6qi +5MxmqDnU9/G+6ACfQVmhZNnGTSfcwQCttwCaW3CRhDY= +=MWUr -END PGP PUBLIC KEY BLOCK- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
