Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Colin S. <col...@ex...>]

Juergen Hoeller wrote:

>Yes, that's what I've been thinking of too...
>
>I'd prefer to reimplement FilterToBeanProxy as DelegatingFilterProxy in
>org.springframework.web.filter, though, in a stripped-down fashion: deriving
>from GenericFilterBean, offering a "targetBeanName" bean property,
>defaulting to the filter name as target bean name.
>
>The name "DelegatingFilterProxy" is analogous to our "DelegatingActionProxy"
>in org.springframework.web.struts. We also have a "DelegatingDataSource",
>"DelegatingMessageSource", etc.
>
>I'm not sure whether we should keep the class-based delegate lookup. If we
>do, I would introduce a "targetBeanClass" property, with a strict check - if
>there isn't exactly one matching bean in the context, we'll fail. However, I
>prefer lookup by bean name, in particular if we simply use the filter name
>as target bean name.
>  
>
I would keep it if it doesn't get in the way of the bean name default 
strategy (which it doesn't seem to), as it's potentially useful to some 
people.

>Regarding the lifecycle concerns: init and destroy should probably always be
>delegated to the target Filter bean instance. If the target Filter uses bean
>lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
>anyway. So I guess we don't really need an explicit config setting for this.
>  
>
I'm not sure I agree about this. If the methods are always delegated, 
then it somewhat precludes for example somebody subclassign an existing 
filter to try to use that codebase as-is. If the init/destroy doesn't 
happen by default, then the filter class in question can decide when/if 
to call the Filter interface lifecycle methods...

>I've kept the lazy initialization of the delegate Filter, which was
>obviously introduced for the case where the Filter proxy gets started before
>the root WebApplicationContext (which can happen with ContextLoaderServlet).
>
>I've just prototyped this; if we agree on the approach, I could document it
>and commit it quickly. I guess the main question is whether the above
>DelegatingFilterProxy suggestion is sufficient for Acegi's needs. Could it
>replace the current FilterToBeanProxy, as used by Acegi?
>
>As a side note: For completeness' sake, we could also add a
>DelegatingServletProxy to org.springframework.web.servlet, providing similar
>delegation to a target Servlet bean instance. However, that would probably
>be a rather academic exercise.
>
>Juergen
>
>  
>

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com