Re: [Springframework-developer] autowiring exclusion attribute

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

I _did_ create the initial Jira entry for this enhancement, so I'm 
biased, but I do think it does add value to be able to exclude some 
beans as autowire candidates. It does add an extra attribute, but at the 
same time, it can help reduce the surprise factor in autowiring, 
allowing autowiring to continue to be used in some cases where it might 
not, and I think that's a good thing generally.

Mark Vickers wrote:

>Hi Juergen, Seth,
>
>(repost - forgive the formatting trainwreck that was the last post)
>
>I'm aware that inner beans are not considered as autowirable candidates,
>but, there are some cases where I find that inner bean definitions cannot be
>used.
>
>For example:
>LazyInitTargetSource, PrototypeTargetSource -
>These are BeanFactoryBasedTargetSources which are supplied with bean names,
>not bean references.
>
>If I want to wrap a proxy around a LazyInitTargetSource, I don't see how I
>can do it without two bean definitions.
>
>There are some other cases where an inner bean definition should not be
>used:
>	ie:) I want an unproxied/unadvised bean for testing
>
>Or imagine this scenario:
>We have an RmiProxyFactoryBean, the target object of which we want to wrap
>additional behaviour around.  In 99/100 cases we want the proxied version of
>the bean (which we happily autowire into other beans), but in one key case
>we need to get at the unproxied version.  But, because its an inner bean
>def, its inaccessible.	
>
>In summary, the ability to tag the corner-case beans as non-candidates for
>autowiring will help where it is difficult, impossible or otherwise
>undesirable to use inner bean defs.
>
>I guess you could call them corner cases, but guess what, we're cornered ;)
>
>Regards,
>Mark
>
>-----Original Message-----
>From: Juergen Hoeller [mailto:ju...@in...]
>Sent: Thursday, July 07, 2005 7:02 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] autowiring exclusion attribute
>
>
>Hi Mark,
>
>I haven't given much thought to this yet. The question is whether there are
>enough good use cases for this.
>
>After all, there's always the option to override autowiring at the level of
>the bean that receives autowiring: You can always explicitly specify
>references for specific properties of constructor arguments there, which
>will override any autowiring that you configured for that bean.
>
>In general, I agree with Seth that inner bean definitions can get you quite
>far as well, in particular regarding proxy vs target. We're illustrating
>that configuration style in JPetStore, for example. Autowiring will always
>only consider the outer bean (the proxy) in such a scenario, never the inner
>bean (the target).
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Mark Vickers
>Sent: Wednesday, July 06, 2005 9:06 PM
>To: 'spr...@li...'
>Subject: [Springframework-developer] autowiring exclusion attribute
>
>Juergen et al,
>
>I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
>http://opensource.atlassian.com/projects/spring/browse/SPR-626
>
>Any chance of this making it into 1.3?
>A quick yea or nay would be appreciated - the presence/absence of this
>feature will greatly impact our development practices.
>
>Regards,
>Mark
>  
>