Spring Framework
  1. Spring Framework
  2. SPR-4524

Autowiring won't work when using scopes and targetClass auto proxying

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5.1
    • Fix Version/s: 2.5.6
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      java.lang.IllegalStateException: Annotation-specified bean name 'portalUserRequestData' for bean class [XXXX.PortalUserRequestData] conflicts with existing, non-compatible bean definition of same name and class [org.springframework.aop.scope.ScopedProxyFactoryBean]

      I've got a PortalUserRequestData bean declared as:
      @Scope( "request" )
      @Component

      This is then injected in another bean as following:

      @Autowired
      private PortalUserRequestData portalUserRequestData;

      and fails with the message above.

      it can be noted that if the same bean is declared in XML (with scope=) and set on the other bean in xml (with set property, and ref="portalUserRequestData").
      there's no problem - thus it's probably a bug in the spring core container.

        Issue Links

          Activity

          Hide
          Alex Gitelman added a comment -

          Here we go.

          ctx1.xml imports ctx2.xml and both scan the same package.

          Show
          Alex Gitelman added a comment - Here we go. ctx1.xml imports ctx2.xml and both scan the same package.
          Hide
          Alex Gitelman added a comment -

          Just in case - file is attached test case and maven pom to simulate the problem. Just run the build.

          Show
          Alex Gitelman added a comment - Just in case - file is attached test case and maven pom to simulate the problem. Just run the build.
          Hide
          Juergen Hoeller added a comment -

          This wasn't the same issue, actually, but rather a different one that sneaked in through the fix for the previous issue: We are comparing the source objects of bean definitions now, and those were accidentally set to null by the SourceExtractor in the XML namespace parsing.

          I've fixed this for 2.5.6, so all so such cases should work fine now. This will be available in tonight's 2.5.6 snapshot (http://static.springframework.org/downloads/nightly/snapshot-download.php?project=SPR). Please give it an early try and let me know whether it works for you...

          Juergen

          Show
          Juergen Hoeller added a comment - This wasn't the same issue, actually, but rather a different one that sneaked in through the fix for the previous issue: We are comparing the source objects of bean definitions now, and those were accidentally set to null by the SourceExtractor in the XML namespace parsing. I've fixed this for 2.5.6, so all so such cases should work fine now. This will be available in tonight's 2.5.6 snapshot ( http://static.springframework.org/downloads/nightly/snapshot-download.php?project=SPR ). Please give it an early try and let me know whether it works for you... Juergen
          Hide
          Alex Gitelman added a comment -

          I finally got around to try it with snapshot and it works.
          Thanks
          Alex

          Show
          Alex Gitelman added a comment - I finally got around to try it with snapshot and it works. Thanks Alex
          Hide
          François Le Droff added a comment -

          I hit the same bug when migration from spring-aop 2.5.2 to version 2.5.6
          I had to specify non overlapping packages to scan in my different application-context xml files (I did not have to do to that with version 2.5.2)

          Show
          François Le Droff added a comment - I hit the same bug when migration from spring-aop 2.5.2 to version 2.5.6 I had to specify non overlapping packages to scan in my different application-context xml files (I did not have to do to that with version 2.5.2)

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              David J. M. Karlsen
              Last updater:
              Sam Brannen
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 49 weeks, 4 days ago