Announcement Announcement Module
Collapse
No announcement yet.
Autowiring support Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Autowiring support

    Hello,
    Any plans to support autowiring in Spring IDE? For the moment, the plugin complains about the absence of constructor with no arguments when I use autowire="constructor" and define a single constructor with arguments.

  • #2
    Re: Autowiring support

    Originally posted by ta
    Any plans to support autowiring in Spring IDE?
    No. I have no clue how to implement autowiring without instantiating the beans. And instantiating a bean factory's whole object graph is not feasable from within a simple validator running in Eclipse. Normally you need a runtime environment or mocks to do so, e.g. a respository for JNDI lookups or a JDBC connection pool for a DataSource.

    Originally posted by ta
    For the moment, the plugin complains about the absence of constructor with no arguments when I use autowire="constructor" and define a single constructor with arguments.
    In this case the validator should skip the no-arguments-constructor check. Please open a ticket for this issue via http://springide.org/project/newticket

    Cheers,
    Torsten

    Comment


    • #3
      Than you. done.
      http://springide.org/project/ticket/143

      Comment


      • #4
        Re: Autowiring support

        Originally posted by Torsten Juergeleit
        No. I have no clue how to implement autowiring without instantiating the beans.
        Is supprting autowire-by-name possible? Naively, it seems that it would be a matter of using reflection to identify setters on a bean, and comparing those against the previously parsed bean ids.

        Comment


        • #5
          Re: Autowiring support

          Originally posted by cepage
          Is supprting autowire-by-name possible? Naively, it seems that it would be a matter of using reflection to identify setters on a bean, and comparing those against the previously parsed bean ids.
          Using reflection from within Eclipse is not an option. We can't do any classloading-stuff like Class.forname() because we're living in a limited classloader provided by Eclipse without any "real" runtime environment.

          IMHO our only option is to use JDT's AST instead of reflection (this is already done by the BeansConfigValidator). But this means re-implementing the Spring's auto-wiring stuff. Here I don't know how complex this would be.

          I have to investigate. But currently I have no spare time left.

          Any volunteers?

          Cheers,
          Torsten

          Comment

          Working...
          X