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

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

Colin,

>>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.

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).

>>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'm not sure if I understand that use case. Subclassing a Filter is
certainly possible, and if someone defines a DelegatingFilterProxy for that
class, I would expect the Filter lifecycle to always be called there, as the
target *is* a Filter. If someone wants to suppress those Filter.init/destroy
calls, there's always the option to override those methods with empty
implementations.

Alternatively, any existing Filter can be held as a delegate within some
wrapper class, whether exposing the Filter interface or not. That allows to
have full control over the lifecycle, only calling stuff on the delegate
that you really want to call. I consider this preferable to subclassing an
existing Filter if you don't want to inherit the existing Filter's lifecycle
behavior.

Juergen