[SPR-9464] Method postProcessBeanDefinitionRegistry is not called if the bean implements BeanDefinitionRegistryPostProcessor Created: 03/Jun/12  Updated: 18/Jan/13  Resolved: 04/Jun/12

Status: Resolved
Project: Spring Framework
Component/s: Core
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Simon Wong Assignee: Chris Beams
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive TestSpring31MyBatis.zip    
Issue Links:
duplicates SPR-7868 BeanDefinitionRegistryPostProcessor r... Resolved
is related to SPR-8269 BeanFactoryPostProcessor breaks defau... Closed
Days since last comment: 5 years, 26 weeks, 5 days ago
Last commented by a User: true
Last updater: Eduardo Macarron


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)

Comment by Chris Beams [ 04/Jun/12 ]

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

Comment by Simon Wong [ 04/Jun/12 ]

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?

Comment by Chris Beams [ 04/Jun/12 ]

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.

Comment by Simon Wong [ 05/Jun/12 ]

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

Comment by Chris Beams [ 05/Jun/12 ]


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


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.

Comment by Simon Wong [ 05/Jun/12 ]

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?

Comment by Chris Beams [ 05/Jun/12 ]


Comment by Eduardo Macarron [ 03/Nov/12 ]

I have just got to this issue while after having a look at one of our issues:

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?

Comment by Eduardo Macarron [ 18/Jan/13 ]

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:

Thank you

Generated at Thu Jul 19 13:30:31 UTC 2018 using JIRA 7.9.0#79000-sha1:3ca552e944c2fe83b21589bc06f155b9b428cc2b.