Re: [Springframework-developer] Let's add Acegi-SEcurity's FilterToBeanProxy directly to Spring

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

Understood, although even if people forget to set the filter beans to 
prototype, there will not be an issue with the fact that they are 
singletons unless the user points two or more filter proxies to the same 
actual filter bean. As long as the lifecycle issues are documented I 
think it works pretty well, and is _much_ better than having filters 
which can't access the main config at all, or the other type of code we 
did before where the filter would manually look for named beans/values 
in the context, basically subverting IOC.

I'm open to other suggestions. One possibility I can think of now, now 
that you'vd added AutowireCapableBeanFactory.autowireBeanProperties, is 
for the filter itself to just look up the beanfactory, and call 
autowireBeanProperties, passing itself. I'm not so sure this is 
necessarilly cleaner than the existing FilterToBeanProxy and telling 
people to use PrototypeBeans though. Certainly it would make testing the 
filter a little bit harder, since it now expects to do this call into 
the BeanFactory to configure itself.

Anyways, no need to figure this out for tomorrow, as I said...

Colin


jürgen höller [werk3AT] wrote:

>It feels a bit odd to have a Spring-managed bean with an init(FilterConfig) method that gets called after its Spring initialization (bean property population, InitializingBean) by a J2EE-managed Filter proxy.
>
>The Spring context should be fully responsible for the lifecycle of its beans. This means that no caller of getBean should call an initializing method on a returned singleton instance...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Monday, September 27, 2004 7:28 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Let's add Acegi-SEcurity's
>FilterToBeanProxy directly to Spring
>
>
>I don't see that much choice in the matter, since the lifecycle of the 
>Filter is clearly defined. Really it lives as a subset of the lifecycle 
>of the webapp and associated appcontext.
>
>But I have no problem with delaying. Anybody that really needs it can 
>still use it by linking to Acegi, or ripping it out of the latter...
>
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Colin,
>>
>>Actually, I'd prefer to defer this till 1.1.2.
>>
>>There are a couple of design issues to discuss there, for example initialization of a javax.servlet.Filter bean in a Spring context: pass through the FilterConfig there from the filter proxy in web.xml? Who really drives the lifecycle of the target bean then?
>>
>>Anyway, please let's not add this on such short notice...
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Colin Sampaleanu
>>Sent: Monday, September 27, 2004 5:46 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] Let's add Acegi-SEcurity's
>>FilterToBeanProxy directly to Spring
>>
>>
>>For about 2-3 months I've been meaning to but kept forgetting to add the 
>>Acegi-Security project's FilterToBeanProxy to Spring itself, since it's 
>>very useful for anybody doing filter-based stuff with Spring. Anybody 
>>mind if I add it in for 1.1.1, even at this late stage?
>> 
>>http://www.jdocs.org/acegi/0.6/api/net/sf/acegisecurity/util/FilterToBeanProxy.html
>>
>>Both Ben and I originally worked on it. It's obviously working and well 
>>tested.
>>    
>>