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

  • Autowire newbie problem

    Hi,

    I have a setup with a few ordinary beans and some hibernate JPA stuff. This seems to work.

    Then there is a @Component annotated bean being loaded by <component-scan>. This bean has an autowired field of a type that has a single bean in the same context.

    But still I get:

    Code:
    Context initialization failed
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'helloWorld': Autowiring of fields failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: protected dk.smaas.erp.AccountDAO dk.smaas.rest.HelloWorld.dao; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [dk.smaas.erp.AccountDAO] is defined: Unsatisfied dependency of type [class dk.smaas.erp.AccountDAO]: expected at least 1 matching bean
    In fact I find it even more surprising that I get this log entry before the above one:

    Code:
    Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@90ff2a1: defining beans [accountDAO,dataSource, etc...]
    But perhaps this is just a by-product caused by the autowiring failure?

    Thanks,

    -dennis

  • #2
    Field Modifier Wrong

    I don't know for sure but I think the first one is because you're trying to autowire a protected field. Someone correct me if I'm wrong here, but I think you have to have the field be public. I wouldn't read too much into the second one coming out first. Logging can get buffered weird and come out in a funny order.

    Comment


    • #3
      Looking at the NoSuchBeanDefinitionException, it looks like there is a problem in the instantiation of your AccountDAO in the first place, so there is never an instance of it to inject/autowire into any other beans.

      Is there anything else on the stack trace that might be telling of AccountDAO's failure to instantiate?

      Comment


      • #4
        Originally posted by jamestastic View Post
        Looking at the NoSuchBeanDefinitionException, it looks like there is a problem in the instantiation of your AccountDAO in the first place, so there is never an instance of it to inject/autowire into any other beans.

        Is there anything else on the stack trace that might be telling of AccountDAO's failure to instantiate?

        That's what I thought. Actually it is being instantiated (System.out in constructor). And there are no errors or warnings in the log that I can find.

        Not sure what it's telling me, but my IDE (intellij) actually also sees the problem and thinks there is no bean implementing the AccountDAO class in question.

        Hmm. Pretty frustrating! But thanks for helping out

        -dennis

        Comment


        • #5
          This is a shot in the dark, but I was noticing the same error in a project I was working on, in which it looked like an object was not being instantiated but in actuality it was being instantiated. I was trying to get an @Around advice to work, and ended up having to change my <aop:aspectj-autoproxy /> to <aop:aspectj-autoproxy proxy-target-class="true" /> to force CGLIB proxying.

          I'm honestly not sure why it fixed the problem, as I'm still learning the ins and outs of proxying, but maybe it will hint at something you are running into.

          Comment


          • #6
            Originally posted by jamestastic View Post
            This is a shot in the dark, but I was noticing the same error in a project I was working on, in which it looked like an object was not being instantiated but in actuality it was being instantiated. I was trying to get an @Around advice to work, and ended up having to change my <aop:aspectj-autoproxy /> to <aop:aspectj-autoproxy proxy-target-class="true" /> to force CGLIB proxying.
            Thanks, that solved the problem. But enabling trace logging, I got the hunch that the bean created in the context is actually of a derived proxy-type, and thus not assignable.

            I solved it with proxy-target-class="true" on my <tx:annotation-driven> element.

            Not exactly an easy problem to figure out, I must say

            -dennis

            Comment


            • #7
              Same problem, same solution

              Hello.

              Many thanks. I had similar problem. After adding
              Code:
              proxy-target-class="true"
              to my tx:annotation-driven declaration it was solved. What I don't understand is that everything was working fine when I was only injecting one bean. But when adding another I had the nosuchbean exception even if looking at the spring trace, the bean was well instanciated...
              I would be interested to know more about that subject...

              Comment


              • #8
                great

                i find my answer here!

                Comment


                • #9
                  Solved my problem too!

                  The problem seems to occur because aspectj puts a proxy on the classes, and so suddenly the classes can't be recognised for autowiring. Very annoying.

                  Thanks for the advice!

                  Comment


                  • #10
                    Originally posted by Anarchofascist View Post
                    The problem seems to occur because aspectj puts a proxy on the classes, and so suddenly the classes can't be recognised for autowiring. Very annoying.

                    Thanks for the advice!
                    Aspectj has nothing to do with that. This is spring aop proxying mechanism selection - very popular problem for the new spring aop users.

                    Comment

                    Working...
                    X