Announcement Announcement Module
Collapse
No announcement yet.
AutoWire by type issue Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • AutoWire by type issue

    Hi guys,
    Sorry to bother you again with my little problems ... but i think I found an issue with autowiring by type.
    I leave it up to you to decide whether it is a bug or a misunderstanding :

    I have configured an object for which one property is injected through declaration (using a constant / FieldRetrievingFactoryObject).
    So far, it works.
    The problem is that I have a second property in my object with the same type that also receives the constant value !

    Consider this object definition :
    Code:
    	<object id="object" class="org.ozb.SimpleObject" scope="singleton" autowire="byType">
    		<property name="value1">
    			<util:constant static-field="org.ozb.Constants.SOMEVALUE"/>
    		</property>
    	</object>
    And the SimpleObject class :
    Code:
    	public class SimpleObject implements IInitializingObject {
    		private static var logger:ILogger = logger = LoggerFactory.getClassLogger(SimpleObject);
    		
    		public var value1:String;
    		public var value2:String;
    		
    		public function SimpleObject() {
    		}
    		
    		public function afterPropertiesSet():void {
    			logger.debug("value1 = [{0}]", value1); 
    			logger.debug("value2 = [{0}]", value2); 
    		}
    	}
    When I configure a context using these definitions I get the following log traces :

    Tue Apr 20 11:07:04 GMT+0200 2010 DEBUG - org.ozb.SimpleObject - value1 = [someValue]
    Tue Apr 20 11:07:04 GMT+0200 2010 DEBUG - org.ozb.SimpleObject - value2 = [someValue]


    And this is not the expected result. I expect value1 to be "someValue" but value2 to be untouched (thus null). Am I right ?
    If I ever turn autowiring off, then it works.

    I have a small eclipse project at your disposal if you ever need some working code.

    I'm working with a SAS version from yesterday (trunk)

    Thanks,
    Alain

  • #2
    by design

    Hi Alain,

    this behavior is completely by design and documented as such. Autowiring (by type in this case) will autowire *any* properties that have not been explicitly configured in the object definition.
    So, in your case the value2 property is autowired by type, which means an object definition of type string will be looked up in the config, i.e. the util:constant.
    Currently its not possible to set the autowire mode on a property (only on an object, so that sets it for all properties), if you feel this functionality is needed then feel free to add a feature request in JIRA:
    http://jira.springframework.org/brow...ACTIONSCRIPTAS

    And don't worry about 'bothering' us with your little problems, our goal is to get you up to speed with the framework as soon as possible, so keep those questions and comments coming

    cheers,

    Roland

    Comment


    • #3
      Roland,
      I have read somewhere in the documentation:
      "Please also note that it is not currently possible to autowire so-called simple properties such as primitives, Strings, and Classes (and arrays of such simple properties). (This is by-design and should be considered a feature.)"

      So, If I stick to this statement, I'm expecting my second porperty (String) to be untouched, no ?
      Is this statement still relevant ?

      Also, I noticed that If I define another String constant in my object definition (for another object), the issue disappears. I guess this is due to the fact the the IoC container detects more than one potential candidate for the wiring and can't decide which one is suitable.

      Comment


      • #4
        oooops

        Hey Alain,

        I take back my previous statement and hang my head in shame, you are completely right, this behaviour does not reflect the documentation.
        I will take this up with the person who wrote the autowiring functionality to see if this behavior was intentional or not.
        So, either the documentation will be changed, or the autowiring code

        Anyways, thanks for bringing up this up

        cheers,

        Roland

        Comment

        Working...
        X