Rebuild mappers automatically after changing xml files

[GoogleCodeExporter]

What version of the MyBatis are you using?
3.1.1

Please describe the problem.  Unit tests are best!
Changing xml files requires the application to restart in order to recreate the 
mapper classes. However, in debug mode an automatic update would be great. 

What is the expected output? What do you see instead?
Mybatis checks upon each requst whether the xml files have been changed and 
recreates the mappers if necessary.

Can you provide stack trace, logs, error messages that are displayed?

Please provide any additional information below.
There is a discussion on the mybatis group:
https://groups.google.com/forum/#!topic/mybatis-user/w1Q-kUS2s7I

Original issue reported on code.google.com by doll.chr...@googlemail.com on 16 Aug 2012 at 6:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

We have a home-grown version of this through a custom fork of Mybatis Guice.  
Because we supply our own CustomConfiguration, we can trap calls to 
getMappedStatement() and check the date of the mapper xml file there.  Last 
modified time stamps are stored in a Map class member.  If the date has 
changed, the mapper object is rebuilt.  The rebuild is not perfect as we do not 
have 100% knowledge of the MyBatis internals, nor the time to delve into all 
possible scenarios.  Basically, all in-memory structures are removed from the 
MyBatis configuration for that mapper - mapped statements, result maps, sql 
fragments, key generators, and caches.  Then the mapper is reloaded using the 
standard parse() methods.

It would be great to get something more robust and configurable (i.e. through 
the mybatis config file - maybe tied to the environment) in place.  The idea of 
creating all SQL up front prior to inclusion in the MyBatis file sounds great, 
but tends to fail in practice in a larger project and team.

Tools like JRebel don't help in this situation, and the app must therefore be 
restarted, using up valuable development time.

Original comment by mof...@gmail.com on 13 Mar 2013 at 3:59