Which version of WL are you using? I'm on 8.1 SP3 and am getting a "Original response not available" ServletException because the ResponseOverrideFilter is using a custom ServletResponse.
I've created a test case for this and opened a case with WL - afaics this is perfectly legal so should be a WL bug.
cheers
dim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just got a response back from BEA saying that they see this as a gray area of the spec and they wont change their implementation. Despite chapter 6 of servlet 2.3 (on filters) saying nothing forbidding what displaytag is doing, section 8.2 states that in the case of request dispatchers that if the request or response passed through isn't that passed into the service method, then they must subclass the provided wrapper classes. I argued that this isn't what is happening, but to no avail.
I'll start on it now then - is there a test case (automated or manual) that I should run on other containers. I assume I'll be able to figure it out but will ask questions here if I need.
L Wilson - I'll post back here once I've submitted it, and then I assume Matt will incorporate it into cvs and hopefully we'll see it in 1.0 rc2 or final (o:
cheers
dim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anyone seen any issues with this patch? I am using Displaytag 1.0 and when I use the export filter with buffering turned on I only get part of the data downloaded to my file. I tried turning off buffering and all the data shows up on the screen but does not go into the file. I created a sample and ran it on Tomcat and everything worked fine.
Any ideas.
Scott Ryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We ended up giving up, and having to rewrite our displaytag pages, for Weblogic (v7, patchlevel 4), to do our own manual "exporting".
So we have a nice Websphere/Tomcat/JBoss version of a web application, using ordinary displaytag exports.
And then we have a hacked Weblogic version, where for the pages that do exports, in place of the export links at the bottom of the displaytag table, we link to a manual export as CSV.
The Weblogic version of this web application also has other restrictions and workarounds for more Weblogic bugs.
And it has to compile and be deployed under JDK 1.3.X (needing different JARs in WEB-INF/lib, some different code, etc.), unlike the main version, for Websphere/Tomcat/JBoss, where they all run JDK 1.4.X.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
response already committed at weblogic.servlet.jsp.JspWriterImpl.clear()
Anyone got the same problem? Any resolution for this?
Thanks,
Dheeraj.
Dheeraj,
Which version of WL are you using? I'm on 8.1 SP3 and am getting a "Original response not available" ServletException because the ResponseOverrideFilter is using a custom ServletResponse.
I've created a test case for this and opened a case with WL - afaics this is perfectly legal so should be a WL bug.
cheers
dim
I just got a response back from BEA saying that they see this as a gray area of the spec and they wont change their implementation. Despite chapter 6 of servlet 2.3 (on filters) saying nothing forbidding what displaytag is doing, section 8.2 states that in the case of request dispatchers that if the request or response passed through isn't that passed into the service method, then they must subclass the provided wrapper classes. I argued that this isn't what is happening, but to no avail.
So - question: Is there a reason the included request wrapper isn't used? From http://cvs.sourceforge.net/viewcvs.py/displaytag/displaytag2/src/java/org/displaytag/filter/BufferedResponseWrapper.java?rev=1.8&view=log it seems that you're not too confident of this.
I'm happy to do the legwork and provide a patch, but want to check you'll accept it (and preferably get it in before 1.0) before I put time into it.
cheers
dim
If your patch doesn't affect the displaytag on other containers (i.e. it still works), I don't see why we wouldn't accept it. ;0)
matt
I'm having the same problem using weblogic. Dmitri and Matt, how will we know when the patch is ready?
Matt,
I'll start on it now then - is there a test case (automated or manual) that I should run on other containers. I assume I'll be able to figure it out but will ask questions here if I need.
L Wilson - I'll post back here once I've submitted it, and then I assume Matt will incorporate it into cvs and hopefully we'll see it in 1.0 rc2 or final (o:
cheers
dim
I've submitted a patch to the dev list as patches on sf aren't enabled.
I've run the test case, which reports no failures, so I'm assuming this is all ok.
cheers
dim
dimc, i'm a newbie to sourceforge. is the fix available for download somewhere ? pls direct me to the link. thank you
dhang00
Has anyone seen any issues with this patch? I am using Displaytag 1.0 and when I use the export filter with buffering turned on I only get part of the data downloaded to my file. I tried turning off buffering and all the data shows up on the screen but does not go into the file. I created a sample and ran it on Tomcat and everything worked fine.
Any ideas.
Scott Ryan
We ended up giving up, and having to rewrite our displaytag pages, for Weblogic (v7, patchlevel 4), to do our own manual "exporting".
So we have a nice Websphere/Tomcat/JBoss version of a web application, using ordinary displaytag exports.
And then we have a hacked Weblogic version, where for the pages that do exports, in place of the export links at the bottom of the displaytag table, we link to a manual export as CSV.
The Weblogic version of this web application also has other restrictions and workarounds for more Weblogic bugs.
And it has to compile and be deployed under JDK 1.3.X (needing different JARs in WEB-INF/lib, some different code, etc.), unlike the main version, for Websphere/Tomcat/JBoss, where they all run JDK 1.4.X.