[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 fuminz...@crd.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from fuminz...@crd.com --- Thanks for the recommendation. New Bug 64081 reported. Closing this one. -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 --- Comment #9 from Mark Thomas --- This situation you describe seems to be wholly unrelated to this bug. I recommend opening a new bug. -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 fuminz...@crd.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #8 from fuminz...@crd.com --- A simple jsp below could demonstrate the issue behavior - when it is used with javax.servlet.jsp.jstl-1.2.3.jar (and javax.servlet.jsp.jstl-api-1.2.1.jar) instead of taglibs-standard-impl-1.2.5.jar and taglibs-standard-spec-1.2.5.jar. I have also created a simple webapp with such. - Some environment factors might play - I am using a Windows 10 pro, with en-US/Eastern Time zone, which might cause the non-constant CharacterEncoding to be set on the Response. But now I am wondering maybe I should create a separate bug instead of reopen this one - so that we could move forward instead of considering rolling it back - what do you think?
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 --- Comment #7 from fuminz...@crd.com --- Note that in debug that encountered the problem (in my particular case anyway), in the DefaultServlet.java, even when: outputEncoding != org.apache.coyote.Constants.DEFAULT_BODY_CHARSET.name() becomes true, the contents of both sides are actually the same. -This and the flush looks to be the logic for the 49464 fix. Which makes this fix suspicious. - Locally changing the "!=" to ".equals(..)" would make the issue go away. -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 --- Comment #6 from fuminz...@crd.com --- It turns out the issue behavior is not related to struts/tiles/action. I am able to develop a simple jsp that encounter the issue - still want to trim down further before I submit the pacakge. But it does require to use tag lib http://java.sun.com/jsp/jstl/fmt, with javax.servlet.jsp.jstl-1.2.3.jar. In debug, it looks the fmt:setLocale would cause an CharacterEncoding (for en-US) to be set on the Response, which in turn, at the code for bug 49464, would cause: outputEncoding != org.apache.coyote.Constants.DEFAULT_BODY_CHARSET.name() to be true, which triggers the outputEncodingSpecified pw.flush to happen. and with the ImportSupport from javax.servlet.jsp.jstl-1.2.3.jar looks not able to deal with the flushed irw, while the taglibs-standard-impl-1.2.5 appears to be able to handle it - these I have not debugged into. -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 --- Comment #5 from fuminz...@crd.com --- Also it appears to require struts(1) action/tiles to get it happen - a simple jsp with c:import does not show the issue behavior. -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 --- Comment #4 from fuminz...@crd.com --- I am able to have an isolated case to reproduce the "bug" behavior now. Still need to clean up a bit more before I submit. But a quick update: previously in the scenario I couldn't reproduce the "bug", appears to be because locally a newer version of taglib was in effect. Removing the taglibs-standard-impl-1.2.5.jar and taglibs-standard-spec-1.2.5.jar, and let the javax.servlet.jsp.jstl-1.2.3.jar and javax.servlet.jsp.jstl-api-1.2.1.jar to take effect, would cause the behavior to appear. - Well, I guess it could be said as a javax.servlet.jsp.jstl-1.2.3.jar bug... -A quick update anyway. -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #3 from Mark Thomas --- This sounds more like a concurrency issue with the tag library. Waiting for more information on how to reproduce this... -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 fuminz...@crd.com changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #2 from fuminz...@crd.com --- The fix to bug 49464 potentially missed a scenario in its consideration, and may have introduced a "new" bug. However, we have not been able to create an isolated test scenario to demonstrate such yet. In comments to bug 49464, it listed 3 scenarios considered: " There are three scenarios to consider: a) directly returning a file b) including a file into an output stream c) including a file into a writer". However, a fourth scenario for standard tag library core appears to be impacted. To my understanding, if a jsp contains a: it is supposed to populate the content from that file "sample.xsl" into the "variable" "xslt", for later code to use. The issue behavior that we (in certain conditions) observed, is that the "variable" "xslt" would become empty, yet the jsp or the result html would receive the content of "sample.xsl" as part of its own content, making it behaving as if it is a "include" tag instead of an import tag. We have not identified the exact conditions that would trigger such behavior yet - thus no isolated test case created to demonstrate such yet. But since the issue behavior looks to match the comments of the bug/fix for 49464, I am adding this comment to start the communication. - We will update when/if we have more specific info. We are using tomcat 9.0.26 -- 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
[Bug 62971] Revert the fix for 49464 in tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=62971 Remy Maucherat changed: What|Removed |Added OS||All Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Remy Maucherat --- *** This bug has been marked as a duplicate of bug 49464 *** -- 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
