Announcement Announcement Module
Collapse
No announcement yet.
No autowiring of simple types. why? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • No autowiring of simple types. why?

    I was trying something which is probably a bad idea: In a command line program, the Main class that loads the Spring application context (using ClassPathXmlApplicationContext), itself being dependency injected.

    ConfigurableApplicationContext cac = (ConfigurableApplicationContext) main.ctx;
    AutowireCapableBeanFactory bf = cac.getAutowireCapableBeanFactory();
    bf.autowireBeanProperties(main, AutowireCapableBeanFactory.AUTOWIRE_BY_NAME,false) ;

    System.out.println("name: " + main.getTestBean());
    System.out.println("title: " + main.getTitle());
    It works. The TestBean in the context is injected into the Application, but the title, a String "bean", is not. I was debugging why I could not autowire by name when a bean is just a String. But finally gave up and reread the Reference manual on this and found:

    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.)
    How is this a feature?

    ---- Josef

  • #2
    Hi Josef

    I was being a tad disingenuous there when I wrote that part of the reference documentation. It's not a feature, but rather a 'feature' (notice the use of quotes).

    I was not around at the beginning of Spring (having only seen the light in 2003), so I don't quite know the exact motivation for not allowing the autowiring of 'primitive' types. Juergen is away so we can't even ping him for the definitive answer

    If we can shoot-the-breeze (as it were), I daresay it's down to the fact that the typical configuration of a typical enterprise application will be replete with a potentially large number of instances of Classes, Strings, etc., the result of which kinda makes autowiring not quite as compelling as it is when used to wire up 'coarser' objects such as Hibernate SessionFactory instances, DAOs and suchlike; and hence the capability was removed.

    Another, perhaps dismissive, viewpoint (emphasis on the 'dismissive') is that maybe, perhaps, possibly the meta-motivation for doing so was to dissuade follks from using autowiring in the first place. Autowiring is 'nice' (notice the use of the quotes there), but if used injudiciously is A Bad Thing, especially on the scale of enterprise projects that I see when consulting. If I can be nosy, what exactly are you using autowiring for? Perhaps I can persuade you to consider using another mechanism

    If you disagree with this, you can always raise an issue on JIRA.

    Cheers
    Rick

    Comment


    • #3
      Rick:

      Thanks for response. I was just curious about the motivations. I agree, autowiring could be very troublesome.

      Other than this experiment I did, and for testing frameworks, I have not seen a big case for its use. So, I'm already disinclined to use it.


      --- Josef

      Comment

      Working...
      X