On Jan 22, 2007, at 8:12 PM, Michael Varshavsky wrote:
Scott,
Thank you so much for trying to help me. I did some thinking and
now I'm starting to blame the RequestDispatcher. Could it be that
some special HttpServletResponse wrapper prevents servlet resources
that are called through the RequestDispatcher from setting content
type on the parent? This would fit with the rest of the facts:
- Works on Tomcat because it has a different RequestDispatcher
implementation
- Works when requesting a .jsp directly, since there is no
forwarding involved
Is there any way to tell the RequestDispatcher to leave the
contentType alone?
BTW, we're using Resin 2.1.10 but have an option of upgrading to
3.0.19 if the issue has been resolved in between those versions.
Can you check with 3.0 or 3.1? That code has changed significantly.
The RequestDispatcher is part of the servlet spec that's really a
mess, especially its interactions with filters. So some parts of
Resin's implementation needs to jump through hoops to make all the
weird spec interactions work.
-- Scott
Regards, Misha
On 1/22/07, Scott Ferguson [EMAIL PROTECTED] wrote:
On Jan 21, 2007, at 9:07 PM, Michael Varshavsky wrote:
Hi,
I've received a request to convert a currently existing mobile
Struts/Tiles-based web application to serve content as
MimeMultipart instead of XHTML. I wrote a ServletFilter that
captures all markup in the response, then parses it to find all the
necessary (css and img) files and downloads them. After that I
create a MimeMultipart object, add markup as a parent part and
styles and images as regular MimeBodyPart(s). Then I set
contentType of the response object to be that of the MimeMultipart
(ends up being multipart/related; boundary xxx), write
MimeMultipart to it and close. I developed and tested on my local
Tocat installation and everything worked as expected. When we
attempted to deploy the code onto our QA server that is running
Resin, we ran into a problem. The filter executes fine, body parts
are added as expected and the contentType is set correctly to
multipart/related (prints fine in the Logs). However, when it
gets to the client, the contentType is overwritten to be text/
html; charset=UTF-8. As a result, browser tries to interpret the
Mutlipart as regular markup writing out binary data for images,
etc. - which is obviously not the desired result.
At first I thought this could be due to the fact that our jsps/
tiles explicitly and through directives set the contentType
to be text/html. So I captured the markup from a regular page in
the app, added
%@ page language='java' session='true' contentType='text/
html; charset=UTF-8'%
% response.setContentType(text/html; charset=UTF-8); %
to it and saved it as jsp page outside of WEB-INF so that I can hit
it directly. This worked fine on Resin!!! I then created a fake
Struts action mapping (ForwardAction) which forwarded to a fake
Tiles definition - which pointed to the same exact test jsp page
(that worked). In this scenario the problem resurfaced and
contentType got overwritten to text/html.
I started blaming Struts. Struts has a way to set contentType on a
per-module basis, through controller's contentType attribute. I
decided to check if that was the root of my problem, so I've added
controller contentType=text/plain/ to my struts configuration
hoping to see my contentType being overwritten to be text/plain
instead of text/html. However,
the contentType header still got overwritten to be text/html.
Trying to think what can possibly be downstream from my filter I
became suspicious of Apache. However, even after disabling
mod_mime, the problem persisted!
To debug, you can open a Resin http port to 8080 to eliminate Apache
as a consideration (I doubt it's the cause.)
I'm not sure what's calling the extra setContentType, since it looks
like some kind of struts interaction. Is it possible to reproduce
this with just forwards/includes and filters?
-- Scott
At this point I don't know what to think and any help would be
greatly appreciated!
Thanks in advance!!!
Misha.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
