That's weird... I actually had a part in my reply at the end that said something like "this should work until some code after the filter tries to access session" :)
Yep, absolutely, if there's a possibility of that then the wrapper is definitely the way to go. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Wed, November 9, 2005 2:24 pm, Brian Moseley said: > Frank W. Zammetti wrote: >> I can't think of any drawbacks to the filter, and tha's what I would >> have >> suggested. Although, it probably doesn't even have to be as complicated >> as a wrapper... simply check for an existing session for the paths you >> do >> want a session created for, and if none is present go ahead and create >> it. >> I *think* that would do the trick. > > well, i'm concerned about code executing further down the filter chain > that calls request.getSession(). i don't own all of the code that i'm > running :) > > that's why i thought of the wrapper. i can intercept calls to > getSession() and always return null for the requests that should never > get sessions, letting the calls through for the requests to the html ui. > > thanks for the feedback! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
