Scott,

Yes, it seems migrating to 3.0 solved my problem. Sanity restored, thanks so
much for your help!

Regards, Misha

On 1/23/07, Scott Ferguson <[EMAIL PROTECTED]> wrote:


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 xxxxxxx"), 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



_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to