Method postProcessBeanDefinitionRegistry is not called if the bean implements BeanDefinitionRegistryPostProcessor [SPR-9464]

[spring-projects-issues]

Simon Wong opened SPR-9464 and commented

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)

---

Affects: 3.1.1

Attachments:

• TestSpring31MyBatis.zip (10.58 kB)

Issue Links:

• BeanDefinitionRegistryPostProcessor registered via @Bean will not be invoked [SPR-7868] #12525 BeanDefinitionRegistryPostProcessor registered via @Bean will not be invoked ("duplicates")
• BeanFactoryPostProcessor breaks default post-processing of @Configuration classes [SPR-8269] #12917 BeanFactoryPostProcessor breaks default post-processing of @Configuration classes

Referenced from: commits spring-attic/spring-framework-issues@a1584d7

[spring-projects-issues]

Chris Beams commented

This issue duplicates #12525. Also see #12917 for history/background on MyBatis and its MapperScannerConfigurer becoming a BeanDefinitionRegistryPostProcessor

[spring-projects-issues]

Simon Wong commented

Hi Chris, I have read #12525 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 #12525?

[spring-projects-issues]

Chris Beams commented

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.

[spring-projects-issues]

Simon Wong commented

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

[spring-projects-issues]

Chris Beams commented

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.

[spring-projects-issues]

Simon Wong commented

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 #12525 and mentioned that even using @ImportResource within @Configuration still not working as expected?

[spring-projects-issues]

Chris Beams commented

Done.

[spring-projects-issues]

Eduardo Macarron commented

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?

[spring-projects-issues]

Eduardo Macarron commented

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