On 8/21/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
On 8/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Filters are executed before the servlet gains control ... which means before > the JSF FacesServlet has had a chance to set up the FacesContext and such > for a JSF request. Therefore, a filter won't be able to use the managed > beans APIs to create new beans. It can, however, have access to any > attributes that have already been created, using standard Servlet API > techniques (request.getAttribute() for request scope, > request.getSession().getAttribute() > for session scope, etc.). You can follow the process detailed at this URL to create a FacesContext in your servlet filter. I don't know if it's sufficient to set up the environment needed for creating managed beans off the top of my head. http://www.thoughtsabout.net/blog/archives/000033.html
I sure wouldn't go that way ... FacesServlet is still going to do all this work again when the request actually gets there. Anything your filter does is potentially thrown away when that happens, depending on the precise details of your JSF implementation. The right way to integrate stuff like authentication and authorization into JSF is to use a phase listener. The challenge will be in how to adapt existing technologies that use a servlet Filter to this approach. Ideally, the filter provider would have segregated the actual logic used to perform its tasks into reusable business logic chunks. Yah, right, dream on :-). The more likely scenario is we'll have to fake out the filter and call an instance of it ourselves, somewhere in the JSF request processing lifecycle, rather than having the container do it. A side benefit of that, of course, is you wouldn't necessarily have to configure the filter in your web.xmlfile. Craig
