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

[Juergen H. <ju...@in...>]

Colin

>>I rather see it like this: If there is no compelling use case for
specifying
>>the fully qualified class name of the target filter instead of the bean
name
>>there, I'd like to only provide the option to specify the target bean name
>>(which makes the interaction easier to track and results in shorter
>>configuration).
>>
>>
>Well, I think the class name has some value for part of the same reason
>byType matching exists in the context. I mean it's not autowired in this
>casse, but it's still a simpler config sometimes. If you know there
>should be exactly one filter of that type (which is usually the case for
>most filters), then you can just put the classname. And if you ever
>refactor, the IDE will take care of fixing the name, etc. I'm not
>incredibly hung up on this, but it probably provides some value.

I think the main difference is that autowire-by-type determines the types to
match through *reflection*, with no need to specify the class name
explicitly. Specifying the target class name instead of the target bean name
in web.xml just does't feel appropriate to me.

I guess my main concern is that we don't support this for any other Filters
that we ship either: OpenSessionInViewFilter,
OpenPersistenceManagerInViewFilter, MultipartFilter all delegate to a
Spring-managed bean, to be found by name rather than by type. If we
introduce by-class lookup to any Filter, we would have to do this for all
these Filters, to stay consistent.

>I guess my main objection is that it just seems weird to be calling
>lifecycle methods you know don't do anything (or shouldn't do anything),
>if you know Spring is really managing the lifecycle. But I guess it
>doesn't hurt. This also means you can't make the Filter interface
>destroy() method the bean destroy method called by the bean container
>(since it would be called twice), but I guess that's not that big a deal.

OK, convinced. I have added a "targetFilterLifecycle" flag to
DelegatingFilterProxy, specifying whether the servlet container will control
the lifecycle of the target Filter bean. Default is false, similar to
Acegi's original FilterToBeanProxy.

Of course, the Spring bean container can never populate the
init(FilterConfig) method of a Filter bean. But admittedly, this often isn't
needed: that method can be considered an alternative to bean-style
initialization, not accessing the FilterConfig object at all.

Juergen