[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:
Duplicate
duplicates SPR-7868 BeanDefinitionRegistryPostProcessor r... Resolved
Relate
is related to SPR-8269 BeanFactoryPostProcessor breaks defau... Closed
Days since last comment: 4 years, 36 weeks, 1 day ago
Last commented by a User: true
Last updater: Eduardo Macarron

 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)



 Comments   
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 ]

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.

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 ]

Done.

Comment by Eduardo Macarron [ 03/Nov/12 ]

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?

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:
http://www.mybatis.org/spring/mappers.html#scan

Thank you

Generated at Sun Sep 24 05:01:37 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.