Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem +solution?]
Patrick Lightbody wrote: I found a possible way around this, but I'm not sure if it's a good idea or not :) What if the FilterDispatcher never actually makes a call to filterChain.doFilter()? This would get around the duplicate view request problem outlined below, but would require that the filter -must- be the last one applied or else you'll loose the application of filters further down the chain. I don't think this is too bad though, since we can just -clearly- document that the FilterDispatcher (if you want to use it) must be applied last. Thoughts? Works for me :-) /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem + solution?]
I don't plan on using it, so as long as it doesn't mess up the core +1 -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 2:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem + solution?] I found a possible way around this, but I'm not sure if it's a good idea or not :) What if the FilterDispatcher never actually makes a call to filterChain.doFilter()? This would get around the duplicate view request problem outlined below, but would require that the filter -must- be the last one applied or else you'll loose the application of filters further down the chain. I don't think this is too bad though, since we can just -clearly- document that the FilterDispatcher (if you want to use it) must be applied last. Thoughts? -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 1:33 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem] Found one small problem with this approach (and it may just be that using the filter + the servlet at all times just can't always work perfectly): If you are using the filter and servlet and access success.jsp, the action will be invoked, then the ResultInterceptor will kick in, call ServletDispatcherResult, which will see that the filter is in use and _not_ dispatch, since the filter is going to chain right after. This is the correct behavior. But if the result of the action executing is _different_ than the URL being request (ie: error.jsp), the ServletDispatcherResult does what it should (dispatch out to error.jsp) but the filter will still try to grab the original request to success.jsp. Thoughts? One way would be to make the WW 2.0 framework/config more rigid and to remove the ResultInterceptor stuff and specifically hard code the ServletDispatcher to doing the dispatching _in_ the servlet itself (problem solved, but then generic results aren't possible in WW, which includes chaining, and then we open up the door to possibly more hardcoding). Anyway, I'm outta here, let me know what you guys think. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 12:06 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? Patrick Lightbody wrote: snippetysnap What do you think? Rickard, would this work for you? Everyone else, would this work for YOU? ;) Works for me! :-) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem + solution?]
I found a possible way around this, but I'm not sure if it's a good idea or not :) What if the FilterDispatcher never actually makes a call to filterChain.doFilter()? This would get around the duplicate view request problem outlined below, but would require that the filter -must- be the last one applied or else you'll loose the application of filters further down the chain. I don't think this is too bad though, since we can just -clearly- document that the FilterDispatcher (if you want to use it) must be applied last. Thoughts? -Pat - Original Message - From: Patrick Lightbody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 1:33 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? [Small problem] Found one small problem with this approach (and it may just be that using the filter + the servlet at all times just can't always work perfectly): If you are using the filter and servlet and access success.jsp, the action will be invoked, then the ResultInterceptor will kick in, call ServletDispatcherResult, which will see that the filter is in use and _not_ dispatch, since the filter is going to chain right after. This is the correct behavior. But if the result of the action executing is _different_ than the URL being request (ie: error.jsp), the ServletDispatcherResult does what it should (dispatch out to error.jsp) but the filter will still try to grab the original request to success.jsp. Thoughts? One way would be to make the WW 2.0 framework/config more rigid and to remove the ResultInterceptor stuff and specifically hard code the ServletDispatcher to doing the dispatching _in_ the servlet itself (problem solved, but then generic results aren't possible in WW, which includes chaining, and then we open up the door to possibly more hardcoding). Anyway, I'm outta here, let me know what you guys think. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 12:06 AM Subject: Re: [OS-webwork] WebWork 2.0: FilterDispatcher? Patrick Lightbody wrote: snippetysnap What do you think? Rickard, would this work for you? Everyone else, would this work for YOU? ;) Works for me! :-) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
