svn commit: r493978 - /tomcat/connectors/trunk/KEYS
Author: rjung Date: Mon Jan 8 00:11:18 2007 New Revision: 493978 URL: http://svn.apache.org/viewvc?view=revrev=493978 Log: Fix key fingerprint of Guenter Knauf. Modified: tomcat/connectors/trunk/KEYS Modified: tomcat/connectors/trunk/KEYS URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/KEYS?view=diffrev=493978r1=493977r2=493978 == --- tomcat/connectors/trunk/KEYS (original) +++ tomcat/connectors/trunk/KEYS Mon Jan 8 00:11:18 2007 @@ -461,8 +461,9 @@ =C30m -END PGP PUBLIC KEY BLOCK- -Type Bits/KeyIDDate User ID -pub 1024D/E55B0D0E 2007-01-01 Guenter Knauf (CODE SIGNING KEY) [EMAIL PROTECTED] +Type bits /keyIDDate User ID +pub 1024D/E55B0D0E 2007/01/01 Guenter Knauf (CODE SIGNING KEY) [EMAIL PROTECTED] + Key fingerprint = 3E6A C004 854F 3A7F 0356 6B59 2FF0 6894 E55B 0D0E -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.6 (MingW32) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Hi Rainer,
As we discussed recently, using a Tomcat Valve or a Filter to detect
invalidated session could be a good approach.
Can I have your feeling about such a Tomcat filter :
If session is invalid (or new)
- Set sendRedirect attribute of HtppResponse at the same value of
current HttpRequest path
- Invalidating the cookie
- Send Response
This filter would have to be active on disabled workers.
So when the request is (re)send by browser, mod_jk doesn't detect any
session informations and route the request to an active worker (so new
application version).
In this way, it will be transparent for the users.
Best wishes,
Anthony
Source code exemple :
if (started session.isNew()) {
// invalidating the jsessionid cookie
// set a new session cookie
Cookie newCookie = new Cookie(JSESSIONID, );
newCookie.setMaxAge(0);
String contextPath = ((HttpServletRequest) request)
.getContextPath();
if ((contextPath != null) (contextPath.length() 0)) {
newCookie.setPath(contextPath);
} else {
newCookie.setPath(/);
}
if (request.isSecure()) {
newCookie.setSecure(true);
}
((HttpServletResponse) response).addCookie(newCookie);
// set sendRedirect response
((HttpServletResponse) response)
.sendRedirect(((HttpServletRequest) request)
.getContextPath()
+ ((HttpServletRequest)
request).getServletPath());
return;
}
Rainer Jung wrote:
Hi Anthony,
Anthony Vromant schrieb:
Here is the explanation about the session validity checking :
This test aims to have users with expired sessions and URL encoded
bookmarks
(or long running browsers with cookies cached) redirected to a node
hosting the new version of the application.
If this test is not done during the update, these users will start a new
session on a
node hosting the old version of application (and so, perhaps just before
the stop of these node).
Do you agree with this ?
Ah OK, yes I agree. You could use a filter (or Valve) to redirect
requests with an invalid session to the login page without URL encoding
and invalidating the cookie. That way you would destroy the invalid
binding to this node.
If we would try to do that with mod_jk directly, mod_jk would need to
have a shadow copy of the session list, something which doesn't sound
right. OK, mod_jk could ask tomcat about the session, but we can also
simply forward and let the node delete the binding.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.7
[x] Beta On 1/5/07, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, 6.0.7 is: [ ] Alpha [ ] Beta Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Houston, we have a problem.
Re: [VOTE] Tomcat 6.0.7
Remy Maucherat wrote: Hi, 6.0.7 is: [ ] Alpha [X] Beta Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.7
Remy Maucherat wrote: Hi, 6.0.7 is: [ ] Alpha [x] Beta -- Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.7
Am 05.01.2007 um 16:46 schrieb Remy Maucherat: Hi, 6.0.7 is: [ ] Alpha [ X] Beta 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]
error-page mapping for 200?
Hi,
StandardContext.findErrorPage(int)
(http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java)
has the following
public ErrorPage findErrorPage(int errorCode) {
if (errorCode == 200) {
return (okErrorPage);
} else {
return ((ErrorPage) statusPages.get(new Integer(errorCode)));
}
}
Why would a web application configure an error-page for a response
status code of 200?
I'd expected to see something like this
if (errorCode 200)
return ((ErrorPage) statusPages.get(new Integer(errorCode)));
else
return null;
Thanks,
Arvind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41318] New: - JK Status Worker Security User Case Problem in Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41318. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41318 Summary: JK Status Worker Security User Case Problem in Windows Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] First, thank you for implementing security in JK. I know it was possible to secure it before in Apache, but in IIS, JK is run before the NTFS-Rights apply. So this is a long awaited feature. But seeing that this mainly applies to non-apache environments, it is bad that the user check done case sensitive.In IIS, especially when working with domain Users, User may com in UCase/LCase Domain\User in any combination. Even Cast differences in the Username (i.e. First letter capital or not) occour. Windows does not care, but JK does. So one can auth against IIS, but still be blocked from JK, even with the right user. In the moment we workaround this with trying to put any combination in the properties-file. But this is a hopeless fight. I understand that you might not be able to simply LCase the username because that would lose some compatibility to the unix side. But maybe you can introduce a parameter like worker.jk-manage.casesensitive=True|False ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41318] - JK Status Worker Security User Case Problem in Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41318.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41318
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |enhancement
--- Additional Comments From [EMAIL PROTECTED] 2007-01-08 10:03 ---
Hi,
good to hear, that the feature basically works :)
I'm sure you noticed, that this only secures the status worker? So we could only
discuss securing access to the status worker in an appropriate way.
I would like to consider, if we could make the string comparison case
insensitive dependent on the platform. So we could use case-insensitivity on the
Windows platform, and sesitivity on the other ones. I'm not sure about Netware,
but we could ask Günter Knauf about the habits there.
We usually use
#ifdef WIN32
to destinguish the Windows platform. Actually I don't know, if this is still
correct in times of 64 Bit Windows, but since Mladen actually does Windows 64
Bit builds since quote some time, I assume, that this is still correct.
So I would propose a patch as follows:
Index: jk_status.c
===
--- jk_status.c (revision 494133)
+++ jk_status.c (working copy)
@@ -2846,7 +2846,11 @@
unsigned int i;
denied = 1;
for (i = 0; i w-num_of_users; i++) {
+#if defined(WIN32)
+if (!strcasecmp(s-remote_user, w-user_names[i])) {
+#else
if (!strcmp(s-remote_user, w-user_names[i])) {
+#endif
denied = 0;
break;
}
Maybe you could try this to find out, if this really handdles all the cases
needed?
Thanks for the suggestion.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41318] - JK Status Worker Security User Case Problem in Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41318. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41318 --- Additional Comments From [EMAIL PROTECTED] 2007-01-08 10:28 --- Hi, this seems like a good solution. Although there might be case-insensitive auth- subsystems unter unix and sensitive ones in a windows environment (some LDAP- Systems), this is not the common way. We'd be happy to test the enhancement, but we have no build environment here. So if anyone could supply a win32 and/or win64 build, we'd test it and report back. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.7
Peter Rossbach wrote: Am 05.01.2007 um 16:46 schrieb Remy Maucherat: Hi, 6.0.7 is: [ ] Alpha [ X] Beta Ok, so this build seems to be beta then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494192 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
Author: remm Date: Mon Jan 8 12:52:40 2007 New Revision: 494192 URL: http://svn.apache.org/viewvc?view=revrev=494192 Log: - Add a new buffered field to allow flushing on each request, which should make the behavior equivalent to the old AccessLogValve. Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml?view=diffrev=494192r1=494191r2=494192 == --- tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml (original) +++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml Mon Jan 8 12:52:40 2007 @@ -49,6 +49,12 @@ attribute name=fileDateFormat description=The format for the date date based log rotation. type=java.lang.String/ + +attribute name=buffered + description=Flag to buffering. + is=true + type=boolean/ + /mbean mbean name=ErrorReportValve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494193 - in /tomcat/tc6.0.x/trunk: conf/server.xml res/confinstall/server_2.xml webapps/docs/config/valve.xml
Author: remm Date: Mon Jan 8 12:54:24 2007 New Revision: 494193 URL: http://svn.apache.org/viewvc?view=revrev=494193 Log: - Use AccessLogValve. - Update docs with buffered field. Modified: tomcat/tc6.0.x/trunk/conf/server.xml tomcat/tc6.0.x/trunk/res/confinstall/server_2.xml tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml Modified: tomcat/tc6.0.x/trunk/conf/server.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/conf/server.xml?view=diffrev=494193r1=494192r2=494193 == --- tomcat/tc6.0.x/trunk/conf/server.xml (original) +++ tomcat/tc6.0.x/trunk/conf/server.xml Mon Jan 8 12:54:24 2007 @@ -106,7 +106,7 @@ !-- Access log processes all example. Documentation at: /docs/config/valve.html -- !-- -Valve className=org.apache.catalina.valves.FastCommonAccessLogValve directory=logs +Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ -- Modified: tomcat/tc6.0.x/trunk/res/confinstall/server_2.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/confinstall/server_2.xml?view=diffrev=494193r1=494192r2=494193 == --- tomcat/tc6.0.x/trunk/res/confinstall/server_2.xml (original) +++ tomcat/tc6.0.x/trunk/res/confinstall/server_2.xml Mon Jan 8 12:54:24 2007 @@ -64,7 +64,7 @@ !-- Access log processes all example. Documentation at: /docs/config/valve.html -- !-- -Valve className=org.apache.catalina.valves.FastCommonAccessLogValve directory=logs +Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=common resolveHosts=false/ -- Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml?view=diffrev=494193r1=494192r2=494193 == --- tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml Mon Jan 8 12:54:24 2007 @@ -61,11 +61,7 @@ attribute name=className required=true pJava class name of the implementation to use. This MUST be set to strongorg.apache.catalina.valves.AccessLogValve/strong to use the -default access log valve. To use a more optimized access log valve -designed for production use, you MUST set this attribute to -strongorg.apache.catalina.valves.FastCommonAccessLogValve/strong. -In this case, only the codecommon/code and codecombined/code -patterns are supported./p +default access log valve./p /attribute attribute name=directory required=false @@ -128,6 +124,13 @@ The date format also decides how often the file is rotated. If you wish to rotate every hour, then set this value to: tt-MM-dd.HH/tt +/p + /attribute + + attribute name=buffered required=false +pDeafult true. Flag to determine if logging will be buffered. + If set to false, then access logging will be written after each + request. /p /attribute - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
do i need to build form source if i want install tomcat on 64-bit linux machine
Hello all, I would like to install tomcat on 64-bit linux machine. do i need to build it from source or can i directly take the binary files provided in the website. Is there any difference between building it from source and directly taking binaries which are i guess compiled on 32-bit machines. Thanks in advance, cheers vamsee movva
Re: do i need to build form source if i want install tomcat on 64-bit linux machine
First: this question should be directed to the user-list - users@tomcat.apache.org Second: Since tomcat is 99% java there is no difference between 32bit and 64bit versions. Just get yourself a 64bit VM and you are fine. For the 1% native code in tcpnative libs you probably have to recompile it or run with ia32 libs. However, the above mentioned user list is again the best place to ask. regards Leon On 1/8/07, vamsee movva [EMAIL PROTECTED] wrote: Hello all, I would like to install tomcat on 64-bit linux machine. do i need to build it from source or can i directly take the binary files provided in the website. Is there any difference between building it from source and directly taking binaries which are i guess compiled on 32-bit machines. Thanks in advance, cheers vamsee movva - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41322] New: - http chunked encoding missing chunk length
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41322 Summary: http chunked encoding missing chunk length Product: Tomcat 5 Version: 5.5.17 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connector:HTTP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm working on a large project using JBOSS 4.0.4GA (which bundles Tomcat 5.5.17) and we've been experiencing intermittent loss of http requests. For example, occasionally a click on a submit button sends off a request to the server which completes successfully but the response is never displayed in the browser. What happens then depends on the browser; Firefox just remains on the original page while IE shows an error page. This really stuffs up Selenium automated tests, and is a user issue too - even in Firefox, as we use javascript to disable the submit button after first use to prevent double-submits :=(. This is reproduceable with Firefox 1.5 , Firefox 2.0 and IE6 on Windows, and Firefox 1.5 on Linux, so I'm fairly sure it isn't a browser-side issue. It's also reproduceable within the work environment and in my home system so it's not likely to be a network issue. It also happens with browser and server on same machine. The problem appears to also occur for GET requests on things like icons, css, javascript referenced from HTML pages. Just clicking the search button on one of the webapp screens repeatedly eventually causes the problem. About every 100 clicks or so, an icon will not be present, or styles will be missing, or the jscookmenu menu will display as a table due to the javascript not being loaded. However the responses to POST requests are the ones more frequently hit. I've tried to isolate a smaller test case but haven't yet succeeded, and our whole app cannot be posted for debugging, sorry. I've used Wireshark (aka Ethereal) to log network packets, and it looks to me like Tomcat is occasionally failing to send a chunk-length field when returning a chunked response, causing the browser to drop the connection and ignore the response. I *suspect* that the intermittent part is related to the maxKeepAliveRequests property, as: (a) the problem occurs more frequently when I set maxKeepAliveRequests to a low value (eg 5). (b) the wireshark logs I have always show a Connection: close header on those requests that also have what I think are bad chunked encoding. I've checked bugzilla and can't find a report that seems related to this. I've also checked the commit history for directory http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11 and cannot see anything relevant since the 5.5.17 release (r394159) so presume it isn't fixed in any later release than the one that comes with JBoss 4.0.4GA. Files focus-hang-1.pcap and focus-hang-3.pcap show two examples of the problem; these can be loaded in Wireshark/Ethereal to view the logged packets. In these logs the machine running the browser is 10.1.1.8 (Firefox 1.5 on Ubuntu Linux), and the machine running JBoss is 10.1.1.3 (Windows XP). Note that I'm not an expert in raw HTTP protocol, so may have misunderstood something here; any correction is very welcome. The jboss logs on the server show no problems. Here's a brief rundown for network capture file focus-hang-1.pcap. First, a good response example from this file: packet 39: * start of a good response. Note, however that header Transfer-Encoding: chunked is emitted twice(?). Transfer-encoding: chunked\r\n ... Transfer-encoding: chunked\r\n \r\n 2000\r\n (chunk size) (html data starts) packet 49: See end of packet for next chunk size marker (2000) packet 74: towards end, see \r\n0\r\n, which is a zero-size chunk, ie marks the end of the http response. Now a bad one: Packet 473: start of an HTTP Post request from the browser packet 474: server acks 473 packet 475: rest of post request packet 476: server acks 475 packet 477: start of (bad) response. * Transfer-encoding: chunked is present (but only once) * Connection: close is present * html data starts without any chunk length field. At packet 493, the client starts sending RST packets; I presume because the browser code has closed the socket after encountering errors processing the input data. For file focus-hang-3.pcap, the bad response starts at packet 969. Any comments/workarounds/etc would be very welcome. Even yes I've seen this too would be nice; it's a major issue on a pretty large project. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because:
DO NOT REPLY [Bug 41322] - http chunked encoding missing chunk length
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41322 --- Additional Comments From [EMAIL PROTECTED] 2007-01-08 16:07 --- Created an attachment (id=19376) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19376action=view) wireshark/ethereal capture file network capture file as described in bug body. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41322] - http chunked encoding missing chunk length
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41322 --- Additional Comments From [EMAIL PROTECTED] 2007-01-08 16:07 --- Created an attachment (id=19377) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19377action=view) wireshark/ethereal capture file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41322] - http chunked encoding missing chunk length
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41322 --- Additional Comments From [EMAIL PROTECTED] 2007-01-08 16:29 --- Sorry, correction to SVN url. I checked http://svn.apache.org/repos/asf/tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/ for relevant commits (not the tc6.x dir as pasted into original description). I did also look at the tc6.x changes but couldn't see anything obviously relevant.. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494290 - /tomcat/tc6.0.x/trunk/res/maven/
Author: fhanik Date: Mon Jan 8 17:16:05 2007 New Revision: 494290 URL: http://svn.apache.org/viewvc?view=revrev=494290 Log: Tomcat's maven publish script Added: tomcat/tc6.0.x/trunk/res/maven/ tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom.tmp tomcat/tc6.0.x/trunk/res/maven/catalina-ha.pom tomcat/tc6.0.x/trunk/res/maven/catalina.pom tomcat/tc6.0.x/trunk/res/maven/coyote.pom tomcat/tc6.0.x/trunk/res/maven/el-api.pom tomcat/tc6.0.x/trunk/res/maven/jasper-el.pom tomcat/tc6.0.x/trunk/res/maven/jasper-jdt.pom tomcat/tc6.0.x/trunk/res/maven/jasper.pom tomcat/tc6.0.x/trunk/res/maven/jsp-api.pom tomcat/tc6.0.x/trunk/res/maven/juli.pom tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default tomcat/tc6.0.x/trunk/res/maven/servlet-api.pom tomcat/tc6.0.x/trunk/res/maven/tribes.pom Added: tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom?view=autorev=494290 == --- tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom (added) +++ tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom Mon Jan 8 17:16:05 2007 @@ -0,0 +1,7 @@ +?xml version=1.0 encoding=UTF-8?project + modelVersion4.0.0/modelVersion + groupIdorg.apache.tomcat/groupId + artifactIdannotations-api/artifactId + version@MAVEN.DEPLOY.VERSION@/version + descriptionAnnotations Package/description +/project \ No newline at end of file Added: tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom.tmp URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom.tmp?view=autorev=494290 == --- tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom.tmp (added) +++ tomcat/tc6.0.x/trunk/res/maven/annotations-api.pom.tmp Mon Jan 8 17:16:05 2007 @@ -0,0 +1,7 @@ +?xml version=1.0 encoding=UTF-8?project + modelVersion4.0.0/modelVersion + groupIdorg.apache.tomcat/groupId + artifactIdannotations-api/artifactId + version6.0.7-SNAPSHOT/version + descriptionAnnotations Package/description +/project \ No newline at end of file Added: tomcat/tc6.0.x/trunk/res/maven/catalina-ha.pom URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/catalina-ha.pom?view=autorev=494290 == --- tomcat/tc6.0.x/trunk/res/maven/catalina-ha.pom (added) +++ tomcat/tc6.0.x/trunk/res/maven/catalina-ha.pom Mon Jan 8 17:16:05 2007 @@ -0,0 +1,39 @@ +?xml version=1.0 encoding=UTF-8?project + modelVersion4.0.0/modelVersion + groupIdorg.apache.tomcat/groupId + artifactIdcatalina-ha/artifactId + version@MAVEN.DEPLOY.VERSION@/version + descriptionTomcat High Availability Implementation/description + dependencies +dependency + groupIdorg.apache.tomcat/groupId + artifactIdcoyote/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency +dependency + groupIdorg.apache.tomcat/groupId + artifactIdservlet-api/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency +dependency + groupIdorg.apache.tomcat/groupId + artifactIdjuli/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency +dependency + groupIdorg.apache.tomcat/groupId + artifactIdtribes/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency +dependency + groupIdorg.apache.tomcat/groupId + artifactIdcatalina/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency + /dependencies +/project Added: tomcat/tc6.0.x/trunk/res/maven/catalina.pom URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/catalina.pom?view=autorev=494290 == --- tomcat/tc6.0.x/trunk/res/maven/catalina.pom (added) +++ tomcat/tc6.0.x/trunk/res/maven/catalina.pom Mon Jan 8 17:16:05 2007 @@ -0,0 +1,33 @@ +?xml version=1.0 encoding=UTF-8?project + modelVersion4.0.0/modelVersion + groupIdorg.apache.tomcat/groupId + artifactIdcatalina/artifactId + version@MAVEN.DEPLOY.VERSION@/version + descriptionTomcat Servlet Engine Core Classes and Standard implementations/description + dependencies +dependency + groupIdorg.apache.tomcat/groupId + artifactIdcoyote/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency +dependency + groupIdorg.apache.tomcat/groupId + artifactIdservlet-api/artifactId + version@MAVEN.DEPLOY.VERSION@/version + scopecompile/scope +/dependency +dependency + groupIdorg.apache.tomcat/groupId +
Connector bufferSize 8K restriction
I posted a long while ago about not being able to decrease the
response buffer below 8K.
http://marc.theaimsgroup.com/?l=tomcat-devm=109218414305332w=2
See also:
Re: AJP/Java connector issues http://marc.theaimsgroup.com/?l=tomcat-
devm=111653712502047w=2
I realize that I'm not familiar with all the low level reasons why
this is such a bad thing but IMO, it seems like a reasonable tradeoff
depending on the situation to increase the the number of packets
going across the network in favor of faster initial response times.
At the very least, I think it would be a good thing if it was
documented with the Tomcat Connector configuration for bufferSize
that the it cannot be decreased and preferably also why. Even better
if that documentation could just advise and leave the decision up to
the deployer. Actually the documentation for the AJP connector says
that the default bufferSize = -1(not buffered). From what I can see,
I don't think the setting has any effect on the actual buffer size.
I've applied the following patch for us, but I wasn't sure why it(or
something similar) would be bad for the Tomcat code base in general.
I did notice that Connector.getBufferSize() is deprecated, however
this would allow each of the different Connector implementations to
override with their own default bufferSize values.
-lenny
Index: catalina/src/share/org/apache/catalina/connector/Response.java
===
--- catalina/src/share/org/apache/catalina/connector/
Response.java (revision 494201)
+++ catalina/src/share/org/apache/catalina/connector/
Response.java (working copy)
@@ -129,12 +129,7 @@
*/
public void setConnector(Connector connector) {
this.connector = connector;
-if(AJP/1.3.equals(connector.getProtocol())) {
-// default size to size of one ajp-packet
-outputBuffer = new OutputBuffer(8184);
-} else {
-outputBuffer = new OutputBuffer();
-}
+outputBuffer = new OutputBuffer(connector.getBufferSize());
outputStream = new CoyoteOutputStream(outputBuffer);
writer = new CoyoteWriter(outputBuffer);
}
Lenny Marks
Software Architect
American Physical Society
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector bufferSize 8K restriction
Sorry. I forgot to include that this is from the Tomcat-5.5.20 source.
On Jan 8, 2007, at 9:17 PM, Lenny Marks wrote:
I posted a long while ago about not being able to decrease the
response buffer below 8K.
http://marc.theaimsgroup.com/?l=tomcat-devm=109218414305332w=2
See also:
Re: AJP/Java connector issues http://marc.theaimsgroup.com/?
l=tomcat-devm=111653712502047w=2
I realize that I'm not familiar with all the low level reasons why
this is such a bad thing but IMO, it seems like a reasonable
tradeoff depending on the situation to increase the the number of
packets going across the network in favor of faster initial
response times. At the very least, I think it would be a good thing
if it was documented with the Tomcat Connector configuration for
bufferSize that the it cannot be decreased and preferably also why.
Even better if that documentation could just advise and leave the
decision up to the deployer. Actually the documentation for the
AJP connector says that the default bufferSize = -1(not buffered).
From what I can see, I don't think the setting has any effect on
the actual buffer size. I've applied the following patch for us,
but I wasn't sure why it(or something similar) would be bad for the
Tomcat code base in general. I did notice that
Connector.getBufferSize() is deprecated, however this would allow
each of the different Connector implementations to override with
their own default bufferSize values.
-lenny
Index: catalina/src/share/org/apache/catalina/connector/Response.java
===
--- catalina/src/share/org/apache/catalina/connector/
Response.java (revision 494201)
+++ catalina/src/share/org/apache/catalina/connector/
Response.java (working copy)
@@ -129,12 +129,7 @@
*/
public void setConnector(Connector connector) {
this.connector = connector;
-if(AJP/1.3.equals(connector.getProtocol())) {
-// default size to size of one ajp-packet
-outputBuffer = new OutputBuffer(8184);
-} else {
-outputBuffer = new OutputBuffer();
-}
+outputBuffer = new OutputBuffer(connector.getBufferSize());
outputStream = new CoyoteOutputStream(outputBuffer);
writer = new CoyoteWriter(outputBuffer);
}
Lenny Marks
Software Architect
American Physical Society
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Lenny Marks
[EMAIL PROTECTED]
svn commit: r494304 - in /tomcat/tc6.0.x/trunk/res/maven: mvn-pub.xml mvn.properties.default servlet-api.pom
Author: fhanik
Date: Mon Jan 8 18:27:20 2007
New Revision: 494304
URL: http://svn.apache.org/viewvc?view=revrev=494304
Log:
fixed xml error
Modified:
tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default
tomcat/tc6.0.x/trunk/res/maven/servlet-api.pom
Modified: tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml?view=diffrev=494304r1=494303r2=494304
==
--- tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml (original)
+++ tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml Mon Jan 8 18:27:20 2007
@@ -15,7 +15,7 @@
To do password less upload, you can modify either
$MAVE_HOME/conf/settings.xml or ~/.m2/settings.xml and add this snippet
-server
+server
idapache.snapshots/id
usernameyourusername/username
privateKey/home/yourusername/.ssh/id_rsa/privateKey
@@ -44,6 +44,7 @@
arg value=-DrepositoryId=${maven.repo.repositoryId}/
arg value=-Durl=${maven.repo.url}/
arg value=-DpomFile=${pom}.tmp/
+ arg value=-Dmaven.scp.executable=${maven.scp.executable}/
/exec
delete file=${pom}.tmp/
/target
Modified: tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default?view=diffrev=494304r1=494303r2=494304
==
--- tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default (original)
+++ tomcat/tc6.0.x/trunk/res/maven/mvn.properties.default Mon Jan 8 18:27:20
2007
@@ -6,3 +6,4 @@
tomcat.lib.path=C:/development/tomcat/6.0/tc6.0.x/trunk/output/build/lib
tomcat.bin.path=C:/development/tomcat/6.0/tc6.0.x/trunk/output/build/bin
tomcat.pom.path=C:/development/tomcat/6.0/tc6.0.x/trunk/res/maven
+maven.scp.executable=c:/software/unix/usr/local/wbin/pscp.exe -i
/home/fhanik/.ssh/id_rsa
Modified: tomcat/tc6.0.x/trunk/res/maven/servlet-api.pom
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/servlet-api.pom?view=diffrev=494304r1=494303r2=494304
==
--- tomcat/tc6.0.x/trunk/res/maven/servlet-api.pom (original)
+++ tomcat/tc6.0.x/trunk/res/maven/servlet-api.pom Mon Jan 8 18:27:20 2007
@@ -5,4 +5,3 @@
version@MAVEN.DEPLOY.VERSION@/version
descriptionjavax.servlet package/description
/project
-s
\ No newline at end of file
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r494306 - /tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
Author: fhanik
Date: Mon Jan 8 18:32:48 2007
New Revision: 494306
URL: http://svn.apache.org/viewvc?view=revrev=494306
Log:
read property files in order, not quote working on windows yet
Modified:
tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
Modified: tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml?view=diffrev=494306r1=494305r2=494306
==
--- tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml (original)
+++ tomcat/tc6.0.x/trunk/res/maven/mvn-pub.xml Mon Jan 8 18:32:48 2007
@@ -22,8 +22,8 @@
passphrase/passphrase
/server
--
- property file=${basedir}/mvn.properties.default/
property file=${basedir}/mvn.properties/
+ property file=${basedir}/mvn.properties.default/
target name=maven-deploy
!--replace the version in the pom--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Script for publishing JARs to Maven Repo done
Paul, got your jars included, http://people.apache.org/repo/m2-snapshot-repository/org/apache/tomcat/ (check out 6.0.7-SNAPSHOT) next steps, 1. get these to a staging server, 2. get the windows version of the publish script working (currently having some private key issues between maven and pscp) 3. once approved from the staging server, move to production server 4. separate snapshot release from a release release (nightly vs when tomcat has an approved release) Filip Paul McMahan wrote: Thanks for setting this up. I'm integrating tomcatv6 into Geronimo 2.0 so having these jar published in a maven repo is a big help since we build using maven. Can you also publish the following jars from lib? Geronimo needs them to run an embedded tomcat engine. catalina.jar catalina-ha.jar jasper.jar jasper-jdt.jar tomcat-coyote.jar I can send you a patch for the publish script if that would help. Best wishes, Paul McMahan On 1/5/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: I've created a script that publishes our JARs to a Maven repo (in this first release, the script is for the apache snapshot repository) all you need to do is, unzip, edit the mvn.properties.default or create a mvn.properties file and run the ANT script http://people.apache.org/~fhanik/tomcat-maven-publish.zip I'd like to include this in our SVN repo, so that when we do a release, we also publish the JARs when we do a release. Any thoughts on where to stick it? you can see my first few test runs at http://people.apache.org/repo/m2-snapshot-repository/org/apache/tomcat/ We can also create a 6.0.x-SNAPSHOT version and have nightly builds, assuming that's how snapshots work. Filip - 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]
DO NOT REPLY [Bug 41324] New: - ApplicationFilterChain holds references to filters after request ends
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41324. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41324 Summary: ApplicationFilterChain holds references to filters after request ends Product: Tomcat 5 Version: 5.5.20 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] ApplicationFilterChain is holding references to filters after the request. I believe this is because in 5.5.x, ApplicationFilterChain.release() is not nulling out the entries in the filters array. In the 6.0.x trunk, there is a for loop to clear these references. I'll attach a snippet from a JBoss Profiler report from a classloader leakage test I wrote for JBoss. This was from a JBoss build with TC 5.5.20 integrated. It shows the classloader for an undeployed app being held by a chain leading to the Tomcat request processor pool. In an experiment I naively altered the Request.recycle() method to null out the ref to the filter chain and that allowed the classloader to be gc'ed. I see now that adding the for loop to ApplicationFilterFactory.release() is probably the correct solution. This could be a fairly serious classloader leak if the leaked filter references are in a high position in the array; i.e. positions that never get replaced by a subsequent request. In that case the classloader leak would be long lasting. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
