portal-struts bridge, filter and buffering

[Mike Douglass <do...@rpi.edu>]

I've spent some time trying to use the portal-struts bridge to get an 
application running as a portlet.

I'm experiencing behaviour which appears to be related to buffering in 
the JspWriter.

The struts application uses an xslt filter to transform xml to html 
(usually). As a standalone application it works, as a portlet I got tow 
responses from it,

no content, or truncated xml at about 8k. I could trigger the second 
response by adding content till the xml exceeded the 8k boundary.

I tried setting a jsp page directive with  buffer="none" and now I get 
no content whatever I do.

The filter wraps the response and I added some debugging to the wrapper 
- for example I flagged the getWriter() call. Before setting the 
buffering in the page directive, getWriter() was called after the jsp 
was processed. Once I set buffer="none" is was called early in the jsp. 
However, nothing was written o the writer (more debugging to track that).

Any clues?

-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: portal-struts bridge, filter and buffering

[Mike Douglass <do...@rpi.edu>]

Further work has persuaded me that something needs to flush the output - 
I imagine somewhere in the portlet bridge.

The problem will show up with any filtered application that reads or 
modifes the response stream. A flush should be done before control is 
handed back to the first filter in the chain -  and now I think of it - 
maybe my filter should flush for the same reason.

I found the following in the tomcat source in ResponseIncludeWrapper 
which seems to imply the same

    /**
     * Flush the servletOutputStream or printWriter ( only one will be 
non-null )
     *
     * This must be called after a requestDispatcher.include, since we 
can't assume that
     * the included servlet flushed its stream.
     */
    public void flushOutputStreamOrWriter() throws IOException {
    if ( servletOutputStream != null ) {
        servletOutputStream.flush();
    }
    if ( printWriter != null ) {
        printWriter.flush();
    }
    }


What I did to get my application to work is include the following as the 
last line in the jsp:

<% pageContext.getOut().flush(); %>



Mike Douglass wrote:

> I've spent some time trying to use the portal-struts bridge to get an 
> application running as a portlet.
>
> I'm experiencing behaviour which appears to be related to buffering in 
> the JspWriter.
>
> The struts application uses an xslt filter to transform xml to html 
> (usually). As a standalone application it works, as a portlet I got 
> tow responses from it,
>
> no content, or truncated xml at about 8k. I could trigger the second 
> response by adding content till the xml exceeded the 8k boundary.
>
> I tried setting a jsp page directive with  buffer="none" and now I get 
> no content whatever I do.
>
> The filter wraps the response and I added some debugging to the 
> wrapper - for example I flagged the getWriter() call. Before setting 
> the buffering in the page directive, getWriter() was called after the 
> jsp was processed. Once I set buffer="none" is was called early in the 
> jsp. However, nothing was written o the writer (more debugging to 
> track that).
>
> Any clues?
>

-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org