[
https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Don Brown resolved WW-2479.
---------------------------
Resolution: Fixed
Turned out to be a bit more complicated, so basically now we have a new
property:
struts.objectFactory.spring.autoWire.alwaysRespect
that can be set to true or false. The default behavior, false, tries to guess
the best autowire strategy for the situation. True will force the object
factory to always use the configured strategy.
> 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
> 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.
