I just wanted to follow up with a point I intended to make in my previous message but forgot. DMF does not buffer the entire response before deciding whether to pass it to the client. It buffers up to a certain amount (default 1024 bytes) and if that buffer overflows then DMF assumes it's a valid response and passes everything directly through. Just in case my description had you worried about that.
-Ben On Mon, May 10, 2010 at 11:16 PM, Ben Gunter <[email protected]> wrote: > Believe me, I have tried to extend StripesFilter for DMF. It doesn't work. > And then a few months will pass, and I'll think to myself, "Self, why was it > that I couldn't extend StripesFilter again?" And then I work on it for about > twenty minutes or so before I run into the same brick wall. I've repeated > that loop a few times already. It's difficult for me to remember exactly > what the problem is, but I think I have a handle on it right now. > > DMF works by passing the request through, buffering the response, and > checking the status code. If the code is anything other than 404 it passes > the response directly back to the client. This allows it to serve up static > files (HTML, CSS, images, etc.) normally as well as dynamic content that is > statically mapped. > > Only when DMF spies a 404 response does it intervene. When it sees a 404, > it asks the ActionResolver if any ActionBeans map to the requested URL. If > not, then it returns the 404 to the client. However, if an ActionBean does > map then it discards the 404 response and directly invokes StripesFilter and > then DispatcherServlet to serve up the response. > > So here's the problem with extending StripesFilter to do this. Take, for > example, a JSP that needs StripesFilter. (This was not unusual in the early > days of Stripes; see the Bugzooky example app in any released version.) The > first thing DMF would do would be to execute the request normally ... which, > for a JSP that needs StripesFilter, would result in a 500 response. How do > you solve that problem? Map DMF to *.jsp? Nope, DMF is already mapped to /* > so that wouldn't help anything. Similarly, if DispatcherServlet were > statically mapped (e.g., to *.action or /action/*) then DMF would also pass > through the request and get back a 500 response. > > One solution would be to just execute all the StripesFilter goodness for > every request, but that's a terrible solution. We wouldn't do that for the > same reason we don't map StripesFilter to /*. That's a lot of stuff you > don't want to execute for every single request. Another solution would be to > define a configuration parameter to specify some mappings for which to > revert to the current StripesFilter behavior, but that feels really dirty, > which is why I chose not to do it that way. Not that that decision looks all > that great now ... > > Anyway, suggestions on how to solve the problem are welcome. I had a > solution worked out, but I never checked it in because it, too, felt a > little bit dirty. (Parsing web.xml and things of that nature.) I might just > have to check that in and be done with it. > > -Ben > > On Mon, May 10, 2010 at 5:13 PM, Nikolaos Giannopoulos < > [email protected]> wrote: > >> Ben, >> >> I understand. For the time being I have simply done what was suggested as >> not being optimal but is the only work around that I know of which is as >> follows: >> >> <filter-mapping> >> <filter-name>StripesFilter</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> </filter-mapping> >> >> <filter-mapping> >> <filter-name>DynamicMappingFilter</filter-name> >> <url-pattern>/*</url-pattern> >> <dispatcher>REQUEST</dispatcher> >> <dispatcher>FORWARD</dispatcher> >> <dispatcher>INCLUDE</dispatcher> >> </filter-mapping> >> >> If I understand the issue correctly it appears that the an instance of the >> StripesFilter servlet needs to be initialized before the >> DynamicFilterMapping. If that is the case then why doesn't the >> DynamicMappingFilter extend the StripesFilter vs. not extending it yet >> depending on it to be initialized before hand but crossing your fingers it >> gets initialized before hand and is available for use (I realize that it >> appears that the spec is OK with this and it is more than crossing your >> fingers but it still seems like a perhaps unnecessary leap of faith)? >> >> >> I'll also reply to the ticket to point out that I too have experienced the >> issue on GlassFish v3 Final. When I become more experienced with Stripes >> I'll look into trying to resolve this as well... . >> >> >> >> Ben Gunter wrote: >> >> No, another ticket isn't necessary. It's the same problem on all of the >> affected containers. I didn't come up with a solution that I liked when I >> was looking at this a while back, and I haven't had time to look into it in >> a while. >> >> On Mon, May 10, 2010 at 2:32 AM, Nikolaos Giannopoulos < >> [email protected]> wrote: >> >>> As Nicholas pointed out in a comment on 29/Oct/2009 on this issue: >>> http://www.stripesframework.org/jira/browse/STS-678 >>> >>> "This is happening in GlassFish v3 as well" >>> >>> I experienced this same issue just today on GlassFish v3 Final. As this >>> is still unresolved and the last update states IBM is working on a patch for >>> WAS and the title includes "WAS 6.1" AND nobody wants to open tickets that >>> will be closed as duplicates: >>> >>> Should I open a ticket specifically for GlassFish v3? >>> >>> I also wonder if more than one app server is experiencing this issue >>> perhaps a cross container solution should be considered? >>> >>> Thoughts? >>> >>> --Nikolaos >>> >> >> >> >
------------------------------------------------------------------------------
_______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
