MapperScannerConfigurer does not work with PropertyPlaceholderConfigurer in 1.0.2 version

[GoogleCodeExporter]

What version of the MyBatis are you using?
mybatis-spring1.0.2 with mybatis3.0.6 

Please describe the problem.  Unit tests are best!
1. First I use the mybatis-spring scanner configuration to load the the mapper 
xml files from some package to make them autowired(that's my purpose):
    <bean id = "dataSource" class="...." /> (ignore)   
    <!-- transaction manager, use JtaTransactionManager for global tx -->
    <bean id="transactionManager"    class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
    </bean>

    <!-- enable transaction demarcation with annotations -->
    <tx:annotation-driven transaction-manager="transactionManager" />

    <!-- simplest possible SqlSessionFactory configuration -->
    <bean id = "dialect" class="com.ylink.card.ws.basic.dialect.OracleDialect" />

    <bean id = "pageQueryInterceptor" class="com.ylink.card.ws.basic.interceptors.OffsetLimitInterceptor">
       <property name="dialect" ref="dialect" />
    </bean>

    <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />   
        <property name="plugins">
           <list>
               <ref local="pageQueryInterceptor" />
           </list>
        </property>
    </bean>

    <!--set up Thread safe sqlSession and use Batch Executor as default -->
    <bean id="sqlSessionTemplate" class="org.mybatis.spring.SqlSessionTemplate">
       <constructor-arg index="0" ref="sqlSessionFactory" />
       <constructor-arg index="1" value="BATCH" />
    </bean>

    <!--use mapper scanner to load the mapper interface as the dao replacement -->
    <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
        <property name="basePackage" value="${DEFAULT_MAPPER_BASENAME}" />
    </bean>

2. then I make some facade class just like follows
   @Service("mappersFacade")
   public class DataMappersFacadeImpl {
      @Autowired
      private CardTradeMsgMapper cardTradeMsgMapper;

      @Override
      public CardTradeMsgMapper getCardTradeMsgMapper() {
      return this.cardTradeMsgMapper;
      }
   }

3. after those above listed, when I want to make the reference to 
DataMappersFacadeImpl and access the getCardTradeMsgMapper() method
the console show me the nullpointerExeption

By the way, I noticed that the same case in such page : 
http://mybatis-user.963551.n3.nabble.com/mybatis-MapperScannerConfigurer-td25824
09.html

4. by the way, since I printed the log file, I did find that there's no mapper 
bean is autowired under the scanner in the edition of mybatis-spring 1.0.2, but 
to my surprise, the snapshot of mybatis-spring1.0.2 (size 34kb not 35kb one) 
had noproblem of that above.

What is the expected output? What do you see instead?
The mapper beans under scanner have beed autowried resort to mybatis-spring
and there's no nullpointerException 

Please provide any additional information below.
sorry there's no implicit log to describe the nullpointException trace, but I'm 
sure of that it happened once I did the right configuration(and I had checked 
it many times)

Original issue reported on code.google.com by jerrysco...@gmail.com on 16 Oct 2011 at 12:57

[GoogleCodeExporter]

I hope mybatis-spring team could help me resolve such problem with the latest 
edition
and leave us the correct way to make full use of mybatis-spring.

Original comment by jerrysco...@gmail.com on 18 Oct 2011 at 5:48

[GoogleCodeExporter]

Hi again Jerry. Could you try this one again with mybatis-spring-1.0.1?? There 
was a change in the scanner in 1.0.2, so trying if it works with 1.0.1 then we 
may need to review that change.

Thanks in advance!

Original comment by eduardo.macarron on 18 Oct 2011 at 5:45

[GoogleCodeExporter]

Hi Jerry. To make it easier I have uploaded a snapshot [1] backing out one 
change we did in 1.0.2. Please try with it and tell us what happened with this 
issue and also with #415. Thanks in advance!

http://code.google.com/p/mybatis/downloads/detail?name=mybatis-spring-1.0.3-SNAP
SHOT.jar

Original comment by eduardo.macarron on 18 Oct 2011 at 7:08

• Added labels: Priority-High, Component-Spring
• Removed labels: Priority-Low

[GoogleCodeExporter]

Thanks's a lot for the quick reply, it's proved that the latest snapshot jar 
has resolved the null exception in red hat 64. 

By the way, it doesn't resolve the issue-415 problem(you should install the 
latest jdk 1.6 to reproduce the case), please refer to the attached file with 
it.

Original comment by jerrysco...@gmail.com on 19 Oct 2011 at 5:50

[GoogleCodeExporter]

Hi Jerry. We will need a bit more of your help. We need a full log of 1.0.2 and 
1.0.3-SNAPSHOT in order to know why this fails and commit the change. 

