[
https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44560#action_44560
]
Bob Tiernay commented on WW-2479:
---------------------------------
For completeness, I must explain how this issue can be avoided for the original
problem cited:
In applicationContext.xml:
<bean id="stringBean" class="java.lang.String" autowire-candidate="false">
<constructor-arg value="${stringBean}"/>
</bean>
In component:
@Resource(name = "stringBean") private String stringBean;
In this way, stringBean will never be a candidate for classical "autowiring",
but still can be autowired using Spring's support for @Resource
See
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-resource-annotation
and the tip in
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-autowired-annotation-qualifiers
for details
> 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.
