Custom FactoryBean on MapperScan annotation

[nguyenvanthan]

Hi !!
Can you have a look to this little contribution :-)

Use case

We want to use our custom annotation on mapper interfaces to select the correct datasource at bean creation phase. Our datasource instances are not present in spring context.

Problem

We use several datasources for our application but we want to scan all our mapper by convention with a spring java config. I see some attribute like sqlSessionFactoryRef or sqlSessionTemplateRef but with this, we have to declare a sqlSessionFactory for each datasource and declare a MapperScan for each different database (or maybe i miss something).

Resolve with this PR

We will be able to use this:

@MapperScan(basePackages = "org.mybatis.spring.mapper", factoryBean = OurCustomFactoryBean.class)

OurCustomFactoryBean will override getObject() to choose the right datasource and return a mapper proxy with the selected sqlSessionFactory. The session factory is built by some custom internal stuffs.

[dstendardi]

Very useful !

[ghost]

👍

[hazendaz]

@nguyenvanthan I know it's been some time. I looked at this and don't really see any issue preventing it from being added to mybatis. I'm not strong in spring but from what I can tell this is extra and doesn't modify existing usage. That said, if that is all true what I state, please rebase this so it is clean to merge and I'll merge it.

[nguyenvanthan]

Hi @hazendaz
I have merge my modifications but it may have conflicts with #58 or #59. I don't see any test on these PR to fix them.
Have a look to org.mybatis.spring.mapper.ClassPathMapperScanner :
I use :

definition.getPropertyValues().add("mapperInterface", definition.getBeanClassName());

instead of :

definition.getConstructorArgumentValues().addGenericArgumentValue(definition.getBeanClassName());

[hazendaz]

What I think you want to do first, is to perform a 'git reset --hard HEAD~1' to get back to your change only. Then perform 'git pull --rebase upstream master'. That will rewind your changes and then apply yours on top allowing you to fix whatever merge conflicts existed. It also won't appears as though changes were made by you that were not actually made as it currently shows. It will also bring your changes up to the HEAD so when we do merge, it will come in completely clean. At that point, then i can look a little closer at this.

Oh once you rebase like that, when you push back up to your origin, use 'git push origin +master' which will rewrite what you have thus leaving only a single commit and no merge.

[nguyenvanthan]

Rebase done but Travis build failed. Strange jdk8 errors ...

[hazendaz]

Closing this PR. I have moved this over to PR #70 with a few minor changes and squashed the commits. Code will be merged into master as soon as travis CI completes successfully.