I tried turning of JavaScript just now, but then I can't submit the form. I
think the JSF (or perhaps tomahawk) is relying on the JS to submit. I tried
entering an input field and hitting "enter" but that didn't submit the form.
Another thing that I thought of was that sitemesh might be interfering. I
excluded **/*.xls from the decorators.xml file, but that didn't seem to make
a difference. I wonder if upon the first submit the URL location still
looks like the report form URL, but then after that it looks like the
attachment URL? I've seen similar, weird behavior in the URL while using my
app; that is, where the URL location always seems to look llike it's one
step behind. So if I'm on a List page and click into a form, the URL still
says "list". Then when I submit the form and return to the list, the URL
says "form".
- Lon
mraible wrote:
>
> On Wed, Apr 30, 2008 at 7:39 AM, LonB <[EMAIL PROTECTED]> wrote:
>>
>> Matt, thanks for the incredibly fast response! I added the two
>> dispatcher
>> params to the filter mapping for the encodingFilter, but no change.
>>
>> I have a feeling this has something to do with the bean method being
>> invoked
>> twice?
>
> Sounds like a good guess. Have you tried turning off JavaScript to
> ensure there's no type of double-submit going on?
>
> Matt
>
>>
>> - Lon
>>
>>
>>
>>
>>
>> mraible wrote:
>> >
>> > By "might help", I mean you might change its <dispatcher>s on the
>> > <filter-mapping> to be REQUEST and FORWARD.
>> >
>> > Matt
>> >
>> > On Wed, Apr 30, 2008 at 7:19 AM, Matt Raible <[EMAIL PROTECTED]>
>> > wrote:
>> >> There's a CharacterEncodingFilter in web.xml that might helps.
>> >>
>> >> Matt
>> >>
>> >>
>> >>
>> >> On Wed, Apr 30, 2008 at 7:15 AM, LonB <[EMAIL PROTECTED]> wrote:
>> >> > In a JSF page, I have a form in a view, that submits via an
>> action
>> >> > commandlink... something like: <f:view>
>> >> > <h:form id="runReport">
>> >> > ...
>> >> > <h:commandLink action="#{reportList.run}"
>> >> > value="#{text['button.runReport']}">
>> >> > <f:param name="customerId" value="#{reportList.customerId}" />
>> >> > </h:commandLink>
>> >> > ...
>> >> >
>> >> > It invokes the "run" method of the backing bean, which executes a
>> >> POI/HSSF
>> >> > (excel) report, and streams it to the output stream. Something
>> like
>> >> > ('BasePage' is from AppFuse):
>> >> >
>> >> > public class ReportList extends BasePage implements Serializable
>> {
>> >> > ...
>> >> > public String run() {
>> >> > HttpServletResponse response = getResponse();
>> >> > response.setContentType("application/vnd.ms-excel");
>> >> > response.setHeader("Content-Disposition", "attachment;
>> >> > filename=Summary.xls");
>> >> > ...
>> >> > ServletOutputStream out = response.getOutputStream();
>> >> > workbook.write(out);
>> >> > out.flush();
>> >> > out.close();
>> >> > ...
>> >> > getFacesContext().responseComplete();
>> >> > return null;
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > The first time I startup tomcat 6.0 and submit the form, the page
>> >> returns
>> >> > incorrectly encoded characters, that look something like:
>> >> >
>> >> > ? ?X @? ????? ???"? ??? ? ? ?? ????? ???1? ?????? ? ??????
>> >> A?r?i?a?l?1?
>> >> > ?????? ? ?????? ;_("$"* "-"_);_(@_) .?)?)??
>> >> >
>> >> >
>> >> >
>> >> > Simply hitting 'refresh' resolves the issue and then it works
>> fine
>> >> (the
>> >> > form loads correctly, the browser "open or save as" dialog opens
>> >> correct and
>> >> > the output excel document is perfect. If I leave the page and
>> return,
>> >> it
>> >> > generally works fine. And this only seems to happen once per app
>> >> server
>> >> > startup.
>> >> >
>> >> > I compared the HTTP headers of the correctly working case and the
>> >> broken
>> >> > case, the only two differences are the "Content-Type", which is
>> >> "text/html"
>> >> > when broken and "text/html;charset=UTF-8" when working. And the
>> second
>> >> is
>> >> > the response compression, which is "gzip" when working and "-"
>> when
>> >> broken.
>> >> > I disabled the gzip filter but that didn't help. I'm not sure how
>> to
>> >> adjust
>> >> > the character encoding.
>> >> >
>> >> > Any advice would be greatly appreciated!
>> >> >
>> >> > Thanks, Lon
>> >> > ________________________________
>> >> > View this message in context: JSF semi-randomly returns
>> incorrectly
>> >> encoded
>> >> > output. Fixed by hitting refresh.
>> >> > Sent from the AppFuse - User mailing list archive at Nabble.com.
>> >> >
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JSF-semi-randomly-returns-incorrectly-encoded-output.--Fixed-by-hitting-refresh.-tp16982293s2369p16982736.html
>>
>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/JSF-semi-randomly-returns-incorrectly-encoded-output.--Fixed-by-hitting-refresh.-tp16982293s2369p16983310.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