I will be much better if you can reproduce it in a test or in a command line 
java program, so that we can get the log for ourselves.

Could you provide us with that?

Original comment by eduardo.macarron on 19 Oct 2011 at 1:41

[GoogleCodeExporter]

Surely.
1. My running application operates in red hat 64 with jdk1.6.0_27(also 64)

2. I use nohup ./runlinux.sh command to start my application(by the way, I use 
mybatis generator to generate the mapper or entity files from the table of my 
database)

3. The attached file contains one of the mapper file and the nohup.out to show 
   the case I listed in my last comment.

Original comment by jerrysco...@gmail.com on 19 Oct 2011 at 4:08

Attachments:

• nohup.out

[GoogleCodeExporter]

I will need the full log with both versions... Anyway it would be better to run 
your code. Could your attach a working piece of your code that reproduces the 
error?

Original comment by eduardo.macarron on 19 Oct 2011 at 4:13

[GoogleCodeExporter]

I tested both in the mybatis-spring-1.0.2 and mybatis-spring-1.0.3.snapshot 
edition the attached file listed within log4j.logger.org.mybatis=debug 
configuration  

Original comment by jerrysco...@gmail.com on 20 Oct 2011 at 2:09

Attachments:

• nohup.out

[GoogleCodeExporter]

Sorry to insist :) Could you attach your the source code to test it by myself?

Original comment by eduardo.macarron on 20 Oct 2011 at 5:56

[GoogleCodeExporter]

The source codes could not be listed as the attached file and the similar ones 
shown just above. the procedure lists as follows
1. mybatis generator to generate the entity,example,mapper interfaces and also 
with the xml files

2. write the facade interface and use @Autowired to refer to the mapper 
interfaces

3. Make the facade interface could be also refered in another class in order to 
get the mapper interfaces reference

And it's very strange that mybatis-spring(or else spring3.0.6) seemed work well 
in windows32 which compared with high cpu usage in red hat 64(red hat server 
5.4)
I tested the jdk1.6.0_29 edition, the same case reproduced. 

Original comment by jerrysco...@gmail.com on 20 Oct 2011 at 8:54

[GoogleCodeExporter]

By the way, the same case reproduced in jdk1.7.0_01 and also with 
mybatis-spring-1.0.1 

Original comment by jerrysco...@gmail.com on 20 Oct 2011 at 9:01

[GoogleCodeExporter]

I think it is going to be really difficult to know why CPU consumption is 
higher in linux than in windows. Moreover, I am pretty sure the work is being 
done inside Spring, not in the Scanner. 

The problem that bothers me is the NullPointerException that got solved with 
1.0.3-SNAPSHOT. Jpetstore is using the same scenario as your project and works 
fine both with 1.0.2 and 1.0.3-SNAPSHOT. So I cannot reproduce the error.

Original comment by eduardo.macarron on 20 Oct 2011 at 11:30

[GoogleCodeExporter]

Yeah, so it is with me. there will be some problem while the integration under 
64jdk, maybe it's due to the sake of spring inside for all test done in red hat 
5.4 linux server(with kernel 2.6.18). for another solution, I just uninstalled 
the 64 JDK to be replaced with the 32 jdk, these errors including the high cpu 
usage disappeared(also with fast extracting speed).

I'm sure that you could reproduce the similar mistakes in redhat linux under 64 
JDK for these days I just tested so many edition of 64JDK. 

Original comment by jerrysco...@gmail.com on 20 Oct 2011 at 2:53

[GoogleCodeExporter]

I will post the same question to spring forum for help later on. maybe someone 
among them could give me the trusted explanation. but thank you all the same 
with mybatis team to trace such problem.

Original comment by jerrysco...@gmail.com on 20 Oct 2011 at 2:56

[GoogleCodeExporter]

Ok, I think I have it. The problem is the PropertyPlaceHolderConfigurer. It 
seems it does not work with mybatis-spring 1.0.2.

Steps to reproduce with jpetstore are these:

Add the configurer to applicationContext.xml

<context:property-placeholder location="classpath:conf.properties" />

Add a file conf.properties with:

DEFAULT_MAPPER_BASENAME=org.mybatis.jpetstore.persistence

Modify the mapperscanner this way:

<property name="basePackage" value="${DEFAULT_MAPPER_BASENAME}" />

And try with 1.0.1 and 1.0.2. With 1.0.2 you will get:

java.lang.IllegalArgumentException: Could not resolve placeholder 
'DEFAULT_MAPPER_BASENAME'
    at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:173)
    at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:125)
    at org.springframework.util.SystemPropertyUtils.resolvePlaceholders(SystemPropertyUtils.java:80)
    at org.springframework.util.SystemPropertyUtils.resolvePlaceholders(SystemPropertyUtils.java:64)
    at org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.resolveBasePackage(ClassPathScanningCandidateComponentProvider.java:264)
    at org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:203)
    at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:204)
    at org.mybatis.spring.mapper.MapperScannerConfigurer$Scanner.doScan(MapperScannerConfigurer.java:224)

