We unfortunately are not using a 2.3 container. However, the other issue are things like if we want intercept all requests and determine if the user has a proper authentication key (not using j2ee security) and managing information the session(e.g. clearing certain information stored into the session when crossing config contexts). I think simply subclassing the RequestProcessor can lead to unwieldy and hard to maintain code. That's why I was thinking about adding a Preprocessor delegate into the RequestProcessor. More configuration...less code change :)
-m -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 5:41 PM To: [EMAIL PROTECTED] Subject: Re: proposal to extend RequestProcessor Why do you want ServletFilter capability in the struts ActionServlet (other than not using a servlet 2.3 compliant container)? I personally think this is best left in the ServletFilter realm and people using older containers (myself included) can subclass RequestProcessor. In general, I don't think it's wise to duplicate java standard functionality in struts, especially when struts already provides an easy extension mechanism. Dave >From: "Michael C. Han" <[EMAIL PROTECTED]> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >To: "Struts List \(E-mail\)" <[EMAIL PROTECTED]> >Subject: proposal to extend RequestProcessor >Date: Fri, 20 Sep 2002 11:27:30 -0400 > >Currently, in order to have preprocessing of a request, we must extend >RequestProcessor each time. I think it will be beneficial to create >mechanism similar to the PlugIns. This'll give us the ability to perform >operations like authentication checks and etc. It'll give us a >ServletFilter like capability within the ActionServlet. > >thoughts? > >-m > > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
