Hmm. I added a requestURI to the JSP in the test war, and it worked fine. I'm also using this with a requestURI with struts on our system, no problem.
Can you modify the test war to the point where it will reproduce the failure? Otherwise, I'm inclined to think it might be something non-displaytag related in your config. --andy > OK Andy, here's what I've found. First off, I deployed your test war file > and it worked as expected. I compared your configuration to mine > in terms of > the filter config and tld and things seem to be the same. After more > experimentation I think I see the problem, but I don't really understand > why. > > I am mapping both *.do and *.jsp to the ResponseOverrideFilter. In my > display:table tag I am using the requestURI attribute to make all of the > links point back to my action instead of the jsp. This > configuration results > in the suppressing of the content-type and content-length headers (on all > requests, not just the export). > > However, if I remove the requestURI attribute the initial request to the > action still suppresses the content type/length headers, but the all the > links that now reference the jsp (the prev/next and export links) work > properly (content type/length headers come through, export opens in Excel, > etc.). > > So as I say, I think I see the what is happening now, but I don't get why > it's working this way. Any thoughts? > > Scott > > -----Original Message----- > From: Andy Pruitt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 07, 2003 10:14 AM > To: [EMAIL PROTECTED] > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy workaround to T > iles/Export Issue > > > I just tested it on Tomcat 4.1.27, it worked fine. Here's > the war I used, it has compiled classes and src. > > The writeExport looks correct, I have: > > protected int writeExport(String contentType, String body) throws > JspException { > > pageContext.getRequest().setAttribute(ResponseOverrideFilter.CONTENT_OVE > RRIDE_TYPE, contentType); > > pageContext.getRequest().setAttribute(ResponseOverrideFilter.CONTENT_OVE > RRIDE_BODY, body); > return SKIP_PAGE; > } > > Maybe there is a classpath or tld issue? > > > > -----Original Message----- > > From: RMC - Scott Mitchell [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 06, 2003 9:06 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > > workaround to T iles/Export Issue > > > > > > Andy, thanks for the feedback. I had already integrated your > > filter and TableTag class changes into the source of 1.0 > > beta. I can confirm that the filter is firing (I can see the > > log messages). Checking the headers with Firebird shows > > something strange. The content type header is not being sent > > at all! Obviously I've screwed something up while integrating > > your code into the package. Here are the headers that are being sent: > > > > HTTP/1.x 200 OK > > Expires: Thu, 01 Jan 1970 00:00:00 GMT > > Date: Tue, 07 Oct 2003 01:55:04 GMT > > Pragma: No-cache > > Server: Apache Tomcat/4.1.24-LE-jdk14 (HTTP/1.1 Connector) > > Cache-Control: no-cache > > > > The only real edits I had to make was to the writeExport > > method of the TableTag class. I essentially just replaced the > > existing code with the > > following: > > > > > > pageContext.getRequest().setAttribute(ResponseOverrideFilter.C > > ONTENT_OVERRID > > E_TYPE, pMimeType); > > > > pageContext.getRequest().setAttribute(ResponseOverrideFilter.C > > ONTENT_OVERRID > > E_BODY, pExportString); > > return SKIP_PAGE; > > > > Could you send me the text of your writeExport method? > > > > Thanks, > > Scott > > > > PS: I've confirmed that when I disable the filter the content > > type header comes through successfully. > > > > -----Original Message----- > > From: Andy Pruitt [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 03, 2003 9:12 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > > workaround to T iles/Export Issue > > > > > > It sounds as though the filter isn't catching the output. > > > > 1) Unless/until the fix to TableTag is committed, you have to run > > the tag as the TableTag that I attached to that message. I'm > > attaching compiled versions to this message; they would go in a > > com/backstopsolutions/web folder. > > > > 2) You have to change the TLD to have it refer to: > > <tagclass>com.backstopsolutions.web.TableTag</tagclass> > > instead of: > > <!-- <tagclass>org.displaytag.tags.TableTag</tagclass>--> > > > > 3) Do you see debug output? The filter is outputing a DEBUG > > message on the category com.backstopsolutions.web.TableTag. > > > > 4) Use Firebird and the Live Http Headers. It's the bomb. > > Watch the content-type that comes back from the page. > > > > Once/if the patch and filter are added to displaytag, you > > won't go through such hoops; it would only be a question of > > adding the filter mapping. > > > > > > > -----Original Message----- > > > From: RMC - Scott Mitchell [mailto:[EMAIL PROTECTED] > > > Sent: Friday, October 03, 2003 9:20 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > > > workaround to T iles/Export Issue > > > > > > > > > Andy, I agree whole-heartedly with you! I tried a small > > test the other > > > night and getting the filter configured wasn't a big deal > > at all. Now > > > having said that I did still wind up with a problem. All the pages > > > rendered fine, but when I clicked on the Excel export link the data > > > was displayed directly in the browser as text. Is seemed like the > > > content type either didn't get set properly, or the browser somehow > > > ignored it. Any thoughts? > > > > > > Scott > > > > > > -----Original Message----- > > > From: Andy Pruitt [mailto:[EMAIL PROTECTED] > > > Sent: Friday, October 03, 2003 10:07 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [displaytag-devel] RE: [displaytag-user] Easy > > > workaround to Tiles/Export Issue > > > > > > > > > > > > The issue is broader than just Tiles; it's anytime you need > > to have an > > > exportable table that is not in the first page fragment to be > > > processed. I've attached a test case to this email; if you go > > > directly to test2.jsp export will work fine, but going to > > > test.jsp and > > > hitting export will output the file inline as text. > > > > > > It seems much more intrusive to say that: > > > 1) Your table must always appear on it's own page > > > 2) You must create actions for each of the export options > > > 3) Your code must be tied to the internal parameter > > > names from the > > > taglib > > > > > > Than to say; > > > just add this filter in web.xml if you want exports to work. > > > > > > > > > I'm never in favor of more configuration, but if someone > > has already > > > gone through all of the trouble of configuring Tiles, I > > don't think it > > > is too outrageous for them to add a filter mapping to their web.xml. > > > > > > > > > > > > > > This will not work in the latest beta: > > > > The "exportType" parameter name changes for any table to allow > > > > placement of more tables on the same page. You should > > check for any > > > > parameter like d-????-e, (for example d-1234-e) > > > > > > > > See it on > > > > http://www.displaytag.org/displaytag-1.0-b1-examples/example-e > > > > xport.jsp > > > > > > > > fabrizio > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Matt > > > > Raible > > > > Sent: Friday, October 03, 2003 4:56 AM > > > > To: [EMAIL PROTECTED]; > > > > [EMAIL PROTECTED] > > > > Subject: [displaytag-user] Easy workaround to Tiles/Export Issue > > > > > > > > I figured out an easy "workaround" to the fact that > > > exporting doesn't > > > > work when using Tiles. The happens because the response > > > has already > > > > been committed by Tiles (when including previous JSPs) and the > > > > displaytag is unable to set the contentType. > > > > > > > > Here's how I'm doing it: > > > > > > > > In struts-config.xml, create a local forward that goes > > > directly to the > > > > JSP: > > > > > > > > <forward name="exportList" > > path="/WEB-INF/pages/userList.jsp"/> > > > > > > > > Then in your Action, add a little logic to see if you > > > should forward > > > > to the definition or to the list: > > > > > > > > // if exportType is a parameter, forward directly to JSP > > > > if (request.getParameter("exportType") != null) { > > > > if (log.isDebugEnabled()) { > > > > log.debug("export detected, forwarding > > directly to list > > > > jsp"); > > > > } > > > > > > > > return mapping.findForward("exportList"); > > > > } else { > > > > // return a forward to the user list definition > > > > return mapping.findForward("list"); > > > > } > > > > > > > > Tested with displaytag 0.8.5 on Windows XP and Tomcat 4.1.27. > > > > > > > > HTH, > > > > > > > > Matt > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > displaytag-user mailing list [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/displaytag-user > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > displaytag-devel mailing list > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > displaytag-devel mailing list [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > displaytag-devel mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > displaytag-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/displaytag-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
