Closed
Description
nigel magnay opened SPR-7582 and commented
We have an application that uses a fairly standard pattern to declare a proxy for a bean:
<bean id="AService" name="aService" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="target"><ref bean="AServiceTXN"/></property>
<property name="interceptorNames">
<list>
<value>Interceptor1</value>
<value>Interceptor2</value>
...
<value>InterceptorN</value>
</list>
</property>
</bean>
The instantiation order causes this bean to be being created in response to an unrelated autowiring request, e.g:
@Autowired(required=false)
List<SomeOther> someOthers;
Which is internally executing getBeanNamesForType()
.
This causes a chain of objects to be created, and the ProxyFactoryBean
for AService
to be called with getObject()
.
However, this getObject()
call is in advance of Spring having set the interceptorNames
. Thus the proxy is created, and the advisorChainInitialized
variable set to true
with no interceptor names.
There's several things here
- I don't see why spring is calling
getObject
on an uninitialized factory; it ought to have set the properties first. I don't believe there are circular dependencies here (since it is initiated by a request to find all instances of an unrelated class). I can remove the problem (for one bean, but this applies to many) by creating a derived type ofProxyFactoryBean
that sets the target andinterceptorNames
on construction... but this seems to be a nasty workaround as I'd have to set it for many, many beans. If it believes there to be a circular dependency I'd expect an exception. - If
setInterceptorNames
finds thatadvisorChainInitialized == true
, it ought to throw an exception, since it is clearly too late to influence the interception chain (so for example security interceptors mysteriously fail to work).
Affects: 2.5.6
Attachments:
- spring-SPR-7582-workaround.patch (1.71 kB)
Referenced from: pull request #1477
2 votes, 3 watchers