Summary changed.

Original comment by eduardo.macarron on 21 Oct 2011 at 4:16

• Changed title: MapperScannerConfigurer does not work with PropertyPlaceholderConfigurer in 1.0.2 version

[GoogleCodeExporter]

BTW seems this is a regression. Have a look at issue 143.

If fails when the mapper itself has a property that must be replaced or when it 
depends on any other object that has a property. 

For example it fails if sqlSessionFactory is set and it depends on a datasource 
with properties as Hunter said in issue 143.

Original comment by eduardo.macarron on 21 Oct 2011 at 4:47

[GoogleCodeExporter]

PropertyPlaceholderConfigurer (BeanFactoryPostProcessor) process after 
MapperScannerConfigurer (BeanDefinitionRegistryPostProcessor), that's why 
placeholder ${} is not working with MapperScannerConfigurer.

There are issue in SpringSource about PropertyPlaceHolder and BeanFactory 
relateed to this problem.
https://jira.springsource.org/browse/SPR-1358

Propose temporary solution for mybatis user:
1. Instead of using PropertyPlaceholderConfigurer, we can use 
PropertiesFactoryBean to do the same task.

    <util:properties id="dataSourceProps" location="classpath:dataSource.properties"/>

    <bean id="dataSource" class="org.apache.ibatis.datasource.pooled.PooledDataSource">
      <property name="driver" value="#{dataSourceProps['jdbc.driverClass']}"/>
      <property name="url" value="#{dataSourceProps['jdbc.url']}"/>
      <property name="username" value="#{dataSourceProps['jdbc.username']}"/>
      <property name="password" value="#{dataSourceProps['jdbc.password']}"/>
    </bean>

2. Use MapperFactoryBean, SqlSessionDaoSupport or SqlSessionTemplate directly.

3. Use PropertyPlaceholderConfigurer with system properties.
$ export jdbc.driverClass=org.postgresql.Driver
$ export jdbc.url=jdbc:postgresql:databaseName
$ export jdbc.username=postgres
$ export jdbc.password=********

Original comment by putthibo...@gmail.com on 22 Oct 2011 at 6:53

[GoogleCodeExporter]

OK,I will try it later on and also test the jdk64 high cpu usage.

Original comment by jerrysco...@gmail.com on 22 Oct 2011 at 3:26

[GoogleCodeExporter]

Original comment by eduardo.macarron on 24 Oct 2011 at 5:57

• Added labels: Target-Release1.0.3

[GoogleCodeExporter]

Fixed in trunk (r3970, r3971, r3972). Substituted actual objects by object 
names in r3984 and r3987.

Snapshot is ready for download.

Thanks for the report!

Original comment by eduardo.macarron on 27 Oct 2011 at 4:10

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by eduardo.macarron on 29 Nov 2011 at 9:25

• Added labels: Target-Release1.1.0
• Removed labels: Target-Release1.0.3

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi, I'm using version 1.1.0 and I'm having the issue described above, but 
instead of property-placeholder I'm using cocoon configurator. The datasource 
is set in the sqlSessionBeanFactory, before the property placeholders are 
replaced.

Thanks,
Sebastian Montero

Original comment by sebastia...@gmail.com on 8 Apr 2012 at 9:48

[GoogleCodeExporter]

Sebastian, I will be great if you could try the snapshot and post the results.

Original comment by eduardo.macarron on 8 Apr 2012 at 10:02

[GoogleCodeExporter]

Hi Eduardo,

I tried it with mybatis-spring1.1.1-SNAPSHOT, but the problem persists.

Thanks,

Sebastian Montero

Original comment by sebastia...@gmail.com on 9 Apr 2012 at 4:31

[GoogleCodeExporter]

Ok, thanks for the testing. Could you post how you configured the scanner? 

Original comment by eduardo.macarron on 9 Apr 2012 at 7:08

[GoogleCodeExporter]

Hi Eduardo,

I just realized that I shouldn’t specify the sqlSessionFactory for the mapper 
scanner, removing it solved the problem.
Sorry for bringing up this issue.
Thanks for your help,
Sebastian

Original comment by sebastia...@gmail.com on 9 Apr 2012 at 2:26

[GoogleCodeExporter]

hi , the issue still exists in mybatis-spring:1.1.0 release

Original comment by ace...@gmail.com on 18 Oct 2012 at 3:06

[GoogleCodeExporter]

Issue 602 has been merged into this issue.

Original comment by eduardo.macarron on 3 Nov 2012 at 6:30