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

1. 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 of ProxyFactoryBean that sets the target and interceptorNames 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.
2. If setInterceptorNames finds that advisorChainInitialized == 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