Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-9464

Method postProcessBeanDefinitionRegistry is not called if the bean implements BeanDefinitionRegistryPostProcessor

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: 3.1.1
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      The issue could be revealed if MyBatis for Spring is used.

      MapperScannerConfigurer in MyBatis for Spring v1.1.0+ has changed to use BeanDefinitionRegistryPostProcessor instead of BeanFactoryPostProcessor as of v1.0.x for scanning MyBatis mapper resources.

      The case is postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) is not called by Spring container if MapperScannerConfigurer is created through @Bean (but it will be called if the bean is created through XML configuration)

        Issue Links

          Activity

          Hide
          cbeams Chris Beams added a comment -

          This issue duplicates SPR-7868. Also see SPR-8269 for history/background on MyBatis and its MapperScannerConfigurer becoming a BeanDefinitionRegistryPostProcessor

          Show
          cbeams Chris Beams added a comment - This issue duplicates SPR-7868 . Also see SPR-8269 for history/background on MyBatis and its MapperScannerConfigurer becoming a BeanDefinitionRegistryPostProcessor
          Hide
          simonwg Simon Wong added a comment -

          Hi Chris, I have read SPR-7868 before. Hence, I put the MapperScannerConfigurer in the XML (but the XML is imported by a @Configuration class with @ImportResource). Does it still suffer from the problem in SPR-7868?

          Show
          simonwg Simon Wong added a comment - Hi Chris, I have read SPR-7868 before. Hence, I put the MapperScannerConfigurer in the XML (but the XML is imported by a @Configuration class with @ImportResource). Does it still suffer from the problem in SPR-7868 ?
          Hide
          cbeams Chris Beams added a comment -

          Hi Simon, I would have to double-check to be certain. It sounds like you have such a setup right now. Is it simple enough for you to try this out locally and confirm whether works as expected with an XML file introduced via @ImportResource? Thanks.

          Show
          cbeams Chris Beams added a comment - Hi Simon, I would have to double-check to be certain. It sounds like you have such a setup right now. Is it simple enough for you to try this out locally and confirm whether works as expected with an XML file introduced via @ImportResource ? Thanks.
          Hide
          simonwg Simon Wong added a comment -

          I have created a testing program
          mvn exec:java -Dexec.mainClass="com.mycompany.testspring31mybatis.cmd.AppTest"

          If the MyBatis MapperFactoryBean is used directly (uncomment them in applicationContext-dao.xml), everything will works fine.

          The @ImportResource is used in com.mycompany.testspring31mybatis.config.spring.AppConfig

          Show
          simonwg Simon Wong added a comment - I have created a testing program mvn exec:java -Dexec.mainClass="com.mycompany.testspring31mybatis.cmd.AppTest" If the MyBatis MapperFactoryBean is used directly (uncomment them in applicationContext-dao.xml), everything will works fine. The @ImportResource is used in com.mycompany.testspring31mybatis.config.spring.AppConfig
          Hide
          cbeams Chris Beams added a comment -

          Simon,

          Thanks for the attached project. I've reworked this and checked it into the spring-framework-issues project with this commit:

          https://github.com/SpringSource/spring-framework-issues/commit/a1584d7aa1906ab06ffe0dc8161c187647c8f6cc

          I would recommend checking that out and taking a look at it. You'll see that I've set up an xml_centric approach and a java_centric approach. When the container is bootstrapped via AnnotationConfigApplicationContext, it is simply not possible for MapperScannerConfigurer to do its job correctly. This is a fundamental limitation that we won't change. When the container is bootstrapped via GenericXmlApplicationContext, MapperScannerConfigurer works just fine.

          The problem is that MapperScannerConfigurer needs to perform additional registration of beans via a classpath scanning process. Implementing BeanDefinitionRegistryPostProcessor works well enough when bootstrapping via XML, but as you've seen, not with @Configuration. As of Spring 3.1, the @Enable* and @ComponentScan annotations are the answer to introducing this kind of support in the @Configuration world. For example, @ComponentScan performs scanning and registration very similar to that which MapperScannerConfigurer does.

          I would recommend reaching out to the MyBatis developers and seeing if they're interested in developing an @Enable*-style annotation that performs the same work as MapperScannerConfigurer.

          Show
          cbeams Chris Beams added a comment - Simon, Thanks for the attached project. I've reworked this and checked it into the spring-framework-issues project with this commit: https://github.com/SpringSource/spring-framework-issues/commit/a1584d7aa1906ab06ffe0dc8161c187647c8f6cc I would recommend checking that out and taking a look at it. You'll see that I've set up an xml_centric approach and a java_centric approach. When the container is bootstrapped via AnnotationConfigApplicationContext , it is simply not possible for MapperScannerConfigurer to do its job correctly. This is a fundamental limitation that we won't change. When the container is bootstrapped via GenericXmlApplicationContext , MapperScannerConfigurer works just fine. The problem is that MapperScannerConfigurer needs to perform additional registration of beans via a classpath scanning process. Implementing BeanDefinitionRegistryPostProcessor works well enough when bootstrapping via XML, but as you've seen, not with @Configuration . As of Spring 3.1, the @Enable * and @ComponentScan annotations are the answer to introducing this kind of support in the @Configuration world. For example, @ComponentScan performs scanning and registration very similar to that which MapperScannerConfigurer does. I would recommend reaching out to the MyBatis developers and seeing if they're interested in developing an @Enable *-style annotation that performs the same work as MapperScannerConfigurer .
          Hide
          simonwg Simon Wong added a comment -

          Chris, thanks for your advice. I think the @Enable* style would works the best for such case.

          In addition, could you please kindly revise the comment in SPR-7868 and mentioned that even using @ImportResource within @Configuration still not working as expected?

          Show
          simonwg Simon Wong added a comment - Chris, thanks for your advice. I think the @Enable* style would works the best for such case. In addition, could you please kindly revise the comment in SPR-7868 and mentioned that even using @ImportResource within @Configuration still not working as expected?
          Hide
          cbeams Chris Beams added a comment -

          Done.

          Show
          cbeams Chris Beams added a comment - Done.
          Hide
          emacarron Eduardo Macarron added a comment - - edited

          I have just got to this issue while after having a look at one of our issues:
          http://code.google.com/p/mybatis/issues/detail?id=694

          The MapperScanner is by far the most problemmatic class of MyBatis Spring integration

          We should indeed add that @Enable*-style annotation but unfortunately I am quite unfamiliar with 3.1 features. Having a look at the code I can see a new ComponentScanAnnotationParser. It looks quite similar to our scanner indeed.

          Is there any doc (or javadoc) that explains how to register a new @Enable* annotation and its parser?

          Show
          emacarron Eduardo Macarron added a comment - - edited I have just got to this issue while after having a look at one of our issues: http://code.google.com/p/mybatis/issues/detail?id=694 The MapperScanner is by far the most problemmatic class of MyBatis Spring integration We should indeed add that @Enable*-style annotation but unfortunately I am quite unfamiliar with 3.1 features. Having a look at the code I can see a new ComponentScanAnnotationParser. It looks quite similar to our scanner indeed. Is there any doc (or javadoc) that explains how to register a new @Enable* annotation and its parser?
          Hide
          emacarron Eduardo Macarron added a comment -

          Hi guys,

          Thanks to Mike Lanyon we will provide a new @Enable* annotation in MyBatis-Spring 1.2.0 as Chris suggested.

          Please refer to the doc:
          http://www.mybatis.org/spring/mappers.html#scan

          Thank you

          Show
          emacarron Eduardo Macarron added a comment - Hi guys, Thanks to Mike Lanyon we will provide a new @Enable* annotation in MyBatis-Spring 1.2.0 as Chris suggested. Please refer to the doc: http://www.mybatis.org/spring/mappers.html#scan Thank you

            People

            • Assignee:
              cbeams Chris Beams
              Reporter:
              simonwg Simon Wong
              Last updater:
              Eduardo Macarron
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 44 weeks, 1 day ago