Can't say for ajax4jsf filter, but there is documentation you might find
helpful about tomahawk extension filter here:
http://wiki.apache.org/myfaces/Performance
All i know is ajax4jsf use filter to make your html xml compliant and
this filter can, if i remember well, be bypassed by telling it you
assume the charge of making your xhtml xml compliant.
mccurdyc a écrit :
Afternoon,
The application I'm working on had a CSV export component developed with all
sorts of wizzy-bang business logic and is fairly important to our customer.
The problem is while reviewing it yesterday I came to notice that it was
taking up a huge amount of memory while generating exports. I reviewed the
code, saw that it was streaming reasonably to the response print writer, but
while debugging it appeared as though the print writer to never actually
being flushed or sent to the client. After adding several flushes and
response.flushBuffer() I got baffled. So I debugged in to the bowels of our
filters and found the ExtensionsFilter (and Ajax4JSF filter) to be the
culprits. It seems that they wrap the response and request object with
their own buffers and only flush them when the response is complete. I
assume this allows them to easily inject javascript and such. However this
storing instead of streaming to the client plays heck with our 100MB CSV
file.
The other crux of the matter is that the component was written in a tightly
coupled manner with the page and the state it is in. So my first
inclination was to write an export servlet that bypassed these filters, but
the work involved with decoupling this component and making it in to an
export servlet due to time constraints, is likely a last resort.
Our more hackish solution is to write or extend new filters and wrappers to
replace the ones in ExtensionsFilter (and Ajax4JSF) and expose the real
response object there. I dislike hackery, but I'm at a loss for something
cleaner.
Any ideas, comments, or suggestions?
Thanks!
Chris
JSF 1.1, Tomahawk 1.1.6, Ajax4JSF 1.1.1.
