Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Remy Maucherat wrote: On Thu, 2009-04-16 at 23:09 +0100, Mark Thomas wrote: Having now read Roy's comment on 39727 I'm leaning towards reverting this patch and seeing what is possible following the Transfer-Encoding route. I'll sleep on it in case a better idea occurs to me and come back to this tomorrow. If you look at the Coyote code, you can probably guess I originally thought about compression using transfer-encoding (prepareRequest is rather obvious about that), and it did not work. Content-encoding did, though. Can you remember what didn't work with Transfer-Encoding? I don't understand why giving an option to not send an ETag would not also be a solution. At least, if it does not, I do not understand how proxies are not broken. To quote Roy from bug 39727: removing etags for the entire configured scope allows clients to use the last-modified timestamp for range requests, which would be just as bad as not changing ETag I also think proxies should be smarter, and assume serving of both a compressed and an uncompressed version, obviously using the same ETag (and send the right version depending on whether or not the client has compression). Otherwise, there's no way things can be efficient. It appears that some caches do already do this although behaviour is far from consistent among caches. Unfortunately this is outside the spec so there is no guarantee of what the behaviour may be. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r765900 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Fri Apr 17 08:40:48 2009 New Revision: 765900 URL: http://svn.apache.org/viewvc?rev=765900view=rev Log: Withdraw the proposal whilst we discuss alternative solutions 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=765900r1=765899r2=765900view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 17 08:40:48 2009 @@ -269,16 +269,3 @@ http://svn.apache.org/viewvc?rev=765662view=rev +1: markt, remm -1: - -* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 - ETag must vary between compressed and uncompressed versions. - Based on a patch by Oliver Schoett - http://svn.apache.org/viewvc?rev=765727view=rev - +1: markt - -1: remm: A hack (from what I read in 39727, the proxy folks say they are right that two representations of - one resource should have different ETag; I disagree with that since it makes ) - - how would the DefaultServlet match the ETag header sent in If conditions with this hack ? - - Tomcat does not do random compression, so unless the Connector configuration changes, there should be no issue, - so the issue is very rare, but will remove caching, so it has real consequences (bad) - I would be +0 for Connector configuration to strip the ETag (since it would be useless, that's the easiest solution), - -1 for all other options since it has an impact and fixes an edge case - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r765902 - in /tomcat/trunk/java/org/apache/coyote/http11: Constants.java Http11AprProcessor.java Http11NioProcessor.java Http11Processor.java
Author: markt
Date: Fri Apr 17 08:43:34 2009
New Revision: 765902
URL: http://svn.apache.org/viewvc?rev=765902view=rev
Log:
Revert r765727 (fix for
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538) - it fixes the
reported issue but introduces other issues.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Constants.java
tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Constants.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Constants.java?rev=765902r1=765901r2=765902view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Constants.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Constants.java Fri Apr 17
08:43:34 2009
@@ -148,10 +148,7 @@
ByteChunk.convertToBytes(400);
public static final byte[] _404_BYTES =
ByteChunk.convertToBytes(404);
-public static final String VARY = Vary;
-public static final String VARY_UNSPECIFIED = *;
-public static final String ACCEPT_ENCODING = Accept-Encoding;
-public static final String ETAG = ETag;
+
/**
* Identity filters (input and output).
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java?rev=765902r1=765901r2=765902view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java Fri Apr
17 08:43:34 2009
@@ -1486,9 +1486,16 @@
/**
- * Check if browser allows compression
+ * Check for compression
*/
-private boolean isCompressableBrowser() {
+private boolean isCompressable() {
+
+// Nope Compression could works in HTTP 1.0 also
+// cf: mod_deflate
+
+// Compression only since HTTP 1.1
+// if (! http11)
+//return false;
// Check if browser support gzip encoding
MessageBytes acceptEncodingMB =
@@ -1498,7 +1505,15 @@
|| (acceptEncodingMB.indexOf(gzip) == -1))
return false;
-// If force mode, always compress (test purposes only)
+// Check if content is not allready gzipped
+MessageBytes contentEncodingMB =
+response.getMimeHeaders().getValue(Content-Encoding);
+
+if ((contentEncodingMB != null)
+ (contentEncodingMB.indexOf(gzip) != -1))
+return false;
+
+// If force mode, allways compress (test purposes only)
if (compressionLevel == 2)
return true;
@@ -1515,23 +1530,8 @@
return false;
}
}
-return true;
-}
-
-/*
- * Check if response allows compression
- */
-private boolean isCompressableResponse() {
-
-// Check if content is not already gzipped
-MessageBytes contentEncodingMB =
-response.getMimeHeaders().getValue(Content-Encoding);
-if ((contentEncodingMB != null)
- (contentEncodingMB.indexOf(gzip) != -1))
-return false;
-
-// Check if sufficient length to trigger the compression
+// Check if suffisant len to trig the compression
long contentLength = response.getContentLengthLong();
if ((contentLength == -1)
|| (contentLength compressionMinSize)) {
@@ -1598,35 +1598,18 @@
((Long)
request.getAttribute(org.apache.tomcat.sendfile.end)).longValue();
}
}
-
-MimeHeaders headers = response.getMimeHeaders();
-
+
// Check for compression
boolean useCompression = false;
if (entityBody (compressionLevel 0) (sendfileData == null)) {
-if (isCompressableResponse()) {
-// Always send the Vary header when response could be
compressed
-MessageBytes varyHeader = headers.getValue(Constants.VARY);
-if (varyHeader == null) {
-headers.addValue(Constants.VARY).setString(
-Constants.ACCEPT_ENCODING);
-} else {
-if (varyHeader.indexOf(Constants.ACCEPT_ENCODING) == -1
-!varyHeader.equals(Constants.VARY_UNSPECIFIED)) {
-varyHeader.setString(varyHeader.toString() + , +
-Constants.ACCEPT_ENCODING);
-}
-}
-}
-
-useCompression = isCompressableBrowser();
-
+
DO NOT REPLY [Bug 46538] ETag must differ between compressed and uncompressed resource versions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 --- Comment #8 from Mark Thomas ma...@apache.org 2009-04-17 01:44:38 PST --- I've reverted the fix from trunk and withdrawn the backport proposal as whilst it fixed this issue, it introduced others. -- 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: r765909 - in /tomcat/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java Http11NioProcessor.java InternalAprOutputBuffer.java InternalNioOutputBuffer.java
Author: markt
Date: Fri Apr 17 08:50:50 2009
New Revision: 765909
URL: http://svn.apache.org/viewvc?rev=765909view=rev
Log:
Remove code that was marked for removal in r300602
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java?rev=765909r1=765908r2=765909view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java Fri Apr
17 08:50:50 2009
@@ -658,7 +658,6 @@
*/
public void setSocketBuffer(int socketBuffer) {
this.socketBuffer = socketBuffer;
-outputBuffer.setSocketBuffer(socketBuffer);
}
/**
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=765909r1=765908r2=765909view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Apr
17 08:50:50 2009
@@ -664,7 +664,6 @@
*/
public void setSocketBuffer(int socketBuffer) {
this.socketBuffer = socketBuffer;
-outputBuffer.setSocketBuffer(socketBuffer);
}
/**
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java?rev=765909r1=765908r2=765909view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java Fri
Apr 17 08:50:50 2009
@@ -192,14 +192,6 @@
/**
- * Set the socket buffer size.
- */
-public void setSocketBuffer(int socketBufferSize) {
-// FIXME: Remove
-}
-
-
-/**
* Add an output filter to the filter library.
*/
public void addFilter(OutputFilter filter) {
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=765909r1=765908r2=765909view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java Fri
Apr 17 08:50:50 2009
@@ -206,13 +206,6 @@
public NioSelectorPool getSelectorPool() {
return pool;
}
-/**
- * Set the socket buffer size.
- */
-public void setSocketBuffer(int socketBufferSize) {
-// FIXME: Remove
-}
-
/**
* Add an output filter to the filter library.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46907] Jasper with log4j in web-app classpath and debug level enabled prevents reading HTTP POST stream from JSP
https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 --- Comment #10 from IzhikovNikolay northdra...@gmail.com 2009-04-17 03:00:59 PST --- I still can't reproduce the bug. I'm on WindowsXP jdk - 1.6.0_07 -- 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: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Remy Maucherat wrote: On Fri, 2009-04-17 at 09:38 +0100, Mark Thomas wrote: Can you remember what didn't work with Transfer-Encoding? I don't remember, it was years ago. I simply used the encoding name specified in T-E to add the compression input filter (for input) rather than using the compression custom hack. I could not get browsers to do anything at the time, so I switched to content-encoding (which is the same thing from a user perspective, but it worked). The problem number 2 with T-E is that it is point to point. So the proxy has to decompress the entity, T-E cannot be cached as is, it's like chunking. So it is less efficient. However, T-E is really the right thing to do at the connector level, using content-encoding should be up to the application (and random compression filters). Too bad it did not work ... Worth checking the current state to see if it has changed then. I don't understand why giving an option to not send an ETag would not also be a solution. At least, if it does not, I do not understand how proxies are not broken. To quote Roy from bug 39727: removing etags for the entire configured scope allows clients to use the last-modified timestamp for range requests, which would be just as bad as not changing ETag Still, we would comply with the spec, and it becomes the proxy responsibility. My point is to demonstrate the specification is broken. It is then up to the proxies impls to do the right thing, or do a lawyer approach to the problem. If they do, I suggest we can do the same thing, and adding an option to drop ETags is perfectly acceptable. I also think proxies should be smarter, and assume serving of both a compressed and an uncompressed version, obviously using the same ETag (and send the right version depending on whether or not the client has compression). Otherwise, there's no way things can be efficient. It appears that some caches do already do this although behaviour is far from consistent among caches. Unfortunately this is outside the spec so there is no guarantee of what the behaviour may be. Maybe so, but it is an efficient solution. I'm currently thinking along the following lines: See if T-E support is any better now that it was a few years ago when you looked at it. (An initial Google has been inconclusive - I need to do some actual testing). For TC7, *if* T-E support is better do something along the lines of: - Use T-E for compression by default - Depending on browser support for T-E provide options to - use T-E even if clients don't send the right request headers - fall back to using C-E - Provide options for: - using C-E by default - including/not including a vary header - modifying/removing the ETag If T-E support in browsers is poor, just provide the additional configuration options for C-E. For TC6 don't make the T-E changes but maybe backport some/all of the C-E configuration options so folks can tweak things to work a little better for the edge cases with their favourite proxy cache. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46538] ETag must differ between compressed and uncompressed resource versions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 --- Comment #9 from Oliver Schoett oliver.scho...@capgemini-sdm.com 2009-04-17 07:59:02 PST --- Yes, sorry, the patch is indeed not sufficient. It fixes the sending side of the problem in that it sends out ETags that conform to the spec. However, I now understand that we also need to fix the receiving side of the problem, that is, deal with the ETags wet get back in If-Match, If-None-Match and If-Range header fields and make appropriate responses. This is much harder to fix, as currently the decision can I compress or not is made at a completely different point from the base ETag calculation, and yet we must know the set of ETags of the variants we are capable of producing to handle the If-... Requests involving ETags. Since my client needed a fix urgently (IE users behind proxy caches did receive unusable JavaScript files), I have removed ETag generation and handling completely from his production Tomcats (can supply patch if there is interest). This way, the logic for 304 Not Modified responses relies entirely on If-Modified-Since, which works well enough if you keep the date stamps between identical copies of a resource on different servers of a farm in sync. -- BTW, the part of RFC2616 that makes it most clear that ETags are per variant is in Section 13.6; for example: If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. This algorithm makes no sense unless ETags are per variant. Unfortunately, the section that defines ETags (14.19) says nothing about this. -- 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 47046] New: Shutdown does not unregister all MBeans
https://issues.apache.org/bugzilla/show_bug.cgi?id=47046 Summary: Shutdown does not unregister all MBeans Product: Tomcat 6 Version: 6.0.18 Platform: PC OS/Version: Mac OS X 10.4 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: rob.har...@springsource.com Created an attachment (id=23505) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23505) Simple driver to highlight problem If I start and stop Tomcat in a VM using the Catalina class then it does not unregister all its MBeans. The list left over is: Catalina:type=RequestProcessor,worker=http-8080,name=HttpRequest1 true Catalina:type=MBeanFactory true Catalina:type=Engine true Catalina:type=JkWorkerEnv true Catalina:type=StringCache true Catalina:type=Host,host=localhost true Catalina:type=JkMain true Catalina:type=JkHandler,name=channelSocket true Catalina:type=Server true Catalina:type=JkHandler,name=request true Catalina:type=Connector,port=8080 true Catalina:type=Connector,port=8009 true I've attached a simple class that can be used to reproduce this list. -- 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 46538] ETag must differ between compressed and uncompressed resource versions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 --- Comment #10 from Remy Maucherat r...@apache.org 2009-04-17 08:17:37 PST --- Yes, that's my point, the only solution I see in Tomcat 6 about this is an option to remove the etag if compression is active for the request. And about your spec quoting, it is great to adhere to specs and stuff, but it might be that clients apparently only really support content-encoding, which is not supposed to be used for on-the-fly compression (but is, since I am very not sure about support for transfer-encoding which is the proper way to do that; originally, I had planned all sorts of filters which would be added according to the T-E header, but in the end, the only thing which was workable then was a hardcoded gzip output filter which used the content-encoding header). You have to do things which work ... -- 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 46907] Jasper with log4j in web-app classpath and debug level enabled prevents reading HTTP POST stream from JSP
https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 --- Comment #11 from Kirk True k...@mustardgrain.com 2009-04-17 09:03:24 PST --- I should mention I'm on Linux (Fedora 10 x64). Here's my java -version: java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) -- 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: r766075 - in /tomcat/trunk/java: javax/servlet/ javax/servlet/http/ org/apache/catalina/connector/ org/apache/catalina/core/ org/apache/jasper/servlet/
Author: markt
Date: Fri Apr 17 16:30:56 2009
New Revision: 766075
URL: http://svn.apache.org/viewvc?rev=766075view=rev
Log:
Update Servlet 3.0 classes to spec snapshot as of early March 2009. Still not
final.
Added:
tomcat/trunk/java/javax/servlet/AsyncDispatcher.java (with props)
Removed:
tomcat/trunk/java/javax/servlet/AsyncContext.java
tomcat/trunk/java/javax/servlet/http/HttpUtils.java
Modified:
tomcat/trunk/java/javax/servlet/AsyncEvent.java
tomcat/trunk/java/javax/servlet/AsyncListener.java
tomcat/trunk/java/javax/servlet/ServletContext.java
tomcat/trunk/java/javax/servlet/ServletRequest.java
tomcat/trunk/java/javax/servlet/ServletRequestWrapper.java
tomcat/trunk/java/javax/servlet/SessionTrackingMode.java
tomcat/trunk/java/javax/servlet/http/HttpServlet.java
tomcat/trunk/java/org/apache/catalina/connector/Request.java
tomcat/trunk/java/org/apache/catalina/connector/RequestFacade.java
tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
tomcat/trunk/java/org/apache/catalina/core/DummyRequest.java
tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
tomcat/trunk/java/org/apache/jasper/servlet/JspCServletContext.java
Added: tomcat/trunk/java/javax/servlet/AsyncDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/AsyncDispatcher.java?rev=766075view=auto
==
--- tomcat/trunk/java/javax/servlet/AsyncDispatcher.java (added)
+++ tomcat/trunk/java/javax/servlet/AsyncDispatcher.java Fri Apr 17 16:30:56
2009
@@ -0,0 +1,26 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one or more
+* contributor license agreements. See the NOTICE file distributed with
+* this work for additional information regarding copyright ownership.
+* The ASF licenses this file to You under the Apache License, Version 2.0
+* (the License); you may not use this file except in compliance with
+* the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an AS IS BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package javax.servlet;
+
+/**
+ * @since 3.0
+ * TODO SERVLET3 - Add comments
+ */
+public interface AsyncDispatcher {
+void forward(ServletRequest request, ServletResponse response)
+throws IllegalStateException;
+}
Propchange: tomcat/trunk/java/javax/servlet/AsyncDispatcher.java
--
svn:eol-style = native
Propchange: tomcat/trunk/java/javax/servlet/AsyncDispatcher.java
--
svn:keywords = Date Author Id Revision
Modified: tomcat/trunk/java/javax/servlet/AsyncEvent.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/AsyncEvent.java?rev=766075r1=766074r2=766075view=diff
==
--- tomcat/trunk/java/javax/servlet/AsyncEvent.java (original)
+++ tomcat/trunk/java/javax/servlet/AsyncEvent.java Fri Apr 17 16:30:56 2009
@@ -19,7 +19,7 @@
/**
* @since 3.0
* $Id$
- * TODO SERVLET3
+ * TODO SERVLET3 - Add comments
*/
public class AsyncEvent {
private ServletRequest request;
Modified: tomcat/trunk/java/javax/servlet/AsyncListener.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/AsyncListener.java?rev=766075r1=766074r2=766075view=diff
==
--- tomcat/trunk/java/javax/servlet/AsyncListener.java (original)
+++ tomcat/trunk/java/javax/servlet/AsyncListener.java Fri Apr 17 16:30:56 2009
@@ -17,13 +17,14 @@
package javax.servlet;
import java.io.IOException;
+import java.util.EventListener;
/**
* @since 3.0
* $Id$
- * TODO SERVLET3
+ * TODO SERVLET3 - Add comments
*/
-public interface AsyncListener {
-void onComplete(AsyncEvent event) throws IOException;
+public interface AsyncListener extends EventListener {
+void onDoneAsync(AsyncEvent event) throws IOException;
void onTimeout(AsyncEvent event) throws IOException;
}
Modified: tomcat/trunk/java/javax/servlet/ServletContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/ServletContext.java?rev=766075r1=766074r2=766075view=diff
==
--- tomcat/trunk/java/javax/servlet/ServletContext.java (original)
+++ tomcat/trunk/java/javax/servlet/ServletContext.java Fri Apr 17 16:30:56 2009
@@ -643,14 +643,38 @@
Problems building 5.5.27 from source
Hi all,
I had some problems building 5.5.27 as pulled from
http://tomcat.apache.org/download-55.cgi.
The first issue was that I couldn't use a JDK 1.4.2-level compiler as it
chokes on the class format of the JUnit libraries. Using JDK 1.6 didn't
work because of the fact that the java.sql.Wrapper class methods aren't
implemented in the connection pool module classes. So I had to install a
1.5-era JDK. No biggie.
Secondly, there are some version problems in the
build.properties.default for which I've submitted a patch (below). I
don't know what the right fix is for the native Tomcat dependencies,
but this at least allowed the build to complete. I couldn't find 1.1.12
anywhere, so while the build doesn't complain, I don't _assume_ this is
the correct fix.
Thanks,
Kirk
--- a/build/build.properties.default2008-08-28 22:10:32.0 -0700
+++ b/build/build.properties.default2009-04-17 11:58:06.0 -0700
@@ -12,10 +12,10 @@
# - Vesion Control Flags -
version.major=5
version.minor=5
-version.build=26
+version.build=27
version.patch=0
#Set the pretty version name
-version=5.5.26
+version=5.5.27
# - Compile Control Flags -
compile.debug=on
@@ -140,9 +140,9 @@
jdt.loc=http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
# - Tomcat native library -
-tomcat-native.home=${base.path}/tomcat-native-1.1.12
+tomcat-native.home=${base.path}/tomcat-native-1.1.16
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
-tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz
+tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/source/1.1.16/tomcat-native-1.1.16-src.tar.gz
# --
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problems building 5.5.27 from source
On 17/04/2009, Kirk True k...@mustardgrain.com wrote:
Hi all,
I had some problems building 5.5.27 as pulled from
http://tomcat.apache.org/download-55.cgi.
The first issue was that I couldn't use a JDK 1.4.2-level compiler as it
chokes on the class format of the JUnit libraries.
AFAIK it requires Java 1.5, see:
http://www.mirrorservice.org/sites/ftp.apache.org/tomcat/tomcat-5/v5.5.27/README.html
Or is there some other documentation that says otherwise?
Using JDK 1.6 didn't work
because of the fact that the java.sql.Wrapper class methods aren't
implemented in the connection pool module classes. So I had to install a
1.5-era JDK. No biggie.
Secondly, there are some version problems in the build.properties.default
for which I've submitted a patch (below). I don't know what the right fix
is for the native Tomcat dependencies, but this at least allowed the build
to complete. I couldn't find 1.1.12 anywhere, so while the build doesn't
complain, I don't _assume_ this is the correct fix.
I don't know about the properties file, perhaps someone more familiar
with Tomcat releases will chip in.
Thanks,
Kirk
--- a/build/build.properties.default2008-08-28
22:10:32.0 -0700
+++ b/build/build.properties.default2009-04-17
11:58:06.0 -0700
@@ -12,10 +12,10 @@
# - Vesion Control Flags -
version.major=5
version.minor=5
-version.build=26
+version.build=27
version.patch=0
#Set the pretty version name
-version=5.5.26
+version=5.5.27
# - Compile Control Flags -
compile.debug=on
@@ -140,9 +140,9 @@
jdt.loc=http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
# - Tomcat native library -
-tomcat-native.home=${base.path}/tomcat-native-1.1.12
+tomcat-native.home=${base.path}/tomcat-native-1.1.16
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
-tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz
+tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/source/1.1.16/tomcat-native-1.1.16-src.tar.gz
# --
-
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
Re: Problems building 5.5.27 from source
Hi sebb,
sebb wrote:
On 17/04/2009, Kirk True k...@mustardgrain.com wrote:
Hi all,
I had some problems building 5.5.27 as pulled from
http://tomcat.apache.org/download-55.cgi.
The first issue was that I couldn't use a JDK 1.4.2-level compiler as it
chokes on the class format of the JUnit libraries.
AFAIK it requires Java 1.5, see:
http://www.mirrorservice.org/sites/ftp.apache.org/tomcat/tomcat-5/v5.5.27/README.html
Or is there some other documentation that says otherwise?
In the zip, apache-tomcat-5.5.27-src.zip is a file named
build/BUILDING.txt which provides steps to build, among which is:
(0) Download and Install a Java Development Kit
* If the JDK is already installed, skip to (1).
* Download a Java Development Kit (JDK) release (version 1.4.x or
later) from:
http://java.sun.com/j2se/
* Install the JDK according to the instructions included with the
release.
* Set an environment variable JAVA_HOME to the pathname of the directory
into which you installed the JDK release.
That's what I went off of.
Kirk
Using JDK 1.6 didn't work
because of the fact that the java.sql.Wrapper class methods aren't
implemented in the connection pool module classes. So I had to install a
1.5-era JDK. No biggie.
Secondly, there are some version problems in the build.properties.default
for which I've submitted a patch (below). I don't know what the right fix
is for the native Tomcat dependencies, but this at least allowed the build
to complete. I couldn't find 1.1.12 anywhere, so while the build doesn't
complain, I don't _assume_ this is the correct fix.
I don't know about the properties file, perhaps someone more familiar
with Tomcat releases will chip in.
Thanks,
Kirk
--- a/build/build.properties.default2008-08-28
22:10:32.0 -0700
+++ b/build/build.properties.default2009-04-17
11:58:06.0 -0700
@@ -12,10 +12,10 @@
# - Vesion Control Flags -
version.major=5
version.minor=5
-version.build=26
+version.build=27
version.patch=0
#Set the pretty version name
-version=5.5.26
+version=5.5.27
# - Compile Control Flags -
compile.debug=on
@@ -140,9 +140,9 @@
jdt.loc=http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.3.1-200709211145/eclipse-JDT-3.3.1.zip
# - Tomcat native library -
-tomcat-native.home=${base.path}/tomcat-native-1.1.12
+tomcat-native.home=${base.path}/tomcat-native-1.1.16
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
-tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz
+tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/source/1.1.16/tomcat-native-1.1.16-src.tar.gz
# --
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
