Bugs item #636920, was opened at 2002-11-12 02:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jeff Miner (jeff_miner)
Assigned to: Nobody/Anonymous (nobody)
Summary: JSP INCLUDE
Initial Comment:
v 3.0.4
See my previous #594563 which starksm closed.
Inclusion of JSP using RequestDispatcher causes
included content to jump to top of page.
He claims this was fixed, yet the latest, greatest
download (v 3.0.4) exhibits the same behavior.
Do I need to upgrade Jetty separately?
One can flush the out buffer in the JSP before
including, but I need to do this in the object, not in
the JSP. Why doesn't the RequestDispatcher know
how to do this?
----------------------------------------------------------------------
Comment By: Greg Wilkins (gregwilkins)
Date: 2002-12-08 22:58
Message:
Logged In: YES
user_id=44062
Thanks for feeding back this solution.
we'll close this issue now (but will still think about
making it
work the way it OUGHT to :-)
regards
----------------------------------------------------------------------
Comment By: Jeff Miner (jeff_miner)
Date: 2002-11-14 22:35
Message:
Logged In: YES
user_id=592596
Aha!
Looks like the clean way to do this is with
PageContext.include()
Thus, pass the PageContext, but not necessarily the
Request and Response, and call PageContext.include()
without a Dispatcher. Seems to work and is cleaner
(though the Dispatcher still OUGHT to work)
----------------------------------------------------------------------
Comment By: Jeff Miner (jeff_miner)
Date: 2002-11-14 10:58
Message:
Logged In: YES
user_id=592596
OK - Sorry I got hot under the collar - I'm having roughly
the same discussion with Macromedia over JRun and they
out and out said "it is not a bug, this is according to spec"
which is just foolish.
I guess I can sort of envision how the problem arises from
not integrating the JSPs into the ServletEngine, but I still
don't understand how the servlet can do ANY include
properly if this doesn't work - that is, if the JSP servlet is
up to spec, because any servlet's output would have to be
properly inserted in the buffer. Why should the JSP
servlet be different?
I can use the workarounds, but it means an extensive
rewrite. The reason things need to be done this way (in
brief) is that the getOutput() method exists on many
objects polymorphically and may not do an include at all,
so I don't want to mess with buffers etc. and would rather
not have to add params to all my method calls.
FYI - This is actually a small part of a nested MVC design
----------------------------------------------------------------------
Comment By: Greg Wilkins (gregwilkins)
Date: 2002-11-14 10:27
Message:
Logged In: YES
user_id=44062
Hey Jeff - keep it cool OK.
We are not ignoring your problem. We have analyzed it and given
you some suggestions. Pretty good service for free!
I agree - that it the include SHOULD work the same either way.
It works for weblogic, because their JSP engine is
integrated into their
servlet engine.
But many containers such as Jetty and Tomcat implement JSPs
simply as a servlet within the container. It is not
possible to simply resolve this
problem with such an implementation of JSPs.
The mood on the servlet JSR is that integrating JSPs with
the servlet spec was a mistake and JSPs should no longer
given special status within servlet containers. Why are
JSPs favoured over webmacros, velocity,
cocoon, etc. etc.? Hence future versions of the spec are
moving
away from tight integration of JSPs. If this was not the
case,
then I might be more inclined to jump hurdles to fix this
problem.
The root of the problem is a bad spec. It's not a bug, just
poorly
defined integration of several features.
So the reality of the situation is that I think it VERY
unlikey that
this "bug" will be fixed by either the developers of jasper,
tomcat or
jetty. But, it is open source and you are free to give it a
go yourself!
PS. Servlets don't normally "have to know about JSP
buggering, etc. in order to include them properly". You are
using servlet code within a
JSP and that is not normal. There are plenty of things you
can break
in JSPs if you start playing with the full servlet API -
these are not bugs,
just dangers inherent in the design of JSPs.
I strongly suggest that once you have invoked a JSP, that
you use
JSP techniques for include etc. If you want to do servlet
stuff, then
do it in a servlet - not via a JSP. Better yet, get a
propper MVC
design going, where the servlets do the Control and JSPs to
the View.
regards
----------------------------------------------------------------------
Comment By: Jeff Miner (jeff_miner)
Date: 2002-11-14 10:01
Message:
Logged In: YES
user_id=592596
Mr. Wilkins,
I don't want to get snippy here, but I do not think there is
any problem with MY code.
A RequestDispatcher that dispatches to a JSP should do
exactly what the <jsp:include> tag does -- no more, no less.
Servlets shouldn't have to know about JSP buffering, etc.
in order to include them properly.
Certainly I could pass the writer around, I can pass the
PageContex around, I can flush the buffers, but these are
workarounds. These are ways for me to avoid the bug.
It is still a bug and should be fixed, not ignored.
FYI - Weblogic has handled this properly since at least
Version 4.5
----------------------------------------------------------------------
Comment By: Greg Wilkins (gregwilkins)
Date: 2002-11-14 01:31
Message:
Logged In: YES
user_id=44062
OK - the problem with your code is that you have decended
back into servlet land to do your include. Poor old
servlets have no idea about what ever
wrappers your JSP (or JSP Engine) has put around the output
stream
and/or writer.
So the servlets are do the dispatch and the new jsp gets the
outputstream and/or writer again from the response and wraps
them
again, without knowing about any buffering already done by
your last JSP.
I think that is why <jsp:include> works, because it knows
about JSP buffering & writers.
You can simply do a flush before your getOutput call, or I
think you can
configure JSPs to do that for you (or not to buffer or
something).
Alternately, you could pass in the JSPs writer to your
getOutput call,
it could wrap the response object and it could return the
writer from
it's getWriter call.
cheers
----------------------------------------------------------------------
Comment By: Jeff Miner (jeff_miner)
Date: 2002-11-13 20:17
Message:
Logged In: YES
user_id=592596
Here is the basic layout of the problem
******Containing Page*******
....<table><tr><td>
<%= myObject.getOutput(request, response) %>
</td></tr></table>...
******* Object ********
public String getOutput(HttpServletRequest request,
HttpServletResponse response) {
RequestDispatcher dispatch =
context.getRequestDispatcher("someJSP.jsp");
try {
dispatch.include(request, response);
} catch(Exception e){}
return "";
*************
I am beginning to understand the extent of the
mishmosh of writers, etc. but it seems to me that the
encapsulating objects should handle these issues.
My point is essentially that a call to
RequestDispatcher.include() really ought to do exactly
the same thing as a <jsp:include>. It doesn't, though.
----------------------------------------------------------------------
Comment By: Greg Wilkins (gregwilkins)
Date: 2002-11-13 00:20
Message:
Logged In: YES
user_id=44062
Can you give us a pair of JSPs that exhibit this problem?
The following URL to the jetty demo site shows that it does
work at least for all the examples that I have.
http://jetty.mortbay.org/jetty/dispatch/include/snoop.jsp
Remember that request dispatching, JSPs, writers and
outputstreams all form a complex little mishmash of
buffering vs flushing (which slows
down performance a lot). You may have some content that
you think has been written to the response before the
include, but it is actually still in a JSP or writer buffer
somewhere (outside the control of Jetty!). I think JSPs do
have some mechanisms for controlling this.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
