[
https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43302#action_43302
]
Don Brown commented on WW-2479:
-------------------------------
Hmm...what if we did something like this:
@@ -142,7 +142,12 @@
Object bean;
try {
- bean = autoWiringFactory.autowire(clazz,
AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR, false);
+ if (autowireStrategy ==
AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR ||
+ autowireStrategy ==
AutowireCapableBeanFactory.AUTOWIRE_AUTODETECT) {
+ bean = autoWiringFactory.autowire(clazz,
AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR, false);
+ } else {
+ bean = super.buildBean(clazz, extraContext);
+ }
} catch (UnsatisfiedDependencyException e) {
// Fall back
bean = super.buildBean(clazz, extraContext);
Basically, we only try to autowire by constructor if that is enabled. Now, the
strategy is one that is explicitly defined in Struts config, ignoring any
configured in Spring, but that's a separate issue.
> 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
> Fix For: 2.1.x
>
>
> 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.
