[
https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Don Brown updated WW-2479:
--------------------------
Issue Type: Improvement (was: Bug)
Changing to improvement since it wasn't respecting the setting by design
> SpringObjectFactory does not respect autowireStrategy
> -----------------------------------------------------
>
> Key: WW-2479
> URL: https://issues.apache.org/struts/browse/WW-2479
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Spring
> Affects Versions: 2.0.11
> Reporter: Bob Tiernay
> Assignee: Don Brown
> Fix For: 2.1.3
>
>
> 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.
