You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by BugRat Mail System <to...@cortexity.com> on 2000/08/31 19:54:13 UTC
BugRat Report #57 has been filed.
Bug report #57 has just been filed.
You can view the report at the following URL:
<http://znutar.cortexity.com:8888/BugRatViewer/ShowReport/57>
REPORT #57 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment:
Release: 3.1
JVM Release: 1.3.0
Operating System: NT
OS Release: 4.0 SP6a
Platform: P3
Synopsis:
Request Dispatcher violates Servlet Spec
Description:
These are the first two lines of the forward and include methods:
Request realRequest = ((HttpServletRequestFacade)request).getRealRequest();
Response realResponse = ((HttpServletResponseFacade)response).getRealResponse();
You are explicitly casting to some Tomcat specific request class. How are we suppposed
to be able to write our own response class and still be able to move between different
application servers. You are totally screwing up the whole idea of having a servlet spec.
For example say I wanted to output my jsp to a file instead of the browser. I could write
my own dummy response that overides the getOutputStream method. I can't do this though because
my dummy Response is not a HttpServletRequestFacade class.
I know that there are other ways to do this. This is just one simple example but there are many
other things we could do if you didn't box us into a corner by requiring the request and response to
be your "Facade" classes.
James
james@intellimedia.com
Tomcat/Catalina scalability
Posted by Diether Samaey <di...@alcatel.be>.
Could anybody give me a list of (current and future) Tomcat/Catalina
features with regards to scalability ?
e.g. load balancing, distributability, ...
Cheers,
Diether
Re: BugRat Report #57 has been filed.
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
James Cook wrote:
> Craig,
>
> Do we need to do anything special to take advatange of this in Tomcat 4.0,
> or do we simple pass our wrappered request and response objects in the
> RequestDispatcher.include and RequestDispatcher.forward methods?
>
The only requirement is that your wrapper classes must be a subclass of the
request and response wrapper classes (usually
javax.servlet.http.HttpServletRequestWrapper or
javax.servlethttp.HttpServletResponseWrapper). These classes take as an
argument the request or response you are wrapping, and by default delegate
everything to the wrapped class (so you only have to override the methods for
which you want to change the behavior).
So, to wrap the output you might write a class like this:
public class MyWrappedResponse extends HttpServletResponseWrapper {
public MyWrappedResponse(HttpServletResponse response) {
super(response);
}
... override just the methods you want to change ...
}
and, in your servlet's doGet() or doPost() method you would:
MyWrappedResponse myResponse = new MyWrappedResponse(response);
RequestDispatcher rd =
getServletContext().getRequestDispatcher(...);
rd.include(request, myResponse);
Tomcat 4.0 currently supports this behavior (as well as the new servlet filter
stuff), so feel free to give it a try and report any problems.
>
> jim
>
Craig McClanahan
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
RE: BugRat Report #57 has been filed.
Posted by James Cook <ji...@iname.com>.
Craig,
Do we need to do anything special to take advatange of this in Tomcat 4.0,
or do we simple pass our wrappered request and response objects in the
RequestDispatcher.include and RequestDispatcher.forward methods?
jim
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> In the current draft of Servlet 2.3, this restriction has been removed.
It is
> legal for either a servlet or a filter to provide wrappers for the request
and
> response objects, as long as you subclass the convenience wrapper base
classes
> that are provided. You can experiment with this using the Tomcat 4.0
module,
> where an initial implementation of support for filters and application
wrapped
> request dispatcher arguments is already present.
Re: BugRat Report #57 has been filed.
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
James Cook wrote:
> I struggled with this concept quite a long time ago. There are some definite
> advantages from an application developers point of view to be able to
> override the request and response objects.
>
> I disagree that Tomcat's trouble with passing your custom class thru
> RequestDispatcher makes Tomcat non-spec compliant. In fact, this technique
> won't work on any Servlet engine that I tried at the time. That said, it
> would be nice if the passed classes could be treated as pure interfaces and
> forgo the casting.
>
In fact, the Servlet 2.2 spec *requires* an application to pass the request and
response objects that it initally received on to the request dispatcher's
include() or forward() method. Application wrappers are therefore prohibited.
See section 8.2, first paragraph.
In the current draft of Servlet 2.3, this restriction has been removed. It is
legal for either a servlet or a filter to provide wrappers for the request and
response objects, as long as you subclass the convenience wrapper base classes
that are provided. You can experiment with this using the Tomcat 4.0 module,
where an initial implementation of support for filters and application wrapped
request dispatcher arguments is already present.
>
> jim
>
Craig McClanahan
>
> > -----Original Message-----
> > From: BugRat Mail System [mailto:tomcat-bugs@cortexity.com]
> > Sent: Thursday, August 31, 2000 1:54 PM
> > To: tomcat-bugs@cortexity.com
> > Subject: BugRat Report #57 has been filed.
> >
> >
> > Bug report #57 has just been filed.
> >
> > You can view the report at the following URL:
> >
> > <http://znutar.cortexity.com:8888/BugRatViewer/ShowReport/57>
> >
> > REPORT #57 Details.
> >
> > Project: Tomcat
> > Category: Bug Report
> > SubCategory: New Bug Report
> > Class: swbug
> > State: received
> > Priority: high
> > Severity: critical
> > Confidence: public
> > Environment:
> > Release: 3.1
> > JVM Release: 1.3.0
> > Operating System: NT
> > OS Release: 4.0 SP6a
> > Platform: P3
> >
> > Synopsis:
> > Request Dispatcher violates Servlet Spec
> >
> > Description:
> > These are the first two lines of the forward and include methods:
> >
> > Request realRequest =
> > ((HttpServletRequestFacade)request).getRealRequest();
> > Response realResponse =
> > ((HttpServletResponseFacade)response).getRealResponse();
> >
> > You are explicitly casting to some Tomcat specific request class.
> > How are we suppposed
> > to be able to write our own response class and still be able to
> > move between different
> > application servers. You are totally screwing up the whole idea
> > of having a servlet spec.
> >
> > For example say I wanted to output my jsp to a file instead of
> > the browser. I could write
> > my own dummy response that overides the getOutputStream method.
> > I can't do this though because
> > my dummy Response is not a HttpServletRequestFacade class.
> >
> > I know that there are other ways to do this. This is just one
> > simple example but there are many
> > other things we could do if you didn't box us into a corner by
> > requiring the request and response to
> > be your "Facade" classes.
> >
> > James
> > james@intellimedia.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
RE: BugRat Report #57 has been filed.
Posted by James Cook <ji...@iname.com>.
I struggled with this concept quite a long time ago. There are some definite
advantages from an application developers point of view to be able to
override the request and response objects.
I disagree that Tomcat's trouble with passing your custom class thru
RequestDispatcher makes Tomcat non-spec compliant. In fact, this technique
won't work on any Servlet engine that I tried at the time. That said, it
would be nice if the passed classes could be treated as pure interfaces and
forgo the casting.
jim
> -----Original Message-----
> From: BugRat Mail System [mailto:tomcat-bugs@cortexity.com]
> Sent: Thursday, August 31, 2000 1:54 PM
> To: tomcat-bugs@cortexity.com
> Subject: BugRat Report #57 has been filed.
>
>
> Bug report #57 has just been filed.
>
> You can view the report at the following URL:
>
> <http://znutar.cortexity.com:8888/BugRatViewer/ShowReport/57>
>
> REPORT #57 Details.
>
> Project: Tomcat
> Category: Bug Report
> SubCategory: New Bug Report
> Class: swbug
> State: received
> Priority: high
> Severity: critical
> Confidence: public
> Environment:
> Release: 3.1
> JVM Release: 1.3.0
> Operating System: NT
> OS Release: 4.0 SP6a
> Platform: P3
>
> Synopsis:
> Request Dispatcher violates Servlet Spec
>
> Description:
> These are the first two lines of the forward and include methods:
>
> Request realRequest =
> ((HttpServletRequestFacade)request).getRealRequest();
> Response realResponse =
> ((HttpServletResponseFacade)response).getRealResponse();
>
> You are explicitly casting to some Tomcat specific request class.
> How are we suppposed
> to be able to write our own response class and still be able to
> move between different
> application servers. You are totally screwing up the whole idea
> of having a servlet spec.
>
> For example say I wanted to output my jsp to a file instead of
> the browser. I could write
> my own dummy response that overides the getOutputStream method.
> I can't do this though because
> my dummy Response is not a HttpServletRequestFacade class.
>
> I know that there are other ways to do this. This is just one
> simple example but there are many
> other things we could do if you didn't box us into a corner by
> requiring the request and response to
> be your "Facade" classes.
>
> James
> james@intellimedia.com
>