You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Akber Choudhry <ak...@dyanet.com> on 2002/03/11 16:30:43 UTC

better container compliance

Here are some mods done specifically for Websphere, but may be used
elsewhere. I also have my home-grown version of the IBM WAS StoredResponse
in case we agree to use some of this.

Itch: JSP generator should really be a servlet generator as JSP's are
handled by the JSP servlet, which invokes different compilers in various
implementations.  Cocoon should not be implementation specific  and not
call the compiler directly, honouring the Container and J2EE spec.  Also,
we should only take the buffered output of the response and, and ignore most
headers (until response headers from external input can participate in
complex pipeline handling -- future ).

Scratch: In this way, the servlet can be the PHP servlet, SSI, CGI or any
other existing business servlet, and the web application URI map is
honoured.  Makes cocoon co-exist and enhance web applications.


Just the relevant portions --

public class ServletEngineImplRequestDispatcherInclude extends
AbstractLoggable
    implements ServletEngine, ThreadSafe {

    public byte[] executeURI(String url, HttpServletRequest httpRequest,
HttpServletResponse httpResponse, ServletContext context)
        throws IOException, ServletException, Exception {

        byte[] bytes = null;

        // get ServletEngine Dispatcher.
        javax.servlet.RequestDispatcher rd = context.getRequestDispatcher(
url );
        StoredResponse storedresponse = new StoredResponse();
        storedresponse.setLocale(httpRequest.getLocale());
        if (rd != null) {
          rd.include( httpRequest, storedresponse );
		  bytes = storedresponse.getOutputBuffer();
        } else {
          getLogger().error( "Error getting " + url + "from ServletEngine
Dispatcher" );
        }
        return bytes;
    }
}

----------------------

Itch: Cocoon servlets attempts to write the content type when sending an
error to the container.  Changed -- moved sendError after the bean
creation and put the bean into the session.  Invalidate the session in the
web application error page.  Container handles gracefully.

                SimpleNotifyingBean n = new SimpleNotifyingBean(this);
                n.setType("error");
                n.setTitle("Resource not found");
                n.setSource("Cocoon servlet");
                n.setMessage("The requested resource not found.");
                n.setDescription("The requested URI \""
                                 + request.getRequestURI()
                                 + "\" was not found.");
                n.addExtraDescription("request-uri",
request.getRequestURI());
                n.addExtraDescription("path-info", uri);
                // send the notification but don't include it in the
output stream
                // as the status SC_NOT_FOUND is enough
                req.getSession(true).setAttribute("cocoon_error", n);

                res.sendError(res.SC_NOT_FOUND);
              // webapp error
res.setContentType(Notifier.notify(n, (OutputStream)null));


----------- sample webapp error page ---



<%@ page isErrorPage="true" %>
<jsp:useBean id="cocoon_error" scope="session"
class="org.apache.cocoon.components.notification.SimpleNotifyingBean"/>
<html>
<head>
<title>Error: <%=exception.getMessage()
%></title>
</head>
<body>
<h2> Cocoon Error </h2>
<font face="Verdana" color="red" size="3">
<b><em><%= exception.getMessage() %> </em></b>
</font>
<% if (cocoon_error != null) { %>
<br/><b> Error Type:&nbsp;</b><%= cocoon_error.getType() %>
<br/><b> Error Title:&nbsp;</b><%= cocoon_error.getTitle() %>
<br/><b> Error Source:&nbsp;</b><%= cocoon_error.getSource() %>
<br/><b> Error Sender:&nbsp;</b><%= cocoon_error.getSender() %>
<br/><b> Error Message:&nbsp;</b><%= cocoon_error.getMessage() %>
<br/><b> Error Description:&nbsp;</b><%= cocoon_error.getDescription() %>
<br/><b> Extra Description(s):&nbsp;</b><%=
cocoon_error.getExtraDescriptions() %>
<br/><b> Stack Trace:&nbsp;</b><br/>
<% } %>
<pre>
<% exception.printStackTrace(new PrintWriter(out)); %>
</pre>
<% session.invalidate(); %>
</body>
</html>


-- 
Akber Choudhry
Dyanet Inc.
http://www.dyanet.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: better container compliance

Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Here are some mods done specifically for Websphere, but may be used
> elsewhere. I also have my home-grown version of the IBM WAS StoredResponse
> in case we agree to use some of this.
>
> Itch: JSP generator should really be a servlet generator as JSP's are
> handled by the JSP servlet, which invokes different compilers in various
> implementations.  Cocoon should not be implementation specific  and not
> call the compiler directly, honouring the Container and J2EE spec.  Also,
> we should only take the buffered output of the response and, and ignore
most
> headers (until response headers from external input can participate in
> complex pipeline handling -- future ).
>
> Scratch: In this way, the servlet can be the PHP servlet, SSI, CGI or any
> other existing business servlet, and the web application URI map is
> honoured.  Makes cocoon co-exist and enhance web applications.

JSP Generator uses JSPEngine interface to get the output of a JSP page. The
same JSPEngine is used in JSPReader which simply outputs the response. So,
something like a ServletEngine is needed that will be used to grab output
from other servlets.

Cocoon does not call compiler directly to compile JSP pages. Compiler is
needed to compile the sitemap (if compiled version is used) and for XSP
pages. So, in this case Cocoon honours J2EE spec (don't know any Container
spec).

>
>
> Just the relevant portions --
>
> public class ServletEngineImplRequestDispatcherInclude extends
> AbstractLoggable
>     implements ServletEngine, ThreadSafe {
>
>     public byte[] executeURI(String url, HttpServletRequest httpRequest,
> HttpServletResponse httpResponse, ServletContext context)
>         throws IOException, ServletException, Exception {
>
>         byte[] bytes = null;
>
>         // get ServletEngine Dispatcher.
>         javax.servlet.RequestDispatcher rd = context.getRequestDispatcher(
> url );
>         StoredResponse storedresponse = new StoredResponse();
>         storedresponse.setLocale(httpRequest.getLocale());
>         if (rd != null) {
>           rd.include( httpRequest, storedresponse );
>   bytes = storedresponse.getOutputBuffer();
>         } else {
>           getLogger().error( "Error getting " + url + "from ServletEngine
> Dispatcher" );
>         }
>         return bytes;
>     }
> }
>

Patches are welcome

Konstantin

> ----------------------
> <skipped why="no comments" />
>
> --
> Akber Choudhry
> Dyanet Inc.
> http://www.dyanet.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: better container compliance

Posted by Stefano Mazzocchi <st...@apache.org>.
Akber Choudhry wrote:
> 
> Here are some mods done specifically for Websphere, but may be used
> elsewhere. I also have my home-grown version of the IBM WAS StoredResponse
> in case we agree to use some of this.
> 
> Itch: JSP generator should really be a servlet generator as JSP's are
> handled by the JSP servlet, which invokes different compilers in various
> implementations.  Cocoon should not be implementation specific  and not
> call the compiler directly, honouring the Container and J2EE spec.

I agree with this, only that, so far, nobody proposed anything better
than what we have today.

> Also,
> we should only take the buffered output of the response and, and ignore most
> headers (until response headers from external input can participate in
> complex pipeline handling -- future)

> Scratch: In this way, the servlet can be the PHP servlet, SSI, CGI or any
> other existing business servlet, and the web application URI map is
> honoured.  Makes cocoon co-exist and enhance web applications.

Ok, let's see.
 
> Just the relevant portions --
> 
> public class ServletEngineImplRequestDispatcherInclude extends
> AbstractLoggable
>     implements ServletEngine, ThreadSafe {
> 
>     public byte[] executeURI(String url, HttpServletRequest httpRequest,
> HttpServletResponse httpResponse, ServletContext context)
>         throws IOException, ServletException, Exception {
> 
>         byte[] bytes = null;
> 
>         // get ServletEngine Dispatcher.
>         javax.servlet.RequestDispatcher rd = context.getRequestDispatcher(
> url );
>         StoredResponse storedresponse = new StoredResponse();
>         storedresponse.setLocale(httpRequest.getLocale());
>         if (rd != null) {
>           rd.include( httpRequest, storedresponse );
>                   bytes = storedresponse.getOutputBuffer();
>         } else {
>           getLogger().error( "Error getting " + url + "from ServletEngine
> Dispatcher" );
>         }
>         return bytes;
>     }
> }
> 
> ----------------------
> 
> Itch: Cocoon servlets attempts to write the content type when sending an
> error to the container.  Changed -- moved sendError after the bean
> creation and put the bean into the session.  Invalidate the session in the
> web application error page.  Container handles gracefully.
> 
>                 SimpleNotifyingBean n = new SimpleNotifyingBean(this);
>                 n.setType("error");
>                 n.setTitle("Resource not found");
>                 n.setSource("Cocoon servlet");
>                 n.setMessage("The requested resource not found.");
>                 n.setDescription("The requested URI \""
>                                  + request.getRequestURI()
>                                  + "\" was not found.");
>                 n.addExtraDescription("request-uri",
> request.getRequestURI());
>                 n.addExtraDescription("path-info", uri);
>                 // send the notification but don't include it in the
> output stream
>                 // as the status SC_NOT_FOUND is enough
>                 req.getSession(true).setAttribute("cocoon_error", n);
> 
>                 res.sendError(res.SC_NOT_FOUND);
>               // webapp error
> res.setContentType(Notifier.notify(n, (OutputStream)null));
> 
> ----------- sample webapp error page ---
> 
> <%@ page isErrorPage="true" %>
> <jsp:useBean id="cocoon_error" scope="session"
> class="org.apache.cocoon.components.notification.SimpleNotifyingBean"/>
> <html>
> <head>
> <title>Error: <%=exception.getMessage()
> %></title>
> </head>
> <body>
> <h2> Cocoon Error </h2>
> <font face="Verdana" color="red" size="3">
> <b><em><%= exception.getMessage() %> </em></b>
> </font>
> <% if (cocoon_error != null) { %>
> <br/><b> Error Type:&nbsp;</b><%= cocoon_error.getType() %>
> <br/><b> Error Title:&nbsp;</b><%= cocoon_error.getTitle() %>
> <br/><b> Error Source:&nbsp;</b><%= cocoon_error.getSource() %>
> <br/><b> Error Sender:&nbsp;</b><%= cocoon_error.getSender() %>
> <br/><b> Error Message:&nbsp;</b><%= cocoon_error.getMessage() %>
> <br/><b> Error Description:&nbsp;</b><%= cocoon_error.getDescription() %>
> <br/><b> Extra Description(s):&nbsp;</b><%=
> cocoon_error.getExtraDescriptions() %>
> <br/><b> Stack Trace:&nbsp;</b><br/>
> <% } %>
> <pre>
> <% exception.printStackTrace(new PrintWriter(out)); %>
> </pre>
> <% session.invalidate(); %>
> </body>
> </html>

Ah, you are re-inverting the control... hmmmm, I fail to see how this is
going to make Cocoon more container compliant.

Care to elaborate more on this?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org