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

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

Juergen Hoeller wrote:

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

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


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