MapperScannerConfigurer can't work with AnnotationConfigApplicationContext

[GoogleCodeExporter]

As described here : 
https://jira.springsource.org/browse/SPR-7868?focusedCommentId=66078&page=com.at
lassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66078 :

This is a fundamental limitation of the @Configuration / @Bean approach. 
Because @Configuration classes are actually themselves processed by a 
BeanDefinitionRegistryPostProcessor, they cannot in turn register additional 
BeanDefinitionRegistryPostProcessors. See comment thread on SPR-9464 for 
further explanation, workarounds and suggestions specific to MyBatis.

The proposed way to do that is here : 
https://jira.springsource.org/browse/SPR-9464?focusedCommentId=79600&page=com.at
lassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-79600 :

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.

Original issue reported on code.google.com by brice.du...@gmail.com on 16 Oct 2012 at 6:05

[GoogleCodeExporter]

mybatis spring has ignored the postProcessBeanFactory  
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) 
{
}
in MapperScannerConfigurer (I don't why the author ingores that)

if you want to make it scanned as usual you should override that method 
with 

 public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
      postProcessBeanDefinitionRegistry((BeanDefinitionRegistry)beanFactory);
  }

and use mvn install to get a new jar.

Original comment by jerrysco...@gmail.com on 17 Oct 2012 at 2:51

[GoogleCodeExporter]

Actually I did the same thing, and for the moment it is working as expected, 
however it seems there is a reason why it's left blank; check issue 592. 
Eduardo is referencing an issue from SpringSource 
(https://jira.springsource.org/browse/SPR-8269) were they recommend to use 
'postProcessBeanDefinitionRegistry' for two main reasons : 
- as the MapperScannerConfigurer adds new bean definitions to the context, it 
should post process the registry
- using can break autowiring postProcessBeanFactory

As a reasonable but cheap workaround we can try 
/**
 * Comments to these issues, including the spring issue, etc
 * And false by default.
 */
private boolean usePostProcessFactoryBean = false;

public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) 
{
     if(usePostProcessFactoryBean) {
      processBeanDefinitionRegistry((BeanDefinitionRegistry)beanFactory);
     }
 }

/**
 * Keeeping current behaviour as default
 */
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry 
beanDefinitionRegistry) throws BeansException {
     if(usePostProcessFactoryBean == false) {
      processBeanDefinitionRegistry((BeanDefinitionRegistry)beanFactory);
     }
}

private void processBeanDefinitionRegistry(BeanDefinitionRegistry 
beanDefinitionRegistry) {
    // current code in "public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry beanDefinitionRegistry) throws BeansException"
}

Though I definitely think that creating an @EnableMyBatisMapperScanner would be 
a better option.

Original comment by brice.du...@gmail.com on 17 Oct 2012 at 12:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Absolutely. I fact, that was Chris Beans recommendation. 

@Enable* is the way to go but I have no idea about its internals, although 
having a look at ComponentScanAnnotationParser I feel it must be quite easy to 
do.

Can anybody help?

Original comment by eduardo.macarron on 3 Nov 2012 at 7:36

[GoogleCodeExporter]

Any update on this issue? I am stuck with this. Not able to run JUnits

Original comment by manik.ma...@gmail.com on 21 Dec 2012 at 7:27

[GoogleCodeExporter]

Hi guys,

Thanks to a contribution by Michael Lanyon we have an snapshot with an @Enable 
annotation.

Using it is quite simple, just this:
@Configuration
@EnableMapperScanning(basePackages = {"my.package"})
public class AppConfig {
}

Could you test the snapshot and post the results?

Original comment by eduardo.macarron on 9 Jan 2013 at 8:32

• Changed state: Accepted
• Added labels: Type-Feature, Priority-Low, Target-Release1.2.0
• Removed labels: Type-Defect, Priority-High

[GoogleCodeExporter]

The @Enable annotation has been committed in r5580.

Please run the snapshot and post your opinions. 

There is a working sample here:
http://mybatis.googlecode.com/svn/sub-projects/mybatis-spring/trunk/src/test/jav
a/org/mybatis/spring/sample/SampleEnableTest.java

Documentation is still pending.

Original comment by eduardo.macarron on 13 Jan 2013 at 6:51

• Changed state: Fixed

[GoogleCodeExporter]

If anyone is interested in a fully Java config example, there's one here: 
http://mybatis.googlecode.com/svn/sub-projects/mybatis-spring/trunk/src/test/jav
a/org/mybatis/spring/annotation/EnableMapperScanningTest.java and here: 
https://github.com/LanyonM/spring-grabbag/blob/master/src/main/java/org/lanyonm/
grabbag/config/DataConfig.java

Cheers,
Mike

Original comment by Lany...@gmail.com on 14 Jan 2013 at 4:44