SpringObjectFactory does not respect autowireStrategy
-----------------------------------------------------

                 Key: WW-2479
                 URL: https://issues.apache.org/struts/browse/WW-2479
             Project: Struts 2
          Issue Type: Bug
          Components: Plugin - Spring
    Affects Versions: 2.0.11
            Reporter: Bob Tiernay


SpringObjectFactory 's Object buildBean(Class clazz, Map extraContext) does not 
respect autowireStrategy as it first attempts to use 
AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR prior to using the default 
constructor.  If the target bean has a candidate constructor, this leads to 
autowire="byType" semantics on the constructor values. This is highly 
undesireable in most circumstances, not to mention inconsistent with the 
semantics of "struts.objectFactory.spring.autoWire" in struts.properties

I noticed this issue because I've been using the new @Autowired support in 
Spring 2.5.  One of the difficulties with @Autowired is determining a way to 
use a PropertyPlaceholderConfigurer to configure simple configuration values on 
the target bean.  One way to achieve this is to create a number of Integer / 
String beans configured by the PropertyPlaceholderConfigurer  in the 
application context, and inject those beans into the target bean.  However, 
creating a single String bean in one's application context will wreak havoc 
when AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR semantics are applied 
because of how common Strings are as constructor arguments.  This seems to be 
the case with Framework classes created by SpringObjectFactory. For instance, 
ServletActionRedirectResult has the following constructor:

ServletActionRedirectResult(String namespace, String actionName, String method)

If there is a String bean in applicationContext.xml, this bean will be 
constructed not with it's actually supplied arguments from the framework, but 
with the value of the applicationContext.xml String bean! This is obviously not 
good.

The same issue occurs with primative wrapper objects, and potentially any class.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to