Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked"
On Mon, 2010-09-20 at 16:31 -0700, Mark Thomas wrote: > I agree the spec isn't crystal clear. > > I took the use of the word "partial" to refer to requests and URIs in > the welcome file to mean that the "complete" request was the result of > adding the welcome file. With that in mind, it seems natural that the > filter should apply post welcome file addition. But that is just an > opinion. I'm still leaning towards WONTFIX. > > I could be convinced that this is a bug but I haven't see anything that > might support such an argument so far. If he wants universal filtering, he can use "/*" I think, right ? As welcome files are not to be done by the default Servlet as a forward, and a HTTP redirect is not desirable either, there's no possibility to invoke a Servlet on / with REQUEST. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked"
On Tue, Sep 21, 2010 at 9:30 AM, Remy Maucherat wrote: > On Mon, 2010-09-20 at 16:31 -0700, Mark Thomas wrote: > If he wants universal filtering, he can use "/*" I think, right ? Yes that should work. I use that all the time. And "" is supposed to be root not "/" according to the specs. > As welcome files are not to be done by the default Servlet as a forward, > and a HTTP redirect is not desirable either, there's no possibility to > invoke a Servlet on / with REQUEST. Yeah the specs are pretty bad on this. They say can be done as a redirect, a forward or some internal mechanism. So you can take whatever you want out of this. If it was a forward it would work or I guess if the order was changed. So to get this straight Rémy you think it should be a WONT FIX too? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.30 released
I'm done on my changes for 1.2.31 Log rotation should be done (pending testing by someone other than me ;), and a quick scan of the IIS bugs didn't reveal any obvious candidates for further fixes. cheers tim On Wed, Sep 15, 2010 at 10:48 AM, Rainer Jung wrote: > On 14.09.2010 01:14, William A. Rowe Jr. wrote: > >> On 9/13/2010 6:11 PM, Tim Whittington wrote: >> >>> I agree with this approach. >>> >>> I'd like to get a 1.2.31 release out sometime to release the ISAPI >>> Redirector log rotation though, before we start on 1.3. >>> >> >> Just to make sure there is no confusion, I'm speaking of dropping >> apache-1.3, >> prior to 1.2.31, or a fresh trunk/ for connectors-1.3 work. >> > > I agree on the latter, i.e. not removing the old cruft in the 1.2.x release > series, but soon starting a mod_jk 1.3.x series with removed cruft. I'm fine > with doing 1.2.31 before branching if e.g. Tim can finish what he wants to > add in a few weeks. > > Regards, > > Rainer > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked"
On Tue, 2010-09-21 at 10:15 +0200, Wesley Acheson wrote: > So to get this straight Rémy you think it should be a WONT FIX too? For the actual resolution, you have to talk with Mark. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49511] IIS 7.5 incorrect logging: pfc->pFilterContext is per-connection not per-request
https://issues.apache.org/bugzilla/show_bug.cgi?id=49511 --- Comment #4 from Tim Whittington 2010-09-21 06:37:04 EDT --- > I think the reason for this is that the redirect filter was only set to serve the jsp files (dynamic content) but the js and gif (the static content) were served by the IIS itself. > So the filter did not update the uri and query info when the js and gif requests were processed. This might actually explain what you're seeing - since the pFilterContext is allocated per session/connection we store the uri/query on the .jsp request, and if the subsequent requests for the .js and .gif are served by IIS, we won't overwrite that data. In the SF_NOTIFY_LOG notification, we just check whether pFilterContext is allocated (which only means that any previous request on that connection was mapped) and blindly overwrite the log information even if we didn't map the current request. I'll commit a fix to guard against this behaviour - if you could test it that'd be appreciated. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.30 released
On 09/21/2010 12:05 PM, Tim Whittington wrote: I'm done on my changes for 1.2.31 Log rotation should be done (pending testing by someone other than me ;), and a quick scan of the IIS bugs didn't reveal any obvious candidates for further fixes. Coll. I'll do some testings on IIS6 and IIS7 I would like that we create a RC pretty soon (this month) and finally create 1.2 branch Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r999308 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Author: timw
Date: Tue Sep 21 11:05:44 2010
New Revision: 999308
URL: http://svn.apache.org/viewvc?rev=999308&view=rev
Log:
Fix #49511 - track when we map a request into the ISAPI Redirector during
filter notification, and only correct the IIS log information for individual
requests within a multi-request session/connection that were actually mapped.
Modified:
tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=999308&r1=999307&r2=999308&view=diff
==
--- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Tue Sep 21 11:05:44 2010
@@ -536,6 +536,8 @@ typedef struct isapi_log_data_t isapi_lo
struct isapi_log_data_t {
char uri[INTERNET_MAX_URL_LENGTH];
char query[INTERNET_MAX_URL_LENGTH];
+int request_matched;/* Whether this request (within a
multi-request connection)
+ was handled and needs the log values
adjusted */
};
typedef struct iis_info_t iis_info_t;
@@ -1856,6 +1858,12 @@ DWORD WINAPI HttpFilterProc(PHTTP_FILTER
SetHeader(pfc, WORKER_HEADER_INDEX, NULL);
SetHeader(pfc, TOMCAT_TRANSLATE_HEADER_NAME, NULL);
+// Suppress logging of original uri/query when we don't map a URL
+if (pfc->pFilterContext) {
+isapi_log_data_t *ld = (isapi_log_data_t *)pfc->pFilterContext;
+ld->request_matched = JK_FALSE;
+}
+
if (!GetHeader(pfc, "url", (LPVOID) uri, (LPDWORD) & sz)) {
jk_log(logger, JK_LOG_ERROR,
"error while getting the url");
@@ -2055,12 +2063,14 @@ DWORD WINAPI HttpFilterProc(PHTTP_FILTER
memset(ld, 0, sizeof(isapi_log_data_t));
StringCbCopy(ld->uri, INTERNET_MAX_URL_LENGTH, forwardURI);
StringCbCopy(ld->query, INTERNET_MAX_URL_LENGTH, squery);
+ld->request_matched = JK_TRUE;
pfc->pFilterContext = ld;
} else {
isapi_log_data_t *ld = (isapi_log_data_t
*)pfc->pFilterContext;
memset(ld, 0, sizeof(isapi_log_data_t));
StringCbCopy(ld->uri, INTERNET_MAX_URL_LENGTH, forwardURI);
StringCbCopy(ld->query, INTERNET_MAX_URL_LENGTH, squery);
+ld->request_matched = JK_TRUE;
}
}
else {
@@ -2084,9 +2094,11 @@ DWORD WINAPI HttpFilterProc(PHTTP_FILTER
else if (dwNotificationType == SF_NOTIFY_LOG) {
if (pfc->pFilterContext) {
isapi_log_data_t *ld = (isapi_log_data_t *)pfc->pFilterContext;
-HTTP_FILTER_LOG *pl = (HTTP_FILTER_LOG *)pvNotification;
-pl->pszTarget = ld->uri;
-pl->pszParameters = ld->query;
+if (ld->request_matched) {
+HTTP_FILTER_LOG *pl = (HTTP_FILTER_LOG *)pvNotification;
+pl->pszTarget = ld->uri;
+pl->pszParameters = ld->query;
+}
}
}
return SF_STATUS_REQ_NEXT_NOTIFICATION;
Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=999308&r1=999307&r2=999308&view=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Tue Sep 21 11:05:44 2010
@@ -60,6 +60,10 @@
Old behaviour can be enabled by defining USE_CGI_HEADERS. (timw)
+ 49511: IIS: Do not override IIS log information when
subsequent
+ requests on a keep-alive connection are not mapped into the
ISAPI Redirector. (timw)
+
+
Docs: Document SSLOptions needed for SSL information forwarding.
(rjung)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49511] IIS 7.5 incorrect logging: pfc->pFilterContext is per-connection not per-request
https://issues.apache.org/bugzilla/show_bug.cgi?id=49511 --- Comment #5 from Tim Whittington 2010-09-21 07:08:25 EDT --- I've committed a fix to prevent logging unless we actually mapped the current request into the ISAPI Redirector into trunk. Can you please build and test this version (or alternatively apply the patch I've attached) and see if this resolves the issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49511] IIS 7.5 incorrect logging: pfc->pFilterContext is per-connection not per-request
https://issues.apache.org/bugzilla/show_bug.cgi?id=49511 --- Comment #6 from Tim Whittington 2010-09-21 07:09:19 EDT --- Created an attachment (id=26060) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26060) Patch to prevent override of logging for unmapped requests -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.30 released
I just committed a proposed fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=49511 - if can simulate the required conditions that could bear some testing as well. cheers tim On Tue, Sep 21, 2010 at 10:49 PM, Mladen Turk wrote: > On 09/21/2010 12:05 PM, Tim Whittington wrote: > >> I'm done on my changes for 1.2.31 >> Log rotation should be done (pending testing by someone other than me ;), >> and a quick scan of the IIS bugs didn't reveal any obvious candidates for >> further fixes. >> >> > Coll. I'll do some testings on IIS6 and IIS7 > > I would like that we create a RC pretty soon (this month) > and finally create 1.2 branch > > > > Regards > -- > ^TM > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
RE: Bug 49914 - "Filter on url-pattern of "/" is not invoked"
> From: Wesley Acheson [mailto:wesley.ache...@gmail.com] > Subject: Re: Bug 49914 - "Filter on url-pattern of "/" is not invoked" > And "" is supposed to be root not "/" according to the specs. Don't think so. The empty string is used only to specify the path of the default context, not pattern matching for a servlet or filter within a context. For global matching in servlets and filters, you must use "/*"; to specify the default servlet you use "/". Using a url-pattern of "/" for a filter doesn't seem to make any sense, since there is no concept in the spec of a "default filter". - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49914] Filter on url-pattern of "/" is not invoked
https://issues.apache.org/bugzilla/show_bug.cgi?id=49914 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Mark Thomas 2010-09-21 09:40:33 EDT --- Managed to speak to the spec lead and a couple of EG members about this. The intention (although only implied rather than explicitly stated) of the Servlet spec is that the welcome file mapping (if required) is applied before matching with any filter URL patterns. Hopefully the next maintenance release will have some clarifications in this area. I am therefore closing this as won't fix. If the spec had been clearer, I probably would have closed it as invalid. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48692] Provide option to parse application/x-www-form-urlencoded PUT requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=48692 --- Comment #8 from Christopher Schultz 2010-09-21 10:56:59 EDT --- Mark, I've just glanced-over RFC 2616 and I can't find any HTTP methods (defined in section 9) that specifically prohibit a request body. On the other hand, section 4.3 says: " The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. " There's a short discussion that can be found here: http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0103.html I tend to agree with one of the contributor's assertion that the principle of robustness applies, here: we shouldn't actively prohibit a request body from being sent, here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
NamingContext Possible Bug
Hello folks,
In NamingContext implementation, if "lookup()" is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But with
the current implementation, it is not possible to write such an object factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
WDYT?
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; ---> CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
("namingContext.failResolvingReference"), e);
throw new NamingException(e.getMessage());
}
}
...
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NamingContext Possible Bug
Sorry but skip the question!
Thanks;
--Gurkan
- Original Message
From: Gurkan Erdogdu
To: dev@tomcat.apache.org
Sent: Tue, September 21, 2010 6:30:43 PM
Subject: NamingContext Possible Bug
Hello folks,
In NamingContext implementation, if "lookup()" is a Reference, current
implementation caches the result of the NamingManager # getObjectInstance via
following statements and changes the type of the entry. In the following
lookups, same object is returned. I would like to write ObjectFactory that
returns new instance for each time lookup is called on its reference. But with
the current implementation, it is not possible to write such an object factory
because of aferomentioned sitaution. I think that entry must be stay as
Reference instead of changing entry type.
WDYT?
NamingContext class:
protected Object lookup(Name name, boolean resolveLinks)
throws NamingException {
.
} else if (entry.type == NamingEntry.REFERENCE) {
try {
Object obj = NamingManager.getObjectInstance
(entry.value, name, this, env);
if (obj != null) {
entry.value = obj;
entry.type = NamingEntry.ENTRY; ---> CHANGES type of
the naming entry
}
return obj;
} catch (NamingException e) {
throw e;
} catch (Exception e) {
log.warn(sm.getString
("namingContext.failResolvingReference"), e);
throw new NamingException(e.getMessage());
}
}
...
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r999482 - /tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Author: mturk Date: Tue Sep 21 16:16:10 2010 New Revision: 999482 URL: http://svn.apache.org/viewvc?rev=999482&view=rev Log: Update changelog Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=999482&r1=999481&r2=999482&view=diff == --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Tue Sep 21 16:16:10 2010 @@ -49,6 +49,14 @@ after the response has been finished. (rjung) +AJP: Log the local and remote socket address. (mturk) + + +Watchdog: Move the maintain workers outside the critical +section allowing other threads to use the connection +pool during maintenance. (mturk) + + Apache: Added version number resource for mod_jk.so on Windows. (timw) @@ -406,13 +414,13 @@ connection timeout but higher operational timeouts. (mturk) -AJP13: +AJP13: [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5519";>CVE-2008-5519] Always send initial POST packet even if the client disconnected after sending request but before providing POST data. In that case or in case the client broke the connection in a middle of read send an zero size packet -informing container about broken client connection. (mturk) +informing container about broken client connection. (mturk) AJP13: Added connection_acquire_timeout directive for setting the @@ -742,7 +750,7 @@ as a prefix. (rjung) -jkstatus: Fix correct parameter validation at JkStatusUpdateTask and +jkstatus: Fix correct parameter validation at JkStatusUpdateTask and JkStatusUpdateLoadbalancerTask ant tasks. Reported by Christian Mittendorf. (pero) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49929] AJP APR connector to mod_jk can result in SEND_BODY_CHUNK message after END_RESPONSE message
https://issues.apache.org/bugzilla/show_bug.cgi?id=49929 --- Comment #5 from Mladen Turk 2010-09-21 13:00:11 EDT --- I have tried your test servlet, but I cannot see anything suspicious. There is no additional packets following the lorem ipsum. Tested on Tomcat 6.0.29, 6.0.x trunk and Tomcat 7. Both APR and JIO endpoints behave the same. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49929] AJP APR connector to mod_jk can result in SEND_BODY_CHUNK message after END_RESPONSE message
https://issues.apache.org/bugzilla/show_bug.cgi?id=49929 --- Comment #6 from brett.dellegra...@intact-is.com 2010-09-21 13:19:54 EDT --- Hi, When using the test servlet the problem appears on the next request when its on the same socket so its a good idea to have a static file around to request immediately after executing the test servlet. The way we did this was to use Jmeter with only 1 thread but executing the two requests in sequence with no wait time. With Apache HTTPD you should see mod_jk (in debug mode) detect an explicit flush packet and reset the socket instead of the usual CPONG expected response as reported originally. Thanks, Brett -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r999523 - /tomcat/trunk/webapps/docs/config/systemprops.xml
Author: kkolinko Date: Tue Sep 21 18:21:38 2010 New Revision: 999523 URL: http://svn.apache.org/viewvc?rev=999523&view=rev Log: correct a typo Modified: tomcat/trunk/webapps/docs/config/systemprops.xml Modified: tomcat/trunk/webapps/docs/config/systemprops.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/systemprops.xml?rev=999523&r1=999522&r2=999523&view=diff == --- tomcat/trunk/webapps/docs/config/systemprops.xml (original) +++ tomcat/trunk/webapps/docs/config/systemprops.xml Tue Sep 21 18:21:38 2010 @@ -240,13 +240,13 @@ org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR. org.apache.tomcat.util.http.ServerCookie.STRICT_NAMING. The tldNamespaceAware attribute of any - Context element. + Context element. The tldValidation attribute of any - Context element. + Context element. The xmlNamespaceAware attribute of any - Context element. + Context element. The xmlValidation attribute of any - Context element. + Context element. Note that changing a number of the above defaults is likely to break - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r999527 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Tue Sep 21 18:36:15 2010 New Revision: 999527 URL: http://svn.apache.org/viewvc?rev=999527&view=rev Log: vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=999527&r1=999526&r2=999527&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Sep 21 18:36:15 2010 @@ -125,7 +125,12 @@ PATCHES PROPOSED TO BACKPORT: option to disable this check. https://issues.apache.org/bugzilla/attachment.cgi?id=25727 +1: markt + +1: kkolinko (if doc part is adjusted to the code) -1: + kkolinko: doc says the SKIP_* property defaults to false, but in the code the +default is true. (Maybe tie it to STRICT_SERVLET_COMPLIANCE?) +Maybe document this in the "Specification" part of the systemprops.xml, +instead of "Expression Language" as done in 7.0.2? * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49555 Correctly handle tag libraries that use functions defined in static inner @@ -133,8 +138,12 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=961948&view=rev http://svn.apache.org/viewvc?rev=963106&view=rev http://svn.apache.org/viewvc?rev=966863&view=rev - +1: markt + +1: markt, kkolinko -1: + kkolinko: I was worried that ELFunctionMapper$PrivilegedGetTccl + should be preloaded in o.a.jasper.security.SecurityClassLoad, + but from debugging it looks that it is called by Tomcat code only + (JspServlet). * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49521 http://people.apache.org/~kkolinko/patches/2010-07-17_tc6_bug49521.patch @@ -150,8 +159,14 @@ PATCHES PROPOSED TO BACKPORT: result) http://people.apache.org/~markt/patches/2010-08-23-ecj-tc6.patch http://svn.apache.org/viewvc?rev=987896&view=rev - +1: markt, rjung + +1: markt, rjung, kkolinko -1: + kkolinko: Regarding the comment added to build.properties.default: + When changing JDT version, updating TldConfig.java and TldLocationsCache.java + is a must, but the following files also mention the JDT version number: + - res/maven/jasper.pom + - eclipse.classpath + * Allow off-line building of the extras packages. Also saves downloading deps every build - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r999540 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Tue Sep 21 18:51:42 2010 New Revision: 999540 URL: http://svn.apache.org/viewvc?rev=999540&view=rev Log: vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=999540&r1=999539&r2=999540&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Sep 21 18:51:42 2010 @@ -180,8 +180,9 @@ PATCHES PROPOSED TO BACKPORT: could be extended to other components that use LifecycleSupport and expose an MBean http://people.apache.org/~markt/patches/2010-09-03-better-state-info.patch - +1: markt, kfujino + +1: markt, kfujino, kkolinko -1: + kkolinko: s/Tomact/Tomcat/ * Fix unlockAccept when the soTimeout is -1 (default). Default conf has soTimeout -1 and that will throw exception if @@ -200,7 +201,7 @@ PATCHES PROPOSED TO BACKPORT: * Fix a possible NPE when a parallel request invalidates the session before the current request has a chance to send the replication message. http://svn.apache.org/viewvc?rev=993042&view=rev - +1: markt, kfujino + +1: markt, kfujino, kkolinko -1: * Make sure Contexts defined in server.xml pick up any configClass setting from @@ -211,7 +212,8 @@ PATCHES PROPOSED TO BACKPORT: * Update commons pool to 1.5.5 http://svn.apache.org/viewvc?rev=996163&view=rev - +1: markt + (Changelog: http://commons.apache.org/pool/changes-report.html#a1.5.5) + +1: markt, kkolinko -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49924 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48692] Provide option to parse application/x-www-form-urlencoded PUT requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=48692 --- Comment #9 from Mark Thomas 2010-09-21 15:36:42 EDT --- (In reply to comment #8) > Mark, I've just glanced-over RFC 2616 and I can't find any HTTP methods > (defined in section 9) that specifically prohibit a request body. TRACE does. No others I could see. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.30 released
> On 09/21/2010 12:05 PM, Tim Whittington wrote: >> I'm done on my changes for 1.2.31 >> Log rotation should be done (pending testing by someone other than me >> ;), >> and a quick scan of the IIS bugs didn't reveal any obvious candidates >> for >> further fixes. >> > > Coll. I'll do some testings on IIS6 and IIS7 > > I would like that we create a RC pretty soon (this month) > and finally create 1.2 branch I can review the recent changes next weekend. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
