auto-configuration and config location conflict.

[jcbvm]

Currently I've an issue with setting up my project.

When I set the config property in my application.properties, MybatisAutoConfiguration still scans the project for possible mappers, causing all my interfaces in that package becoming a mapper file.

When debugging, I see the config check being done after the auto configuration is scanning my package. This seems like a bug to me.

[eddumelendez]

Hi @jcbvm are you talking about this?

/cc @emacarron

[jcbvm]

@eddumelendez I'm talking about the AutoConfiguredMapperScannerRegistrar class in the class MybatisAutoConfiguration. The method registerBeanDefinitions is automatically scanning the base package. Not sure if this is intended, it seems so, because the documentation of the MapperScannerRegistrarNotFoundConfiguration class says:

"If it is not used, however, then this will bring in a bean registrar and automatically register components based on the same component-scanning path as Spring Boot itself."

My question is why it is by default scanning the package if the mappers are hard coded in the config file.

[eddumelendez]

It is working as spring-boot itself, if you are working with jpa in spring-boot yo don't need to put @Repository in your repositories classes, spring-boot does for you. The same happen with mybatis-spring-boot. The difference is, this project provided support for xml and java config. And as you can see there are some combinations that doesn't work as expected. I do not know if we can cover each case but, at the beginning, we add xml support to help people in the transition.

We can solve this removing the xml support :)
I will take a look with some ideas in my mind but take into account that now xml and java config will be working together in the next version.

Thanks

[jcbvm]

Thanks, for now I will move out any interface from the spring boot application package, so it will not get picked up as a mapper file.

[emacarron]

Hi,

@jcbvm If you add you mapper files using the mybatis-config.xml file, MyBatis will know about the mappers but spring don't. You need that your mappers are scanned so they can be injected afterwards. When using Spring we expect that mappers become spring beans and scanning is the heart of spring boot :)

I am not familiar with spring boot JPA. I will take a look to have a better opinion about this topic, but it indeed looks like a bug that all the interfaces in a project are registered as mappers.

You can bypass this by adding a @MapperScan annotation that lets you specify lots of filters.

But honestly I do not like to mix the usage of @MapperScan with spring boot. I would prefer to specify everyting in the application.properties. The AutoConfiguredMapperScannerRegistrar can take lots of parameters to make a finer search like for example the base package. This can be achieved easily by porting code from @MapperScan (MapperScannerRegistrar).

If you don't mind lets keep ths issue open because it is worth having a discussion about how this feature works.

[emacarron]

Hi again,

Does anybody know how can we read the MyBatisProperties bean in AutoConfiguredMapperScannerRegistrar???

[kazuki43zoo]

@emacarron I don't know ...
Can use the MapperScannerConfigurer instead of ?

[emacarron]

I don't think so. The registrar is the right bean to provide addional beans to a @configuration object. But looks like when it is executed the MyBatisProperties bean has not yet been created. I tried to get the object out of the beanFactory but it is not yet there :(

BTW I have just had a fast look at spring-boot-starter-data-jpa. Looks like by default it searches for classes that implements the interface Repository or are annotated with @RepositoryDefinition so seems that it won't get all the interfaces in the project but just the right ones.

See https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/repository/config/RepositoryComponentProvider.java#L71

super.addIncludeFilter(new InterfaceTypeFilter(Repository.class));
super.addIncludeFilter(new AnnotationTypeFilter(RepositoryDefinition.class, true, true));

Unfortunately MyBatis mappers are not marked (by design) so a good idea would be for example to search with a pattern like basepackage + "/**/mapper" so mappers are expected to be inside a package called whatever/mappers. The problem now is that this will break existing code. But I wount care too much about that given the project has just born.

[emacarron]

Have a look at this, what do you think?

emacarron@e4a2c4b

[kazuki43zoo]

Can get property value via Environment instead of type-safe properties using EnvironmentAware ?

For example:

public static class AutoConfiguredMapperScannerRegistrar implements BeanFactoryAware,
        ImportBeanDefinitionRegistrar, ResourceLoaderAware , EnvironmentAware {
    // ...
    private Environment environment;
    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }
    // ...
    @Override
    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata,
            BeanDefinitionRegistry registry) {

        ClassPathMapperScanner scanner = new ClassPathMapperScanner(registry);

        try {
            String[] mapperPackages = StringUtils.tokenizeToStringArray(environment.getProperty("mybatis.mapper-packages"),
                    ConfigurableApplicationContext.CONFIG_LOCATION_DELIMITERS);
            if(mapperPackages == null || mapperPackages.length == 0) {
                List<String> pkgs = AutoConfigurationPackages.get(this.beanFactory);
                for (String pkg : pkgs) {
                    log.debug("Found MyBatis auto-configuration package '" + pkg + "'");
                }
                if (this.resourceLoader != null) {
                    scanner.setResourceLoader(this.resourceLoader);
                }
                mapperPackages = pkgs.toArray(new String[pkgs.size()]);
            }
            scanner.registerFilters();
            scanner.doScan(mapperPackages);
        }
        catch (IllegalStateException ex) {
            log.debug("Could not determine auto-configuration "
                    + "package, automatic mapper scanning disabled.");
        }
    }
    // ...
}

What do you think ?

[kazuki43zoo]

Probably, above my idea is not good ... (sorry ...)