Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
We heartily thank you for your support interest in our offerings. We appreciate value your mails. We will soon contact you to take this further, as appropriate. Thank you, mie consultants inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: yoavs 2005/08/02 11:12:06 Modified:.tomcat.nsi webapps/docs changelog.xml Log: Bugzilla 33261: http://issues.apache.org/bugzilla/show_bug.cgi?id=33261 Can you fix the EOLs ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey, Done. Thanks for catching that, Yoav PS -- Is the 1.1.0 native coming any time soon? The build is broken since build.xml and build.properties.default were updated, but archive.apache.org/dist/[jtc]/native does not exist... -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 2:26 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: yoavs 2005/08/02 11:12:06 Modified:.tomcat.nsi webapps/docs changelog.xml Log: Bugzilla 33261: http://issues.apache.org/bugzilla/show_bug.cgi?id=33261 Can you fix the EOLs ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav Shapira wrote: Hey, Done. Thanks for catching that, Yoav PS -- Is the 1.1.0 native coming any time soon? The build is broken since build.xml and build.properties.default were updated, but archive.apache.org/dist/[jtc]/native does not exist... Syncing takes a lot of time with the new architecture, sorry. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 26, 2005 5:45 AM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2005/07/26 05:45:22
Modified:catalina/src/share/org/apache/catalina/valves
ValveBase.java
ErrorReportValve.java mbeans-descriptors.xml
catalina build.xml
webapps/docs changelog.xml
Added: catalina/src/share/org/apache/catalina/valves
SemaphoreValve.java
Log:
- Add a simple valve for concurrency control, with a conditional
compilation
flag.
- At the moment, this will not be shipped in the release (needs Java 5).
- Update changelog.
snip/
/**
* Create a new StandardHost component with the default basic Valve.
*/
public SemaphoreValve() {
semaphore = new Semaphore(concurrency, fairness);
}
This happens before the setters get called (so only the default values are
possible). You probably want to implement Lifecycle and create the
Semaphore in a Lifecycle method.
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication
in error, please notify us immediately by e-mail and then delete all copies of
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through
the Internet is not secure. Do not send confidential or sensitive information,
such as social security numbers, account numbers, personal identification
numbers and passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Bill Barker wrote: Gump has been nagging about this for, like, almost a week now. You're a week late to be b*tching about this. I didn't build clean, so I didn't see it until yesterday. I never pay attention to gump messages BTW. I want to allow the committers that don't check email over the weekend a chance to review my Jk-Coyote patch for this particular issue, and then if Mark doesn't patch it first, I promise that Gump will get a clean build. At this point, all it takes is anybody with half a brain and Karma to finish the patch. I'm busy with other things at the moment ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: markt 2005/05/11 14:39:41 Modified:catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java SavedRequest.java webapps/docs changelog.xml Log: Include request body in saved request when using FORM authentication. - Fixes problem with saved request assuming platform default encoding for POSTed parameters. - Improves restoration of request by using CoyoteRequest Can you revert this commit ? I see no other solution right now, as: - it will not work with AJP - it depends on HTTP/1.1 connector internal classes, so it breaks a clean build Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Sunday, May 15, 2005 6:57 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: markt 2005/05/11 14:39:41 Modified:catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java SavedRequest.java webapps/docs changelog.xml Log: Include request body in saved request when using FORM authentication. - Fixes problem with saved request assuming platform default encoding for POSTed parameters. - Improves restoration of request by using CoyoteRequest Can you revert this commit ? I see no other solution right now, as: - it will not work with AJP - it depends on HTTP/1.1 connector internal classes, so it breaks a clean build Urm, we are nowhere close to doing another release (and Mark has already promised to revert it before then, if not fixed). Also, it doesn't really take much more to fix it from here. If you can't see any other solution right now, then you are truely brain-dead. Thanks, Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Bill Barker wrote: Urm, we are nowhere close to doing another release (and Mark has already promised to revert it before then, if not fixed). Also, it doesn't really take much more to fix it from here. If you can't see any other solution right now, then you are truely brain-dead. I missed the part about reverting, all I saw about this was adding limits. Besides, I am mostly complaining because it seems to break the build, which is never acceptable (even if no release is planned immediately). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Sunday, May 15, 2005 8:20 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Bill Barker wrote: Urm, we are nowhere close to doing another release (and Mark has already promised to revert it before then, if not fixed). Also, it doesn't really take much more to fix it from here. If you can't see any other solution right now, then you are truely brain-dead. I missed the part about reverting, all I saw about this was adding limits. Besides, I am mostly complaining because it seems to break the build, which is never acceptable (even if no release is planned immediately). Gump has been nagging about this for, like, almost a week now. You're a week late to be b*tching about this. I want to allow the committers that don't check email over the weekend a chance to review my Jk-Coyote patch for this particular issue, and then if Mark doesn't patch it first, I promise that Gump will get a clean build. At this point, all it takes is anybody with half a brain and Karma to finish the patch. Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Jan Luehe wrote:
[EMAIL PROTECTED] wrote:
remm2005/05/12 06:01:05
Modified:jasper2/src/share/org/apache/jasper/servlet
JspCServletContext.java
webapps/docs changelog.xml
Log:
- 34465: jspc without web.xml.
- Submitted by Yoichi Hirose.
Revision ChangesPath
1.4 +7 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java
Index: JspCServletContext.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JspCServletContext.java 17 Mar 2004 19:23:05 - 1.3
+++ JspCServletContext.java 12 May 2005 13:01:04 - 1.4
@@ -235,7 +235,13 @@
if (!path.startsWith(/))
throw new MalformedURLException(Path ' + path +
' does not start with '/');
-return (new URL(myResourceBaseURL, path.substring(1)));
+URL url = new URL(myResourceBaseURL, path.substring(1));
+if (file.equals(url.getProtocol())) {
+if (!(new File(url.getFile())).exists()) {
+return null;
+}
+}
+return url;
}
I don't think this is very efficient. Normally, the resource
with the given path will exist. It is just in the case
of web.xml that it may not exist.
Why not check specifically for existence of web.xml, as follows:
No, the JspCServletContext is supposed to work as a regular servlet
context, so we should really return null if the file does not exist
rather than add hacks elsewhere to work around it.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: markt 2005/05/11 14:39:41 Modified:catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java SavedRequest.java webapps/docs changelog.xml Log: Include request body in saved request when using FORM authentication. - Fixes problem with saved request assuming platform default encoding for POSTed parameters. - Improves restoration of request by using CoyoteRequest This is way too risky to do it for any POST (which could be a file upload), and I think it could lead to easy DoSes, so I share Bill's concerns. Saving parameters in general is risky as well, obviously ... IMO, webapps need to be better designed, and auth should happen before sending forms. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Olen työmatkalla ja takaisin toimistolla 16.5.2005. Back at the office May 16th. Kristiina Markkula GSM +358 50 560132 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. -Tim Remy Maucherat wrote: [EMAIL PROTECTED] wrote: markt 2005/05/11 14:39:41 Modified:catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java SavedRequest.java webapps/docs changelog.xml Log: Include request body in saved request when using FORM authentication. - Fixes problem with saved request assuming platform default encoding for POSTed parameters. - Improves restoration of request by using CoyoteRequest This is way too risky to do it for any POST (which could be a file upload), and I think it could lead to easy DoSes, so I share Bill's concerns. Saving parameters in general is risky as well, obviously ... IMO, webapps need to be better designed, and auth should happen before sending forms. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Tim Funk wrote: Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. I think I disagree. Even if you are not trying to do a DoS, it is very easy to do it non intentionally if you save any post data (file upload). We'd need to restrict saved POST size severely, as well as restrict more by default any form POST data. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 12, 2005 6:01 AM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2005/05/12 06:01:05
Modified:jasper2/src/share/org/apache/jasper/servlet
JspCServletContext.java
webapps/docs changelog.xml
Log:
- 34465: jspc without web.xml.
- Submitted by Yoichi Hirose.
-return (new URL(myResourceBaseURL, path.substring(1)));
+URL url = new URL(myResourceBaseURL, path.substring(1));
+if (file.equals(url.getProtocol())) {
+if (!(new File(url.getFile())).exists()) {
+return null;
+}
+}
A huge -1 to this. I can't believe that a Windows user would even think
commit junk like this. ;-)
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication
in error, please notify us immediately by e-mail and then delete all copies of
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through
the Internet is not secure. Do not send confidential or sensitive information,
such as social security numbers, account numbers, personal identification
numbers and passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, May 12, 2005 5:28 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Tim Funk wrote: Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. I think I disagree. Even if you are not trying to do a DoS, it is very easy to do it non intentionally if you save any post data (file upload). We'd need to restrict saved POST size severely, as well as restrict more by default any form POST data. I agree. I'd even be +1 to further restricting the saved body size for CLIENT-CERT auth, and that one is only saved for the time of one request. Since the body in a FORM auth is going to be saved for much longer, it's even more important to restrict it. And this is even more important for mod_jk users, since they will never get a chance to recover the data that they have posted :(. Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, May 12, 2005 5:28 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Tim Funk wrote: Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. I think I disagree. Even if you are not trying to do a DoS, it is very easy to do it non intentionally if you save any post data (file upload). We'd need to restrict saved POST size severely, as well as restrict more by default any form POST data. I agree. I'd even be +1 to further restricting the saved body size for CLIENT-CERT auth, and that one is only saved for the time of one request. Since the body in a FORM auth is going to be saved for much longer, it's even more important to restrict it. And this is even more important for mod_jk users, since they will never get a chance to recover the data that they have posted :(. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark Bill Barker wrote: Tim Funk wrote: Would it be worthwhile to use a new property? maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 to disable saving post. Of course this doesn't mitigate a malicious person issuing many POSTS under the configured threshold. I think I disagree. Even if you are not trying to do a DoS, it is very easy to do it non intentionally if you save any post data (file upload). We'd need to restrict saved POST size severely, as well as restrict more by default any form POST data. I agree. I'd even be +1 to further restricting the saved body size for CLIENT-CERT auth, and that one is only saved for the time of one request. Since the body in a FORM auth is going to be saved for much longer, it's even more important to restrict it. And this is even more important for mod_jk users, since they will never get a chance to recover the data that they have posted :(. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message - From: Mark Thomas [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Monday, May 12, 2003 10:34 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) The check on maxPostSize in the Request isn't applied to any 'chunked' POST body, and also not to any 'multipart/form-data'. I don't see any place else that checks it except when CLIENT-CERT auth saves the request body. Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. No. Previously only the Parameters were saved, and limited by maxPostSize. Now you are saving off file-upload posts as well, and these aren't limited anywhere. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. It should be something like: request.getCoyoteRequest().action(ActionCode.ACTION_SET_BODY_REPLAY, body); but that won't work either unless Jk-Coyote gets cleaned up a bit (the ActionHook implementation is one of those it's ugly but it works things at the moment :). I could do the cleanup if the consensus is that this is the way to go. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Bill Barker wrote: From: Mark Thomas [EMAIL PROTECTED] So the issues are: 1. AJP/1.3 compatibility 2. Potential DoS As far as DoS goes, with the previous behaviour any parameters POSTed would be persisted in the session until the authentication was completed or the session timed out. Therefore, the same issue exists with both the old and new implementation. (a) The size of the the POST is already limited by maxPostSize for both FORM and CLIENT-CERT auth. Is the proposal to add another parameter to the connector to optionally further limit the saved POST size when authenticating? (b) The check on maxPostSize in the Request isn't applied to any 'chunked' POST body, and also not to any 'multipart/form-data'. I don't see any place else that checks it except when CLIENT-CERT auth saves the request body. I stand corrected. This is easy to fix if it is agreed that this, or something similar to it, is the way forward. Given (a), I don't see a significant difference in risk between the old and new behaviour. I am happy to mitigate this risk by implementing (b). As maxPostSize applies to any POST, including during CLIENT-CERT auth my own view is that the new parameter should apply only to the FormAuthenticator valve and should default to 0 (ie no data saved). -1 would mean use whatever value is specified for maxPostSize and any value 0 would be the limit unless maxPostSize was smaller in which case maxPostSize would override the new parameter. The docs for this parameter would include a health warning about the risks of permitting the saving of POSTed data during FORM authentication. No. Previously only the Parameters were saved, and limited by maxPostSize. Now you are saving off file-upload posts as well, and these aren't limited anywhere. As above, putting the limit in is easy. I obviously also need to look at AJP/1.3 compatibility. Any hints/tips gratefully received. It should be something like: request.getCoyoteRequest().action(ActionCode.ACTION_SET_BODY_REPLAY, body); but that won't work either unless Jk-Coyote gets cleaned up a bit (the ActionHook implementation is one of those it's ugly but it works things at the moment :). I could do the cleanup if the consensus is that this is the way to go. Any help would be great. It took me a while to figure out how to get this far. If these issues aren't resolved by the time of the next release, I'll revert the saving the raw data part of the patch. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote:
remm2005/05/12 06:01:05
Modified:jasper2/src/share/org/apache/jasper/servlet
JspCServletContext.java
webapps/docs changelog.xml
Log:
- 34465: jspc without web.xml.
- Submitted by Yoichi Hirose.
Revision ChangesPath
1.4 +7 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java
Index: JspCServletContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspCServletContext.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JspCServletContext.java 17 Mar 2004 19:23:05 - 1.3
+++ JspCServletContext.java 12 May 2005 13:01:04 - 1.4
@@ -235,7 +235,13 @@
if (!path.startsWith(/))
throw new MalformedURLException(Path ' + path +
' does not start with '/');
-return (new URL(myResourceBaseURL, path.substring(1)));
+URL url = new URL(myResourceBaseURL, path.substring(1));
+if (file.equals(url.getProtocol())) {
+if (!(new File(url.getFile())).exists()) {
+return null;
+}
+}
+return url;
}
I don't think this is very efficient. Normally, the resource
with the given path will exist. It is just in the case
of web.xml that it may not exist.
Why not check specifically for existence of web.xml, as follows:
Index: JspConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java,v
retrieving revision 1.18
diff -u -r1.18 JspConfig.java
--- JspConfig.java 24 Mar 2005 04:08:01 - 1.18
+++ JspConfig.java 13 May 2005 00:09:22 -
@@ -16,6 +16,7 @@
package org.apache.jasper.compiler;
+import java.io.File;
import java.io.InputStream;
import java.util.Iterator;
import java.util.Vector;
@@ -63,10 +64,12 @@
try {
URL uri = ctxt.getResource(WEB_XML);
-if (uri == null) {
+if (uri == null
+|| (file.equals(uri.getProtocol())
+ !(new File(uri.getFile())).exists())) {
// no web.xml
return;
- }
+}
is = uri.openStream();
InputSource ip = new InputSource(is);
Jan
Jan
1.308 +7 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.307
retrieving revision 1.308
diff -u -r1.307 -r1.308
--- changelog.xml 11 May 2005 21:39:41 - 1.307
+++ changelog.xml 12 May 2005 13:01:04 - 1.308
@@ -153,6 +153,10 @@
default encoding. A side effect of this fix is that the bodies of
POST requests that
require FORM authentication are now buffered and made available
after a sucessful login. (markt)
/fix
+ fix
+bug34840/bug: Better handling of external WARs redeployment,
and ignore docBase specified
+in context file if within the Host appBase (remm)
+ /fix
/changelog
/subsection
@@ -199,6 +203,9 @@
bug34652/bug: Add the ability to get SMAPs when precompiling,
submitted by
Daryl Robbins (remm)
/update
+ fix
+bug34465/bug: Jspc failure if there is no web.xml, submitted
by Yoichi Hirose (remm)
+ /fix
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 11, 2005 2:39 PM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
markt 2005/05/11 14:39:41
+// Restore body
+InputFilter savedBody = new SavedRequestInputFilter(body);
+InternalInputBuffer internalBuffer = (InternalInputBuffer)
+request.getCoyoteRequest().getInputBuffer();
+internalBuffer.addActiveFilter(savedBody);
This is going to crash-and-burn spectacularly for anybody using the AJP/1.3
Connector.
+
+byte[] buffer = new byte[4096];
+int bytesRead;
+InputStream is = request.getInputStream();
+ByteChunk body = new ByteChunk();
+
+while ( (bytesRead = is.read(buffer) ) = 0) {
+body.append(buffer, 0, bytesRead);
+}
+saved.setBody(body);
}
It's generally not a good idea to allow unlimited saving of POST data, since
I can bring down your server by simply POSTing a 4GB file to a protected
page.
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication
in error, please notify us immediately by e-mail and then delete all copies of
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through
the Internet is not secure. Do not send confidential or sensitive information,
such as social security numbers, account numbers, personal identification
numbers and passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Peter, One of your related changes (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/cluster/build.xml?r1=1.14r2=1.15diff_format=h) has broken the 5.5 build on 1.4 JDKs :( Can you roll it back or commit an alternative please? Cheers, Mark [EMAIL PROTECTED] wrote: pero2005/04/22 13:38:38 Modified:webapps/docs changelog.xml Log: redesign DeltaManager restart under load Revision ChangesPath 1.291 +3 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- changelog.xml 15 Apr 2005 20:15:17 - 1.290 +++ changelog.xml 22 Apr 2005 20:38:38 - 1.291 @@ -146,7 +146,9 @@ update Refactor DeltaManager: - createSession call now ManagerBase super class method - - extract some long methods (pero) + - extract some long methods + - send GET_ALL_SESSION with session blocks + - don't sync sessions map when send all sessions (pero) /update update Add developer actions at to-do.txt (Proposal of changes) (pero) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey Mark, I roll it back. Thanks Peter Mark Thomas schrieb: Peter, One of your related changes (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/cluster/build.xml?r1=1.14r2=1.15diff_format=h) has broken the 5.5 build on 1.4 JDKs :( Can you roll it back or commit an alternative please? Cheers, Mark [EMAIL PROTECTED] wrote: pero2005/04/22 13:38:38 Modified:webapps/docs changelog.xml Log: redesign DeltaManager restart under load Revision ChangesPath 1.291 +3 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- changelog.xml15 Apr 2005 20:15:17 -1.290 +++ changelog.xml22 Apr 2005 20:38:38 -1.291 @@ -146,7 +146,9 @@ update Refactor DeltaManager: - createSession call now ManagerBase super class method - - extract some long methods (pero)+ - extract some long methods + - send GET_ALL_SESSION with session blocks + - don't sync sessions map when send all sessions (pero) /update update Add developer actions at to-do.txt (Proposal of changes) (pero) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Thanks, Mark Peter Rossbach wrote: Hey Mark, I roll it back. Thanks Peter Mark Thomas schrieb: Peter, One of your related changes (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/cluster/build.xml?r1=1.14r2=1.15diff_format=h) has broken the 5.5 build on 1.4 JDKs :( Can you roll it back or commit an alternative please? Cheers, Mark [EMAIL PROTECTED] wrote: pero2005/04/22 13:38:38 Modified:webapps/docs changelog.xml Log: redesign DeltaManager restart under load Revision ChangesPath 1.291 +3 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- changelog.xml15 Apr 2005 20:15:17 -1.290 +++ changelog.xml22 Apr 2005 20:38:38 -1.291 @@ -146,7 +146,9 @@ update Refactor DeltaManager: - createSession call now ManagerBase super class method - - extract some long methods (pero)+ - extract some long methods + - send GET_ALL_SESSION with session blocks + - don't sync sessions map when send all sessions (pero) /update update Add developer actions at to-do.txt (Proposal of changes) (pero) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
subsection name=Cluster changelog add +DeltaManager has now JMX expireAllLocalSessions and processExipre operation +for better cluster node shutdown handling (pero) + /add Why would we want to invalidate all sessions active on one node of the cluster when bringing it down, as opposed to replicating the session data out to one or more other available nodes in the cluster and letting the other machine(s) handle them? Or, did you add these operations/methods for cases where the cluster is configured to keep any given session on exactly one node? (I wouldn't think so, since in that case what would the session clustering really be useful for?) Just curious.. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yes your arguments are correct, but this method is very usefull to test the cluster implemention, a very important use case. :-) Thanks Peter Jason Brittain schrieb: subsection name=Cluster changelog add +DeltaManager has now JMX expireAllLocalSessions and processExipre operation +for better cluster node shutdown handling (pero) + /add Why would we want to invalidate all sessions active on one node of the cluster when bringing it down, as opposed to replicating the session data out to one or more other available nodes in the cluster and letting the other machine(s) handle them? Or, did you add these operations/methods for cases where the cluster is configured to keep any given session on exactly one node? (I wouldn't think so, since in that case what would the session clustering really be useful for?) Just curious.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: yoavs 2005/03/23 07:17:17 Modified:catalina/src/share/org/apache/catalina/realm JNDIRealm.java webapps/docs changelog.xml Log: Bugzilla 32938. update bug33636/bug: Set lastModified attribute when expanding WAR files. (yoavs) /update + update +bug32938/bug: Allow Salted SHA (SSHA) passwords in JNDIRealm. (yoavs) + /update /changelog /subsection If a patch was submitted and committed, I think the name of the submitter should be mentioned. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hola, If a patch was submitted and committed, I think the name of the submitter should be mentioned. I usually put the name of the committer only in the changelog. That seems to be consistent with past practice. The bugzilla issue (linked from the changelog when possible) has the name of the submitter(s). If they add themselves as @authors in the code, I also leave that in. However, if we want to put submitter names in the changelog, I'm fine with that and will start doing so from now on. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav Shapira wrote: Hola, If a patch was submitted and committed, I think the name of the submitter should be mentioned. I usually put the name of the committer only in the changelog. That seems to be consistent with past practice. The bugzilla issue (linked from the changelog when possible) has the name of the submitter(s). If they add themselves as @authors in the code, I also leave that in. However, if we want to put submitter names in the changelog, I'm fine with that and will start doing so from now on. The standard practice for the Apache httpd project is to mention both the patch submitter and committer in the change log. As a sometime patch submitter, I appreciate this. -- Jess Holle
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav Shapira wrote: Hola, If a patch was submitted and committed, I think the name of the submitter should be mentioned. I usually put the name of the committer only in the changelog. That seems to be consistent with past practice. The bugzilla issue (linked from the changelog when possible) has the name of the submitter(s). If they add themselves as @authors in the code, I also leave that in. However, if we want to put submitter names in the changelog, I'm fine with that and will start doing so from now on. We've actually been using submitted by for a long time in the changelog. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
PLEASE PLEASE STOP SENDING US YOUR E-MAILS...Satalogue --- [EMAIL PROTECTED] wrote: yoavs 2005/02/15 07:32:32 Modified:.tomcat.nsi webapps/docs changelog.xml Log: Bugzilla 33489. Revision ChangesPath 1.69 +2 -2 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.68 retrieving revision 1.69 diff -u -r1.68 -r1.69 --- tomcat.nsi 2 Feb 2005 12:01:43 - 1.68 +++ tomcat.nsi 15 Feb 2005 15:32:32 - 1.69 @@ -631,7 +631,7 @@ ; if $INSTDIR was removed, skip these next ones IfFileExists $INSTDIR 0 Removed MessageBox MB_YESNO|MB_ICONQUESTION \ - Remove all files in your Tomcat 5.5 directory? (If you have anything \ + Remove all files in your Tomcat 5.5 directory? (If you have anything \ you created that you want to keep, click No) IDNO Removed RMDir /r $INSTDIR\webapps\ROOT ; this would be skipped if the user hits no RMDir $INSTDIR\webapps 1.236 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.235 retrieving revision 1.236 diff -u -r1.235 -r1.236 --- changelog.xml 15 Feb 2005 09:58:06 - 1.235 +++ changelog.xml 15 Feb 2005 15:32:32 - 1.236 @@ -35,6 +35,9 @@ fix bug33351/bug: Fix silent uninstallation. (remm) /fix + fix +bug33489/bug: Missing space in uninstaller message. (yoavs) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = FROM SATALOGUE TECHNICAL DEPARTMENT...WE HAVE READ YOUR E-MAIL... Please call our Duty Engineer on 01332 811564 - for a proper 'one to one' answer as further information and / or clarification is required from you in order to answer your question properly . He is available from 10am until 5pm Monday to Friday inclusive. TO RETURN TO SATALOGUE WEBSITE: Click on to link below. http://www.satalogue.com/about.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hello Remy, Thanx for your help and I hope we have now a better server.xml saving support. The new features are: - Clustering support - new 5.5 Connector attribute mapping support (with correct https saving) - backup the context.xml also as default mode - Internally you can save Server/Service/Host/Context at PrintWriter - configurable and extendable I hope we have fun with the new modul :-) Peter s.u Remy Maucherat schrieb: Remy Maucherat wrote: I've thought about this more. Actually, maybe it's better to leave an indirection (and keep the compatibility as a bonus). Otherwise, we start to have to hardcode (or make configurable = more complexity) an ObjectName. So I think you probably have made the right choice. Now that I have looked at it, I have some comments: - nearly all of the logging is done as log.error(e), which isn't cool, because it logs e.toString() rather than a stack trace Yes, this is a ToDO and I spent time for this. - I think some special cases are needed for Context handling (but it's not very high priority, the current stuff does the job): * avoid saving information which is in the default context configuration (I think MBeans should be added for exposing the context defaults) Yes, the Context handling is very spezial. Currently the only chance is parse context defaults at a fresh new Context and strip down the real Context. Bad,Bad and no easy :-( I hope we have at future a DefaultContext MBean and use this at HostConfig and StoreConfig. * don't save path except in server.xml I thing that can I fix! * don't save docBase if the webapp is in the host appBase OK! It seems to work as well as the old code, so it's great :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Remy Maucherat wrote: I've thought about this more. Actually, maybe it's better to leave an indirection (and keep the compatibility as a bonus). Otherwise, we start to have to hardcode (or make configurable = more complexity) an ObjectName. So I think you probably have made the right choice. Now that I have looked at it, I have some comments: - nearly all of the logging is done as log.error(e), which isn't cool, because it logs e.toString() rather than a stack trace - I think some special cases are needed for Context handling (but it's not very high priority, the current stuff does the job): * avoid saving information which is in the default context configuration (I think MBeans should be added for exposing the context defaults) * don't save path except in server.xml * don't save docBase if the webapp is in the host appBase It seems to work as well as the old code, so it's great :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: pero2005/01/11 12:02:14 Modified:catalina/src/share/org/apache/catalina/core StandardServer.java modules/storeconfig/src/share/org/apache/catalina/storeconfig StoreConfigLifecycleListener.java server-registry.xml modules/storeconfig/test/src/share/org/apache/catalina/storeconfig ManagerSFTest.java webapps/docs changelog.xml Log: Integrate StoreConfig at StandardServer and fix small StoreConfig bugs I was thinking all that stuff would be completely removed from StandardServer, and the admin would call the right JMX operation directly. I've yet to try it, though ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: pero2005/01/11 12:02:14 Modified:catalina/src/share/org/apache/catalina/core StandardServer.java modules/storeconfig/src/share/org/apache/catalina/storeconfig StoreConfigLifecycleListener.java server-registry.xml modules/storeconfig/test/src/share/org/apache/catalina/storeconfig ManagerSFTest.java webapps/docs changelog.xml Log: Integrate StoreConfig at StandardServer and fix small StoreConfig bugs I was thinking all that stuff would be completely removed from StandardServer, and the admin would call the right JMX operation directly. I've thought about this more. Actually, maybe it's better to leave an indirection (and keep the compatibility as a bonus). Otherwise, we start to have to hardcode (or make configurable = more complexity) an ObjectName. So I think you probably have made the right choice. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
See, I told you that there was a bug, that prevented antiResourceLocking
from working :P
On Windows, Tomcat 5.5.6 Installer leaves service's Working Path blank on
both startup and shutdown tabs.
Filling it with apropriate value solves the problem for 5.5.6.
Now, there is still this antiJARLocking left
remm2004/12/14 05:57:31
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
webapps/docs changelog.xml
Log:
- 32694: Fix bad code to make a path absolute, which caused problem if
the VM working path is not catalina.base.
Revision ChangesPath
1.60 +6 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Co
ntextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/
startup/ContextConfig.java,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- ContextConfig.java 2 Oct 2004 09:22:18 - 1.59
+++ ContextConfig.java 14 Dec 2004 13:57:31 - 1.60
@@ -843,7 +843,11 @@
}
File docBaseFile = new File(docBase);
if (!docBaseFile.isAbsolute()) {
-docBaseFile = new File(appBase, docBase);
+File file = new File(appBase);
+if (!file.isAbsolute()) {
+file = new
File(System.getProperty(catalina.base), appBase);
+}
+docBaseFile = new File(file, docBase);
}
String path = context.getPath();
1.205 +11 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,
v
retrieving revision 1.204
retrieving revision 1.205
diff -u -r1.204 -r1.205
--- changelog.xml 11 Dec 2004 08:06:20 - 1.204
+++ changelog.xml 14 Dec 2004 13:57:31 - 1.205
@@ -26,6 +26,17 @@
/p
/section
+section name=Tomcat 5.5.7 (yoavs)
+ subsection name=Catalina
+changelog
+ fix
+bug32694/bug: Fix bad code to make docBase path aboslute
in antiLocking
+method. (remm)
+ /fix
+/changelog
+ /subsection
+/section
+
section name=Tomcat 5.5.6 (yoavs)
subsection name=General
changelog
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hi, Without knowing the filter, I figured if .jpg was there than .png wasn't much different, and if .txt was there .css is not much different. So it made sense from a consistency standpoint. However, I have no particular attachment to the filter itself or this commit: if you don't like it, feel free to undo it ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:25 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yoav, you made the right choice. The checkin is good. Filip - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:25 AM Subject: RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Hi, Without knowing the filter, I figured if .jpg was there than .png wasn't much different, and if .txt was there .css is not much different. So it made sense from a consistency standpoint. However, I have no particular attachment to the filter itself or this commit: if you don't like it, feel free to undo it ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:25 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. I did that since people use all kinds of extensions on the MVC framework. Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:39 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml [EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Filip Hanik - Dev wrote: actually, its a negative filter, (if one can say that :) Anything that doesn't match the filter, gets replicated. Ahh :) Good then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
I'd like to thank you for your effort and time so far. Thanks, Laszlo Kishalmi [EMAIL PROTECTED] wrote: yoavs 2004/10/29 07:45:07 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Removed contrib directory which I added previously. I don't like this solution, it leads to a maintenance nightmare and I don't think the market is there. If another committer feels strongly otherwise (which none did in tomcat-dev discussions), they can reopen this issue and deal with it. Revision ChangesPath No revision No revision 1.70.2.66 +0 -3 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.65 retrieving revision 1.70.2.66 diff -u -r1.70.2.65 -r1.70.2.66 --- changelog.xml 29 Oct 2004 14:01:20 - 1.70.2.65 +++ changelog.xml 29 Oct 2004 14:45:07 - 1.70.2.66 @@ -20,9 +20,6 @@ update Update web.xml files to 2.4 schema (from 2.3 DTD) where applicable. (yoavs) /update - update -Added contrib directory to hold 3rd party scripts: bug31499/bug, bug31447/bug. (yoavs) - /update /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hi, No problem. There's a bigger issue here than just these scripts, and I don't have the bandwidth to deal with it at the moment. But the door is open for future considerations and alternatives. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 11:13 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml I'd like to thank you for your effort and time so far. Thanks, Laszlo Kishalmi [EMAIL PROTECTED] wrote: yoavs 2004/10/29 07:45:07 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Removed contrib directory which I added previously. I don't like this solution, it leads to a maintenance nightmare and I don't think the market is there. If another committer feels strongly otherwise (which none did in tomcat-dev discussions), they can reopen this issue and deal with it. Revision ChangesPath No revision No revision 1.70.2.66 +0 -3 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.65 retrieving revision 1.70.2.66 diff -u -r1.70.2.65 -r1.70.2.66 --- changelog.xml 29 Oct 2004 14:01:20 - 1.70.2.65 +++ changelog.xml 29 Oct 2004 14:45:07 - 1.70.2.66 @@ -20,9 +20,6 @@ update Update web.xml files to 2.4 schema (from 2.3 DTD) where applicable. (yoavs) /update - update -Added contrib directory to hold 3rd party scripts: bug31499/bug, bug31447/bug. (yoavs) - /update /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: Valve className=org.apache.catalina.cluster.tcp.ReplicationValve - filter=.*\.gif;.*\.js;.*\.jpg;.*\.htm;.*\.html;.*\.txt;/ + filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ -0. Adding static resources to that list is not good IMO. The idea is that replication (with the Tomcat defaults) will only have to occur for dynamic content. If the guy has special needs, then he can change this. Obviously, this is not a big issue for the 5.5.4 build ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: pero2004/10/04 23:57:20 Modified:catalina/src/share/org/apache/catalina/deploy ContextEjb.java ContextLocalEjb.java ContextResource.java ContextResourceEnvRef.java ContextResourceLink.java webapps/docs changelog.xml Log: refactor o.a.c.deploy.ContextXXX classes to use new super class ContextBase. - I think the ContextBase name for this class is quite bad. - Please make sure you don't break the build. This means checking when adding files that they are indeed added (and same when removing). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hmm, I also so think that the managedResource attribute is a hack. What we need is a better JMX API. My wish is that we open some of the MBeans to add more operations. Example realm: We have only init/start/stop/destroy jmx operations but what I need is authenticateXXX hasRole Than I can easy used every realm for my JMX http adaptor (MX4J 2.0.1). Peter Bill Barker schrieb: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 04, 2004 4:23 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Bill Barker wrote: It was on Peter's wish-list to add managedResource to the Realms. This was taken from (I think :) StandardHost, where the code was so broken that it was impossible that anybody was using it, so waiting for managedResource to be added to the mbean-descriptor was reasonable. I tested with removing the relevant blocks in the containers: it's not really used. It would be only used by some custom JMX-embedding (and, like I said, it never worked :). The JMX-embedding method that does work is to invoke init on the Realm, which will then add itself to whichever Container it was registered for. Except that managedResource is an internal-implementation artifact of c-m. There really isn't any point in getting rid of it before Remy's project to make c-m an optional component. Really, I'm supposed to do that ? ;) It's your todo list ;). I don't think managedResource needs anything special: it's just a standard attribute (and is a hack) that is declared in the mbean-descriptors. Its name makes it sound like it's somehow magically provided by the model MBean implementation, but it's not (it would be very insecure to do so). I would be happier if we tried removing the managedResource, actually. It will make Peter unhappy, but it wouldn't be hard. Probably the hardest one to do would be Connector (since you can't add a Connector to an Engine :). The Realm stuff that started this could probably just invoke init on the Realm instead. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey Remy, I have made a complete rebuild and a test. It works fine for me.. Ok, what you thing is a better name for ContextBase or you mean the refactoring is useless ? I need this refactoring for eaiser identifiy the ContextXXX classes for my new xml saving code. Peter Remy Maucherat schrieb: [EMAIL PROTECTED] wrote: pero2004/10/04 23:57:20 Modified:catalina/src/share/org/apache/catalina/deploy ContextEjb.java ContextLocalEjb.java ContextResource.java ContextResourceEnvRef.java ContextResourceLink.java webapps/docs changelog.xml Log: refactor o.a.c.deploy.ContextXXX classes to use new super class ContextBase. - I think the ContextBase name for this class is quite bad. - Please make sure you don't break the build. This means checking when adding files that they are indeed added (and same when removing). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Peter Rossbach wrote: Hey Remy, I have made a complete rebuild and a test. It works fine for me.. Apparently, you didn't cvs add the new ContextBase class. I think I can figure out what it contains, of course ;) Ok, what you thing is a better name for ContextBase or you mean the refactoring is useless ? No, the classname just sounds this is a superclass of StandardContext. So the classname is bad. I need this refactoring for eaiser identifiy the ContextXXX classes for my new xml saving code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Peter Rossbach wrote: Hmm, I also so think that the managedResource attribute is a hack. What we need is a better JMX API. My wish is that we open some of the MBeans to add more operations. Example realm: We have only init/start/stop/destroy jmx operations but what I need is authenticateXXX hasRole Than I can easy used every realm for my JMX http adaptor (MX4J 2.0.1). Some of the descriptors are very old, so there's no problem with updating them as needed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey Remy, sorry, to my checkin fault... I am change the name to ResourceBase and add it to the cvs. Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, I have made a complete rebuild and a test. It works fine for me.. Apparently, you didn't cvs add the new ContextBase class. I think I can figure out what it contains, of course ;) Ok, what you thing is a better name for ContextBase or you mean the refactoring is useless ? No, the classname just sounds this is a superclass of StandardContext. So the classname is bad. I need this refactoring for eaiser identifiy the ContextXXX classes for my new xml saving code. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jasper-howto.xml
Hi Remy,
[EMAIL PROTECTED] wrote:
remm2004/10/04 10:39:46
Modified:jasper2/src/share/org/apache/jasper/resources
LocalStrings.properties
jasper2/src/share/org/apache/jasper
EmbeddedServletOptions.java Options.java JspC.java
jasper2/src/share/org/apache/jasper/compiler Compiler.java
webapps/docs changelog.xml jasper-howto.xml
Log:
- Allow configuring the interval following a compilation during which a JSP will not
be checked for modifications.
how is this different from the 'checkInterval' option?
Jan
Revision ChangesPath
1.2 +2 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/LocalStrings.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LocalStrings.properties 1 Sep 2004 10:08:48 - 1.1
+++ LocalStrings.properties 4 Oct 2004 17:39:45 - 1.2
@@ -143,6 +143,7 @@
jsp.warning.sendErrToClient=Warning: Invalid value for the initParam sendErrToClient. Will use the default value of \false\
jsp.warning.classDebugInfo=Warning: Invalid value for the initParam classdebuginfo. Will use the default value of \false\
jsp.warning.checkInterval=Warning: Invalid value for the initParam checkInterval. Will use the default value of \300\ seconds
+jsp.warning.modificationTestInterval=Warning: Invalid value for the initParam modificationTestInterval. Will use the default value of \4000\ milliseconds
jsp.warning.development=Warning: Invalid value for the initParam development. Will use the default value of \true\
jsp.warning.fork=Warning: Invalid value for the initParam fork. Will use the default value of \true\
jsp.warning.reloading=Warning: Invalid value for the initParam reloading. Will use the default value of \true\
1.14 +24 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
Index: EmbeddedServletOptions.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- EmbeddedServletOptions.java 2 Sep 2004 16:05:06 - 1.13
+++ EmbeddedServletOptions.java 4 Oct 2004 17:39:45 - 1.14
@@ -164,7 +164,12 @@
*/
private String javaEncoding = UTF8;
-/*
+/**
+ * Modification test interval.
+ */
+public int modificationTestInterval = 4000;
+
+/**
* Is generation of X-Powered-By response header enabled/disabled?
*/
private boolean xpoweredBy;
@@ -226,6 +231,13 @@
}
/**
+ * Modification test interval.
+ */
+public int getModificationTestInterval() {
+return modificationTestInterval;
+}
+
+/**
* Is Jasper being used in development mode?
*/
public boolean getDevelopment() {
@@ -450,6 +462,17 @@
}
}
+String modificationTestInterval = config.getInitParameter(modificationTestInterval);
+if (modificationTestInterval != null) {
+try {
+this.modificationTestInterval = Integer.parseInt(modificationTestInterval);
+} catch(NumberFormatException ex) {
+if (log.isWarnEnabled()) {
+log.warn(Localizer.getMessage(jsp.warning.modificationTestInterval));
+}
+}
+}
+
String development = config.getInitParameter(development);
if (development != null) {
if (development.equalsIgnoreCase(true)) {
@@ -589,9 +612,6 @@
}
}
-/*
- * X-Powered-By
- */
String xpoweredBy = config.getInitParameter(xpoweredBy);
if (xpoweredBy != null) {
if (xpoweredBy.equalsIgnoreCase(true)) {
1.25 +6 -0 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java
Index: Options.java
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Options.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Options.java 2 Sep 2004 16:05:06 - 1.24
+++ Options.java 4 Oct 2004 17:39:45 - 1.25
@@ -164,4 +164,10 @@
* Are Text strings to be generated as char arrays?
*/
public boolean genStringAsCharArray();
+
+/**
+ * Modification test interval.
+ */
+public int
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jasper-howto.xml
Jan Luehe wrote: Hi Remy, [EMAIL PROTECTED] wrote: remm2004/10/04 10:39:46 Modified:jasper2/src/share/org/apache/jasper/resources LocalStrings.properties jasper2/src/share/org/apache/jasper EmbeddedServletOptions.java Options.java JspC.java jasper2/src/share/org/apache/jasper/compiler Compiler.java webapps/docs changelog.xml jasper-howto.xml Log: - Allow configuring the interval following a compilation during which a JSP will not be checked for modifications. how is this different from the 'checkInterval' option? The check interval is in seconds, and is for the background reloading thread. This means at most one check every X ms. I did consider reusing it, but since the unit was different, I chose not to. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jasper-howto.xml
Remy Maucherat wrote: Jan Luehe wrote: Hi Remy, [EMAIL PROTECTED] wrote: remm2004/10/04 10:39:46 Modified:jasper2/src/share/org/apache/jasper/resources LocalStrings.properties jasper2/src/share/org/apache/jasper EmbeddedServletOptions.java Options.java JspC.java jasper2/src/share/org/apache/jasper/compiler Compiler.java webapps/docs changelog.xml jasper-howto.xml Log: - Allow configuring the interval following a compilation during which a JSP will not be checked for modifications. how is this different from the 'checkInterval' option? The check interval is in seconds, and is for the background reloading thread. This means at most one check every X ms. I did consider reusing it, but since the unit was different, I chose not to. I think this new option is going to confuse users. If we wanted to reduce the number of last-modified checks in development mode, we should at least try to leverage the existing option and use the same unit. The default for the new option (4000ms) seems to imply that seconds may be a reasonable unit for it as well. Also, I think it is more intuitive if we check for last modification date on each access in dev mode. I don't think perf improvements are important in dev mode. +listrongmodificationTestInterval/strong - If development has to be set to +codetrue/code for any reason (such as dynamic generation of JSPs), setting +this to a high value will improve performance a lot./li Why won't dynamic generation of JSPs work in nondev mode? Notice that in JspServleWrapper, we compile if options.getDevelopment() || firstTime Jan Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jasper-howto.xml
Jan Luehe wrote: Remy Maucherat wrote: Jan Luehe wrote: Hi Remy, [EMAIL PROTECTED] wrote: remm2004/10/04 10:39:46 Modified:jasper2/src/share/org/apache/jasper/resources LocalStrings.properties jasper2/src/share/org/apache/jasper EmbeddedServletOptions.java Options.java JspC.java jasper2/src/share/org/apache/jasper/compiler Compiler.java webapps/docs changelog.xml jasper-howto.xml Log: - Allow configuring the interval following a compilation during which a JSP will not be checked for modifications. how is this different from the 'checkInterval' option? The check interval is in seconds, and is for the background reloading thread. This means at most one check every X ms. I did consider reusing it, but since the unit was different, I chose not to. I think this new option is going to confuse users. If we wanted to reduce the number of last-modified checks in development mode, we should at least try to leverage the existing option and use the same unit. The default for the new option (4000ms) seems to imply that seconds may be a reasonable unit for it as well. Also, I think it is more intuitive if we check for last modification date on each access in dev mode. I don't think perf improvements are important in dev mode. I feel strongly about this. Dev mode is the default, and is needed for some special purpose stuff (where JSPs are regenerated on the fly), so it need to perform relatively well. IMO, the background reloading thread is way too complex and buggy. It should go in favor of a much simpler mechanism (if you really want only one thing; personally, I would keep both, as it's more flexible). +listrongmodificationTestInterval/strong - If development has to be set to +codetrue/code for any reason (such as dynamic generation of JSPs), setting +this to a high value will improve performance a lot./li Why won't dynamic generation of JSPs work in nondev mode? Notice that in JspServleWrapper, we compile if options.getDevelopment() || firstTime It works for the first compilation, of course. But most people who use that obvious refresh their JSPs. Overall, I think that having two attributes is appropriate. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hi Remy,
Modified:.build.xml
catalina/src/share/org/apache/catalina/core
StandardContext.java StandardEngine.java
mbeans-descriptors.xml
catalina/src/share/org/apache/catalina/connector
Connector.java
resources/mbeans tomcat5-ant.xml
catalina/src/share/org/apache/catalina/realm RealmBase.java
webapps/docs changelog.xml
Log:
- Fix embed and deployer packaging.
- Fix JMX registration of realm.
- Fix a variety of problems in MBean names.
1.26 +18 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java
Index: StandardEngine.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- StandardEngine.java 16 Aug 2004 09:31:05 - 1.25
+++ StandardEngine.java 3 Oct 2004 08:53:56 - 1.26
@@ -404,6 +404,23 @@
if( !initialized ) {
init();
}
+
+// Look for a realm - that may have been configured earlier.
+// If the realm is added after context - it'll set itself.
+if( realm == null ) {
+ObjectName realmName=null;
+try {
+realmName=new ObjectName( domain + :type=Realm);
+if( mserver.isRegistered(realmName ) ) {
+Realm nrealm =
(Realm)mserver.getAttribute(realmName,
+
managedResource);
I don't think Realm has managedResource attribute.
Shouldn't we be moving towards getting rid of all non-serializable
attributes and return types in order to support remote access to MBeanServer
using JSR 160?
Thanks,
Amy
+setRealm(nrealm);
+}
+} catch( Throwable t ) {
+log.debug(No realm for this engine + realmName);
+}
+}
+
// Log our server identification information
//System.out.println(ServerInfo.getServerInfo());
log.info( Starting Servlet Engine: +
ServerInfo.getServerInfo());
1.36 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/mbeans-descriptors.xml
Index: mbeans-descriptors.xml
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/mbeans-descriptors.xml,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- mbeans-descriptors.xml 29 Sep 2004 21:09:40 - 1.35
+++ mbeans-descriptors.xml 3 Oct 2004 08:53:56 - 1.36
@@ -547,7 +547,7 @@
returnType=void
parameter name=connector
description=Connector object
- type=org.apache.catalina.Connector/
+ type=org.apache.catalina.connector.Connector/
/operation
operation name=start description=Start impact=ACTION
returnType=void /
1.6 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java
Index: Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Connector.java 29 Sep 2004 09:55:38 - 1.5
+++ Connector.java 3 Oct 2004 08:53:56 - 1.6
@@ -1156,7 +1156,7 @@
log.debug(Adding to + parentName );
if( mserver.isRegistered(parentName )) {
mserver.invoke(parentName, addConnector, new Object[]
{ this },
-new String[] {org.apache.catalina.Connector});
+new String[]
{org.apache.catalina.connector.Connector});
// As a side effect we'll get the container field set
// Also initialize will be called
//return;
1.17 +16 -35jakarta-tomcat-5/resources/mbeans/tomcat5-ant.xml
Index: tomcat5-ant.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/resources/mbeans/tomcat5-ant.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- tomcat5-ant.xml 13 Nov 2003 08:45:48 - 1.16
+++ tomcat5-ant.xml 3 Oct 2004 08:53:56 - 1.17
@@ -145,8 +145,12 @@
target name=run depends=init,jmx-console
description=Start tomcat as an mbean, no server.xml
+property name=catalina.useNaming value=false /
+
+!--
modelerRegistry
resource=org/apache/catalina/mbeans/mbeans-descriptors.xml /
modelerRegistry
resource=org/apache/catalina/loader/mbeans-descriptors.xml /
+--
mkdir dir=${tomcat.home}/work/${domain}/ /
jmx-service
@@
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Amy Roh wrote:
Hi Remy,
Modified:.build.xml
catalina/src/share/org/apache/catalina/core
StandardContext.java StandardEngine.java
mbeans-descriptors.xml
catalina/src/share/org/apache/catalina/connector
Connector.java
resources/mbeans tomcat5-ant.xml
catalina/src/share/org/apache/catalina/realm
RealmBase.java
webapps/docs changelog.xml
Log:
- Fix embed and deployer packaging.
- Fix JMX registration of realm.
- Fix a variety of problems in MBean names.
1.26 +18 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java
Index: StandardEngine.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- StandardEngine.java 16 Aug 2004 09:31:05 - 1.25
+++ StandardEngine.java 3 Oct 2004 08:53:56 - 1.26
@@ -404,6 +404,23 @@
if( !initialized ) {
init();
}
+
+// Look for a realm - that may have been configured earlier.
+// If the realm is added after context - it'll set itself.
+if( realm == null ) {
+ObjectName realmName=null;
+try {
+realmName=new ObjectName( domain + :type=Realm);
+if( mserver.isRegistered(realmName ) ) {
+Realm nrealm =
(Realm)mserver.getAttribute(realmName,
+ managedResource);
I don't think Realm has managedResource attribute.
Shouldn't we be moving towards getting rid of all non-serializable
attributes and return types in order to support remote access to
MBeanServer using JSR 160?
It's probably not used. I don't know for sure if it does anything, all I
know is that I did cut paste from the other standard containers while
I was investigating why realms weren't working with embed.
Rmy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message -
From: Amy Roh [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, October 04, 2004 3:30 PM
Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hi Remy,
Modified:.build.xml
catalina/src/share/org/apache/catalina/core
StandardContext.java StandardEngine.java
mbeans-descriptors.xml
catalina/src/share/org/apache/catalina/connector
Connector.java
resources/mbeans tomcat5-ant.xml
catalina/src/share/org/apache/catalina/realm
RealmBase.java
webapps/docs changelog.xml
Log:
- Fix embed and deployer packaging.
- Fix JMX registration of realm.
- Fix a variety of problems in MBean names.
1.26 +18 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/Standard
Engine.java
Index: StandardEngine.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/StandardEngine.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- StandardEngine.java 16 Aug 2004 09:31:05 - 1.25
+++ StandardEngine.java 3 Oct 2004 08:53:56 - 1.26
@@ -404,6 +404,23 @@
if( !initialized ) {
init();
}
+
+// Look for a realm - that may have been configured earlier.
+// If the realm is added after context - it'll set itself.
+if( realm == null ) {
+ObjectName realmName=null;
+try {
+realmName=new ObjectName( domain + :type=Realm);
+if( mserver.isRegistered(realmName ) ) {
+Realm nrealm =
(Realm)mserver.getAttribute(realmName,
+
managedResource);
I don't think Realm has managedResource attribute.
It was on Peter's wish-list to add managedResource to the Realms. This
was taken from (I think :) StandardHost, where the code was so broken that
it was impossible that anybody was using it, so waiting for
managedResource to be added to the mbean-descriptor was reasonable.
Shouldn't we be moving towards getting rid of all non-serializable
attributes and return types in order to support remote access to
MBeanServer
using JSR 160?
Except that managedResource is an internal-implementation artifact of c-m.
There really isn't any point in getting rid of it before Remy's project to
make c-m an optional component.
Thanks,
Amy
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Bill Barker wrote: It was on Peter's wish-list to add managedResource to the Realms. This was taken from (I think :) StandardHost, where the code was so broken that it was impossible that anybody was using it, so waiting for managedResource to be added to the mbean-descriptor was reasonable. I tested with removing the relevant blocks in the containers: it's not really used. Except that managedResource is an internal-implementation artifact of c-m. There really isn't any point in getting rid of it before Remy's project to make c-m an optional component. Really, I'm supposed to do that ? ;) I don't think managedResource needs anything special: it's just a standard attribute (and is a hack) that is declared in the mbean-descriptors. Its name makes it sound like it's somehow magically provided by the model MBean implementation, but it's not (it would be very insecure to do so). I would be happier if we tried removing the managedResource, actually. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jasper-howto.xml
I feel strongly about this. Dev mode is the default, and is needed for some special purpose stuff (where JSPs are regenerated on the fly), so it need to perform relatively well. IMO, the background reloading thread is way too complex and buggy. It should go in favor of a much simpler mechanism (if you really want only one thing; personally, I would keep both, as it's more flexible). +listrongmodificationTestInterval/strong - If development has to be set to +codetrue/code for any reason (such as dynamic generation of JSPs), setting +this to a high value will improve performance a lot./li Why won't dynamic generation of JSPs work in nondev mode? Notice that in JspServleWrapper, we compile if options.getDevelopment() || firstTime It works for the first compilation, of course. But most people who use that obvious refresh their JSPs. Overall, I think that having two attributes is appropriate. OK, I think I've bought your point. Can we specify the interval in seconds then, or what was the reason to specify it in ms? Do you think a JSP could change that frequently? When you specify a value 1000ms, you might as well specify -1. Also, we should add this option to the documentation of the JspServlet init params in the default web.xml. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 04, 2004 4:23 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Bill Barker wrote: It was on Peter's wish-list to add managedResource to the Realms. This was taken from (I think :) StandardHost, where the code was so broken that it was impossible that anybody was using it, so waiting for managedResource to be added to the mbean-descriptor was reasonable. I tested with removing the relevant blocks in the containers: it's not really used. It would be only used by some custom JMX-embedding (and, like I said, it never worked :). The JMX-embedding method that does work is to invoke init on the Realm, which will then add itself to whichever Container it was registered for. Except that managedResource is an internal-implementation artifact of c-m. There really isn't any point in getting rid of it before Remy's project to make c-m an optional component. Really, I'm supposed to do that ? ;) It's your todo list ;). I don't think managedResource needs anything special: it's just a standard attribute (and is a hack) that is declared in the mbean-descriptors. Its name makes it sound like it's somehow magically provided by the model MBean implementation, but it's not (it would be very insecure to do so). I would be happier if we tried removing the managedResource, actually. It will make Peter unhappy, but it wouldn't be hard. Probably the hardest one to do would be Connector (since you can't add a Connector to an Engine :). The Realm stuff that started this could probably just invoke init on the Realm instead. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: yoavs 2004/09/28 06:23:11 Modified:catalina/src/share/org/apache/catalina/core Tag: TOMCAT_5_0 ApplicationDispatcher.java webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: Bugzilla 30949: moved ApplicationDispatcher's unwrap calls to the invoke method so that they're done even if errors occur in the include. I think the patch is not so good. Revision ChangesPath No revision No revision 1.34.2.1 +6 -9 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java Index: ApplicationDispatcher.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v retrieving revision 1.34 retrieving revision 1.34.2.1 diff -u -r1.34 -r1.34.2.1 --- ApplicationDispatcher.java 7 Jun 2004 17:32:15 - 1.34 +++ ApplicationDispatcher.java 28 Sep 2004 13:23:11 - 1.34.2.1 @@ -531,8 +531,6 @@ new Integer(ApplicationFilterFactory.INCLUDE)); request.setAttribute(ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR, origServletPath); invoke(request, outerResponse); -unwrapResponse(); - Here it doesn't seem good (ok, the case is actually never used) since the request would be unwrapped as well. } // Handle an HTTP named dispatcher include @@ -552,9 +550,6 @@ invoke(outerRequest, outerResponse); wrequest.recycle(); -unwrapRequest(); -unwrapResponse(); - And here the recycling won't get done. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: funkman 2004/09/15 05:59:46 Modified:webapps/docs changelog.xml Log: Start 5.5.3 - Server Header config You are simply ignoring my opinion, then. Fine :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
I thought the setup time config was a reasonable compromise. It allows the tinfoil hat folks to be happy while providing no performance decrease. (Unless 2 new instance variables is an issue ;) ) -Tim Remy Maucherat wrote: [EMAIL PROTECTED] wrote: funkman 2004/09/15 05:59:46 Modified:webapps/docs changelog.xml Log: Start 5.5.3 - Server Header config You are simply ignoring my opinion, then. Fine :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
where do I get a tinfoil hat? on a less silly note, thanks for such great software. starting next month I get to return to tomcat + java and get away from *cough* .NET + IIS peter On Wed, 15 Sep 2004 09:24:10 -0400, Tim Funk [EMAIL PROTECTED] wrote: I thought the setup time config was a reasonable compromise. It allows the tinfoil hat folks to be happy while providing no performance decrease. (Unless 2 new instance variables is an issue ;) ) -Tim Remy Maucherat wrote: [EMAIL PROTECTED] wrote: funkman 2004/09/15 05:59:46 Modified:webapps/docs changelog.xml Log: Start 5.5.3 - Server Header config You are simply ignoring my opinion, then. Fine :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Tim Funk wrote: I thought the setup time config was a reasonable compromise. It allows the tinfoil hat folks to be happy while providing no performance decrease. (Unless 2 new instance variables is an issue ;) ) Sigh. Ok, I give up. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote:
yoavs 2004/08/28 05:49:55
Modified:catalina/src/share/org/apache/catalina/core Tag: TOMCAT_5_0
StandardContext.java
webapps/docs Tag: TOMCAT_5_0 changelog.xml
Log:
Addressed Bugzilla 30762. Risky fix I think, but better than the current broken behavior.
Revision ChangesPath
No revision
No revision
1.130.2.1 +9 -2 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.130
retrieving revision 1.130.2.1
diff -u -r1.130 -r1.130.2.1
--- StandardContext.java 7 Jun 2004 15:30:06 - 1.130
+++ StandardContext.java 28 Aug 2004 12:49:54 - 1.130.2.1
@@ -4497,7 +4497,11 @@
}
// Stop our application listeners
-listenerStop();
+// I think this should be after the children are stopped,
+// because now servlet destroy() is called AFTER
+// contextDestroyed, which is a Spec violation as noted
+// Bugzilla 30762.
+// listenerStop();
// Finalize our character set mapper
setCharsetMapper(null);
@@ -4538,6 +4542,9 @@
if ((loader != null) (loader instanceof Lifecycle)) {
((Lifecycle) loader).stop();
}
+
+// Now stop the listeners, Bugzilla 30762
+listenerStop();
You should stop them at least before the loader, or there will be trouble.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
-1
how about not putting your home directory in the default property file :)
Filip
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 3:10 PM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/08/05 13:10:49
Modified:.build.properties.default
webapps/docs changelog.xml
Log:
Updated Jakarta-Commons dependencies (BeanUtils to 1.7.0, Collections to 3.1).
Revision ChangesPath
1.131 +8 -7 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- build.properties.default 29 Jul 2004 19:16:08 - 1.130
+++ build.properties.default 5 Aug 2004 20:10:48 - 1.131
@@ -35,9 +35,10 @@
cvsroot=:pserver:[EMAIL PROTECTED]:/home/cvspublic
# - Default Base Path for Dependent Packages -
-base.path=/usr/share/java
+#base.path=/usr/share/java
#base.path=../repository
#base.path=/usr/local
+base.path=/home/yoavs/temp
# - Jakarta files base location -
base-jakarta.loc=http://archive.apache.org/dist/jakarta
@@ -54,17 +55,17 @@
# - Commons Beanutils, version 1.4 or later -
-commons-beanutils.home=${base.path}/commons-beanutils-1.6.1
+commons-beanutils.home=${base.path}/commons-beanutils-1.7.0
commons-beanutils.lib=${commons-beanutils.home}
commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
-commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.6.1.tar.gz
+commons-beanutils.loc=${base-jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.7.0.tar.gz
# - Commons Collections, version 2.0 or later -
-commons-collections.home=${base.path}/commons-collections-2.1.1
+commons-collections.home=${base.path}/commons-collections-3.1
commons-collections.lib=${commons-collections.home}
-commons-collections.jar=${commons-collections.lib}/commons-collections-2.1.1.jar
-commons-collections.loc=${base-jakarta.loc}/commons/collections/binaries/commons-collections-2.1.1.tar.gz
+commons-collections.jar=${commons-collections.lib}/commons-collections-3.1.jar
+commons-collections.loc=${base-jakarta.loc}/commons/collections/binaries/commons-collections-3.1.tar.gz
# - Commons Launcher, version 0.9 or later -
1.87 +5 -2 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- changelog.xml 5 Aug 2004 13:10:35 - 1.86
+++ changelog.xml 5 Aug 2004 20:10:48 - 1.87
@@ -14,7 +14,7 @@
body
-section name=Tomcat 5.1.0 (yoavs)
+section name=Tomcat 5.5.0 (yoavs)
subsection name=General
changelog
fix
@@ -33,7 +33,10 @@
bug29826/bug: Modified setclasspath.bat exit code to 1. (yoavs)
/fix
update
-Updated status page, basically completely rewritten for Tomcat 5.1. (yoavs)
+Updated status page, mostly rewritten. (yoavs)
+ /update
+ update
+Updated Jakarta-Commons dependencies: BeanUtils to 1.7.0, Collections to
3.1. (yoavs)
/update
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hi,
Oops, sorry about that, I've just fixed it.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 4:14 PM
To: Tomcat Developers List
Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs
changelog.xml
-1
how about not putting your home directory in the default property file
:)
Filip
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 3:10 PM
Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2004/08/05 13:10:49
Modified:.build.properties.default
webapps/docs changelog.xml
Log:
Updated Jakarta-Commons dependencies (BeanUtils to 1.7.0, Collections
to
3.1).
Revision ChangesPath
1.131 +8 -7 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- build.properties.default 29 Jul 2004 19:16:08 - 1.130
+++ build.properties.default 5 Aug 2004 20:10:48 - 1.131
@@ -35,9 +35,10 @@
cvsroot=:pserver:[EMAIL PROTECTED]:/home/cvspublic
# - Default Base Path for Dependent Packages -
-base.path=/usr/share/java
+#base.path=/usr/share/java
#base.path=../repository
#base.path=/usr/local
+base.path=/home/yoavs/temp
# - Jakarta files base location -
base-jakarta.loc=http://archive.apache.org/dist/jakarta
@@ -54,17 +55,17 @@
# - Commons Beanutils, version 1.4 or later -
-commons-beanutils.home=${base.path}/commons-beanutils-1.6.1
+commons-beanutils.home=${base.path}/commons-beanutils-1.7.0
commons-beanutils.lib=${commons-beanutils.home}
commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
-commons-beanutils.loc=${base-
jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.6.1.tar.gz
+commons-beanutils.loc=${base-
jakarta.loc}/commons/beanutils/binaries/commons-beanutils-1.7.0.tar.gz
# - Commons Collections, version 2.0 or later -
-commons-collections.home=${base.path}/commons-collections-2.1.1
+commons-collections.home=${base.path}/commons-collections-3.1
commons-collections.lib=${commons-collections.home}
-commons-collections.jar=${commons-collections.lib}/commons-collections-
2.1.1.jar
-commons-collections.loc=${base-
jakarta.loc}/commons/collections/binaries/commons-collections-2.1.1.tar
.gz
+commons-collections.jar=${commons-collections.lib}/commons-collections-
3.1.jar
+commons-collections.loc=${base-
jakarta.loc}/commons/collections/binaries/commons-collections-3.1.tar.g
z
# - Commons Launcher, version 0.9 or later -
1.87 +5 -2
jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- changelog.xml 5 Aug 2004 13:10:35 - 1.86
+++ changelog.xml 5 Aug 2004 20:10:48 - 1.87
@@ -14,7 +14,7 @@
body
-section name=Tomcat 5.1.0 (yoavs)
+section name=Tomcat 5.5.0 (yoavs)
subsection name=General
changelog
fix
@@ -33,7 +33,10 @@
bug29826/bug: Modified setclasspath.bat exit code to 1.
(yoavs)
/fix
update
-Updated status page, basically completely rewritten for
Tomcat
5.1. (yoavs)
+Updated status page, mostly rewritten. (yoavs)
+ /update
+ update
+Updated Jakarta-Commons dependencies: BeanUtils to 1.7.0,
Collections to 3.1. (yoavs)
/update
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Can someone please unsubscribe me from this list? I have sent about 20 email to unsubscribe and I'm still recieving them. THanks Mike Currie Senior Web Developer New Century Mortgage Direct 949 743 7037 Mobile 949 279 4358 Fax 866 281 0360 This electronic message transmission contains information from New Century which may be confidential or privileged. This information is intended for the use of the individuals or entity named in the message. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this transmission is strictly prohibited. If you have received this electronic transmission in error, please notify us immediately by telephone and delete the message from your system. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 8:35 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml yoavs 2004/07/26 08:34:32 Modified:catalina/src/bin setclasspath.bat webapps/docs changelog.xml Log: Addressed Bugzilla 29826. Revision ChangesPath 1.7 +2 -2 jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat Index: setclasspath.bat === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- setclasspath.bat 12 Feb 2004 21:38:56 - 1.6 +++ setclasspath.bat 26 Jul 2004 15:34:31 - 1.7 @@ -52,6 +52,6 @@ goto end :exit -exit +exit /b 1 :end 1.76 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.75 retrieving revision 1.76 diff -u -r1.75 -r1.76 --- changelog.xml 23 Jul 2004 14:13:41 - 1.75 +++ changelog.xml 26 Jul 2004 15:34:31 - 1.76 @@ -29,6 +29,9 @@ fix bug30245/bug: Corrected Connector documentation to list address as a common attribute. (yoavs) /fix + fix +bug29826/bug: Modified setclasspath.bat exit code to 1. (yoavs) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: billbarker2004/07/26 10:04:04 Modified:webapps/docs changelog.xml Log: Fix version #. What ever the next version is that is released from here, it is not going to be called 5.0.x. I did refer to that with the 5.5 revision number, because the API isn't compatible, and because I wanted to tweak it for JDK 1.5 (or JDK 5.0, whatever). So it's a lot of 5s. Revision ChangesPath 1.78 +1 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.77 retrieving revision 1.78 diff -u -r1.77 -r1.78 --- changelog.xml 26 Jul 2004 15:39:13 - 1.77 +++ changelog.xml 26 Jul 2004 17:04:04 - 1.78 @@ -14,7 +14,7 @@ body -section name=Tomcat 5.0.28 (yoavs) +section name=Tomcat 5.5.0 (yoavs) subsection name=General changelog fix Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
subsection name=Webapps +changelog + fix +bug29779/bug: Admin/Examples SetCharacterEncodingFilter wrong package. (yoavs) + /fix +/changelog /subsection /section You do realize that you are making changes in HEAD, but documenting them as being for 5.0.28 :). This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
[EMAIL PROTECTED] wrote: yoavs 2003/12/16 18:42:26 Modified:webapps/docs changelog.xml Log: Started changelog for 5.0.17. It's probably easier if either: - only one guy does it (so he knows what needs to be in the changelog) - everyone updates the changelog when making a change As the second is too messy and generates too much mail, I think it's the RM's duty to do the first item :) This is really boring, of course, but at least it's manageable this way. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
I prefer only the RM updating changelog. -Tim Remy Maucherat wrote: [EMAIL PROTECTED] wrote: yoavs 2003/12/16 18:42:26 Modified:webapps/docs changelog.xml Log: Started changelog for 5.0.17. It's probably easier if either: - only one guy does it (so he knows what needs to be in the changelog) - everyone updates the changelog when making a change As the second is too messy and generates too much mail, I think it's the RM's duty to do the first item :) This is really boring, of course, but at least it's manageable this way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Tim Funk wrote: I prefer only the RM updating changelog. Or we would need to disable commit messages for changelog.xml ;-) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
