[jira] Created: (WW-2479) SpringObjectFactory does not respect autowireStrategy

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.

    [ 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.

     [ https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown updated WW-2479:
--------------------------

    Fix Version/s: 2.1.x
         Assignee: Don Brown

> 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.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.

     [ https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown updated WW-2479:
--------------------------

    Fix Version/s:     (was: 2.1.x)
                   2.1.3

> 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.

     [ 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.

     [ 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.

    [ https://issues.apache.org/struts/browse/WW-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44559#action_44559 ]

Brad Cupit commented on WW-2479:
--------------------------------

any chance of a backport to 2.0.x? I looked at the patches and there doesn't seem to be anything 2.1 specific in them, so I think the code would 'just work'.

> 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.

    [ 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.