DO NOT REPLY [Bug 43191] compressableMimeType attribute ignored
https://issues.apache.org/bugzilla/show_bug.cgi?id=43191
Richard Mundell <[EMAIL PROTECTED]> changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment #10 from Richard Mundell <[EMAIL PROTECTED]> 2008-06-16 05:44:43
PST ---
I would like to share an alternative approach for this problem I just
implemented which avoids having to update Tomcat (or patch it).
Grab CompressionFilter.java, CompressionResponseStream.java and
CompressionServletResponseWrapper.java from the Tomcat source code distribution
(I did this with the 5.5.25 source).
Open up CompressionServletResponseWrapper.java and modify the writetoGZip()
method. On line 305, replace...
response.addHeader("Content-Encoding", "gzip");
gzipstream = new GZIPOutputStream(output);
...with...
if ((response.getContentType()!=null) &&
(response.getContentType().equals("application/pdf")) {
// I want to compress this content type
response.addHeader("Content-Encoding", "gzip");
gzipstream = new GZIPOutputStream(output);
} else {
// Don't want to compress this content type
gzipstream = output;
}
Compile all three Java classes, then add the filter into your web.xml file:
Compressing Filter
compressionFilters.CompressionFilter
compressionThreshold
1
Compressing Filter
/*
This is very handy if you don't want to upgrade Tomcat, or for Tomcat 5.5.x
users for who there isn't an upgrade with the patch available yet. Also useful
if you don't want to compress server-wide for all of your web applications.
Enjoy!
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45212] New: AbstractReplicatedMap. entrySet returns values not entries.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45212
Summary: AbstractReplicatedMap.entrySet returns values not
entries.
Product: Tomcat 6
Version: 6.0.16
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Cluster
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
AbstractReplicatedMap implements entrySet() as follows;
public Set entrySet() {
LinkedHashSet set = new LinkedHashSet(super.size());
Iterator i = super.entrySet().iterator();
while ( i.hasNext() ) {
Map.Entry e = (Map.Entry)i.next();
Object key = e.getKey();
MapEntry entry = (MapEntry)super.get(key);
if ( entry != null && entry.isPrimary() )
set.add(entry.getValue());
}
return Collections.unmodifiableSet(set);
}
this returns a set of all the *values*, the line set.add(entry.getValue())
should be set.add(entry);
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45213] New: Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45213
Summary: Recompiled JSPs not reloaded as necessary
Product: Tomcat 5
Version: 5.5.26
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
In a Tomcat server farm utilizing a shared work directory (that is, all Tomcat
instances have the virtual 'Host' element attribute 'workDir' pointing to the
same directory) it is possibly (even likely) that one Tomcat instance may
recompile a changed JSP that another instance has already loaded. Under these
circumstances, the second Tomcat instance will fail to reload the newly
recompiled JSP.
Method to Duplicate:
1) Bring up two instances of Tomcat (call them node1 and node2) that share a
set of JSPs and a work directory (each node's server.xml has the default
virtual host's appBase and workDir pointing to common shared directories).
2) For each hit a common JSP
3) Suspend the process running Tomcat for node1 ...
a) On windows you can use the Process Explorer
(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) to suspend the
process (right click on process and select Suspend).
b) On *nix you can use send it a SIGSTOP to suspend it.
4) Modify the JSP.
5) Hit the page on node2. You should see the modification.
6) Resume the suspended appserver process. (on unix you send SIGCONT; Process
Explorer right click on process and select Resume).
7) Hit the page on node1. Without this fix you should *not* see the
modification. With the fix you should see the changes.
Analysis:
The shared JSP is correctly flagged for recompile and rebuilt. Note that there
is a race condition (not the subject of the bug report) wherein any number
(from one to all) Tomcat instances may try to recompile the changed JSP at the
same time, depending on the timing of their JspRuntimeContext (JSP
recompilation) threads. In the the procedure above we suspend one server to
control which server performs the recompilation.
The awakened server will (within its JspRuntimeContext thread) detect that the
JSP has changed and will "request" that it be reloaded. This occurs in
JspServletWrapper.setServletClassLastModifiedTime in the call to
JspServletWrapper.setReload(boolean) ... the calling sequence will be
approximately JspRuntimeContext.checkCompile() ->
JspCompilationContext.compile() -> Compiler.isOutDated() ->
Compiler(isOutDated(boolean=true) ->
JspServletWrapper.setServletClassLastModifiedTime(long) ->
JspServletWrapper.setReload(boolean=true). JspServletWrapper.getServlet() will
try to reload the JSP by calling JspCompilationContext.load(). However, the
call to load() will return the *old* class, not the *new* one.
The underlying reason is that JspCompilationContext's class loader (property
jspLoader) was never reset as a side effect of
JspServletWrapper.setReload(boolean=true). As a result, the subsequent call to
JspCompilationContext.load() continues to use the old class loader, and hence
return the old class.
At present, the JspCompilationContext class loader is only reset as a side
effect of performing a compilation *by this instance of Tomcat*. Thus an Tomcat
instance may notice that a JSP has been recompiled (by another Tomcat instance)
but will never reload the class because *it* didn't perform the recompiation.
Fix:
The following modification to Jasper addresses this behavior:
- add a resetJspLoader() method to JspCompilationContext which throws
away the current class loader thus allowing the JSP to be reloaded.
- modify the setReload(boolean) method on JspServletWrapper
to invoke JspCompilationContext.resetJspLoader() if the reload argument
is true.
Diffs:
The following diffs are against 5.5.20. The same modifications apply to 5.5.26
and 6.0.16, only the line numbers differ.
---
/apache-tomcat-5.5.20-src/jasper/src/share/org/apache/jasper/JspCompilationContext.java
+++ /fix/org/apache/jasper/JspCompilationContext.java
@@ -182,10 +182,14 @@
rctxt.getCodeSource());
}
return jspLoader;
}
+public void resetJspLoader() {
+this.jspLoader = null;
+}
+
/** -- Input/Output -- */
/**
* The output directory to generate code into. The output directory
* is make up of the scratch directory, which is provide in Options,
@@ -557,11 +561,11 @@
public void compile() throws JasperException, FileNotFoundException {
createCompiler();
if (isPackagedTagFile || jspCompiler.isOutDated()) {
try {
-jspLoader = null;
+this.resetJspLoader();
jspCompiler.compile();
jsw.setReload(true);
jsw.setCompilationException(null);
} catch (JasperException ex) {
svn commit: r668249 - /tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
Author: markt Date: Mon Jun 16 10:22:36 2008 New Revision: 668249 URL: http://svn.apache.org/viewvc?rev=668249&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45212 Map.entrySet() should return entries, not values Modified: tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java Modified: tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=668249&r1=668248&r2=668249&view=diff == --- tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java (original) +++ tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java Mon Jun 16 10:22:36 2008 @@ -1017,7 +1017,7 @@ Map.Entry e = (Map.Entry)i.next(); Object key = e.getKey(); MapEntry entry = (MapEntry)super.get(key); -if ( entry != null && entry.isPrimary() ) set.add(entry.getValue()); +if ( entry != null && entry.isPrimary() ) set.add(entry); } return Collections.unmodifiableSet(set); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45214] New: Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45214
Summary: Recompiled JSPs not reloaded as necessary
Product: Tomcat 6
Version: 6.0.16
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In a Tomcat server farm utilizing a shared work directory (that is, all Tomcat
instances have the virtual 'Host' element attribute 'workDir' pointing to the
same directory) it is possibly (even likely) that one Tomcat instance may
recompile a changed JSP that another instance has already loaded. Under these
circumstances, the second Tomcat instance will fail to reload the newly
recompiled JSP.
Method to Duplicate:
1) Bring up two instances of Tomcat (call them node1 and node2) that share a
set of JSPs and a work directory (each node's server.xml has the default
virtual host's appBase and workDir pointing to common shared directories).
2) For each hit a common JSP
3) Suspend the process running Tomcat for node1 ...
a) On windows you can use the Process Explorer
(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) to suspend the
process (right click on process and select Suspend).
b) On *nix you can use send it a SIGSTOP to suspend it.
4) Modify the JSP.
5) Hit the page on node2. You should see the modification.
6) Resume the suspended appserver process. (on unix you send SIGCONT; Process
Explorer right click on process and select Resume).
7) Hit the page on node1. Without this fix you should *not* see the
modification. With the fix you should see the changes.
Analysis:
The shared JSP is correctly flagged for recompile and rebuilt. Note that there
is a race condition (not the subject of the bug report) wherein any number
(from one to all) Tomcat instances may try to recompile the changed JSP at the
same time, depending on the timing of their JspRuntimeContext (JSP
recompilation) threads. In the the procedure above we suspend one server to
control which server performs the recompilation.
The awakened server will (within its JspRuntimeContext thread) detect that the
JSP has changed and will "request" that it be reloaded. This occurs in
JspServletWrapper.setServletClassLastModifiedTime in the call to
JspServletWrapper.setReload(boolean) ... the calling sequence will be
approximately JspRuntimeContext.checkCompile() ->
JspCompilationContext.compile() -> Compiler.isOutDated() ->
Compiler(isOutDated(boolean=true) ->
JspServletWrapper.setServletClassLastModifiedTime(long) ->
JspServletWrapper.setReload(boolean=true). JspServletWrapper.getServlet() will
try to reload the JSP by calling JspCompilationContext.load(). However, the
call to load() will return the *old* class, not the *new* one.
The underlying reason is that JspCompilationContext's class loader (property
jspLoader) was never reset as a side effect of
JspServletWrapper.setReload(boolean=true). As a result, the subsequent call to
JspCompilationContext.load() continues to use the old class loader, and hence
return the old class.
At present, the JspCompilationContext class loader is only reset as a side
effect of performing a compilation *by this instance of Tomcat*. Thus an Tomcat
instance may notice that a JSP has been recompiled (by another Tomcat instance)
but will never reload the class because *it* didn't perform the recompiation.
Fix:
The following modification to Jasper addresses this behavior:
- add a resetJspLoader() method to JspCompilationContext which throws
away the current class loader thus allowing the JSP to be reloaded.
- modify the setReload(boolean) method on JspServletWrapper
to invoke JspCompilationContext.resetJspLoader() if the reload argument
is true.
Diffs:
The following diffs are against 6.0.16.
---
apache-tomcat-6.0.16-src/apache-tomcat-6.0.16-src/java/org/apache/jasper/JspCompilationContext.java
2008-01-28 16:41:12.0 -0600
+++
apache-tomcat-6.0.16-src/apache-tomcat-6.0.16-src/java/org/apache/jasper/JspCompilationContext.java.fixed
2008-06-16 12:18:27.227778400 -0500
@@ -183,10 +183,14 @@
rctxt.getCodeSource());
}
return jspLoader;
}
+public void resetJspLoader() {
+this.jspLoader = null;
+}
+
/** -- Input/Output -- */
/**
* The output directory to generate code into. The output directory
* is make up of the scratch directory, which is provide in Options,
@@ -560,11 +564,11 @@
public void compile() throws JasperException, FileNotFoundException {
createCompiler();
if (isPackagedTagFile || jspCompiler.isOutDated()) {
try {
jspCompiler.removeGeneratedFiles();
-jspLoader = null;
+this.resetJspLoader();
jspCompiler.compile();
jsw.setReload(true);
jsw.setCompilationExcep
svn commit: r668251 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Jun 16 10:27:25 2008 New Revision: 668251 URL: http://svn.apache.org/viewvc?rev=668251&view=rev Log: Propose fix for 45212 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=668251&r1=668250&r2=668251&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jun 16 10:27:25 2008 @@ -79,3 +79,9 @@ http://svn.apache.org/viewvc?rev=667644&view=rev +1: markt -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45212 + Map.entrySet() should return entries, not values + http://svn.apache.org/viewvc?rev=668249&view=rev + +1: markt + -1: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45212] AbstractReplicatedMap. entrySet returns values not entries.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45212 --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 10:27:54 PST --- Thanks for the report. This is fixed in trunk and proposed for 6.0.x -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45213] Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45213 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|major |enhancement Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 10:44:31 PST --- Sharing workDir between multiple instances is not a supported configuration. Whilst the docs don't explicitly say this, the description for workDir implies this and it was never, as far as I am aware, the intention of the Tomcat developers to allow multiple hosts to share the work directory. I am pleased you have a local fix that works for you but I am concerned that further down the line that you will discover a whole host of other things that break when using a shared work directory (such as the race condition you have identified). These issues would all need to be addressed (in a much larger patch) before any patch was committed. I do not believe the benefit obtained by getting this functionality working correctly justifies the additional complexity that would be required. Since this change would represent new functionality, I am changing it to an enhancement. I am also marking it as WONTFIX as I do not believe this would ever be implemented. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45215] New: Request reader returns length zero
https://issues.apache.org/bugzilla/show_bug.cgi?id=45215
Summary: Request reader returns length zero
Product: Tomcat 5
Version: 5.5.26
Platform: All
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P2
Component: Connector:Coyote
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Experienced as ArrayIndexOutOfBounds exceptions in Xerces
Due to the Reader returning a length of zero which should never occur unless
the input length parameetr is zero (which it isn').
A CalDAV REPORT request of 31k+ bytes produces the error.
Debugged it down through the CharChunk.subtract method called with off=1 and
len=2047.
The fields start and end both equal 8192.
In this code
if ((end - start) == 0) {
if (in == null)
return -1;
int n = in.realReadChars( buff, end, buff.length - end);
if (n < 0)
return -1;
}
int n = len;
if (len > getLength()) {
n = getLength();
}
buf.length - end = 0, so we call realReadChars with len = 0
And then n = getLength() sets n to zero.
Difficult to attach any test case as it involves debugging a whole system
Possibly a large POST would reveal the problem.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45215] Request reader returns length zero
https://issues.apache.org/bugzilla/show_bug.cgi?id=45215 --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 11:13:53 PST --- Sounds like a duplicate of one of the many issues exposed by bug 44494. These have been fixed in trunk for 6.x. Can you build trunk from svn and test against it? -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45216] New: tc 6 classloading doc references tc 5 startup scripts
https://issues.apache.org/bugzilla/show_bug.cgi?id=45216 Summary: tc 6 classloading doc references tc 5 startup scripts Product: Tomcat 6 Version: 6.0.16 Platform: PC URL: http://tomcat.apache.org/tomcat-6.0-doc/class-loader- howto.html OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] >>System - This class loader is normally initialized from the contents of the >>CLASSPATH environment variable. All such classes are visible to both Tomcat >>internal classes, and to web applications. However, the standard Tomcat 5 >>startup scripts -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45213] Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45213 --- Comment #2 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 11:48:19 PST --- *** Bug 45214 has been marked as a duplicate of this bug. *** -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45214] Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45214 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 11:48:19 PST --- *** This bug has been marked as a duplicate of bug 45213 *** -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45216] tc 6 classloading doc references tc 5 startup scripts
https://issues.apache.org/bugzilla/show_bug.cgi?id=45216 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 11:50:34 PST --- This has already been fixed and will be included in the next release. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45213] Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45213 --- Comment #3 from Jim Hanlon <[EMAIL PROTECTED]> 2008-06-16 11:52:15 PST --- The shared work directory is convenient, but not central, to duplicating this bug. The same effect can be had by running the JspC ant task concurrent with a running server -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 45213] Recompiled JSPs not reloaded as necessary
https://issues.apache.org/bugzilla/show_bug.cgi?id=45213 --- Comment #4 from Mark Thomas <[EMAIL PROTECTED]> 2008-06-16 12:00:26 PST --- That isn't supported either - for pretty much the same reasons. If you have two independent processes trying to do the same thing without co-ordination you are going to get race conditions. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
