Wasted way too many hours on this today since I was looking everywhere
except for the Spring MyBatis setup as the culprit. I went away from using
a Java config for my MyBatis stuff since there were issues with the whole
issues of properties getting loaded and dealing with the Mapper scanner.
Now, apparently even defining the following messes with the whole setting
of properties using the PropertyPlaceholderConfigurer...
<!--- NONE OF THESE WILL BE SET ! --->
<bean id="oracleDS" class="org.apache.commons.dbcp.BasicDataSource">
<property name="url" value="${oraUrl}"/>
<property name="username" value="${username}"/>
.....
</bean>
According to the docs I realize these issues happened with the
MapperScanner http://www.mybatis.org/spring/mappers.html, but how do I
avoid it when just creating a standard MapperFactoryBean? MapperFactory
doesn't take an instance of sqlSessionFactoryBeanName like the
MapperScanner does?
Note the same issue arises if you try to define another MapperScanner and
you still end up instantiating a SqlSessionTemplate with a reference to
sqlSessionFactory...
<!-- try to map a different package with batch mappers -->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.ncs.batchmapper"/>
<property name="sqlSessionFactoryBeanName"
value="sqlSessionFactoryForBatch"/>
</bean>
<!-- This coupled with the mapper above causes the problem -->
<bean id="batchSqlSessionTemplate"
class="org.mybatis.spring.SqlSessionTemplate">
<constructor-arg index="0" ref="sqlSessionFactoryForBatch"/>
<constructor-arg index="1" value="BATCH"/>
</bean>
On Mon, May 14, 2012 at 10:51 PM, Rick R <ric...@gmail.com> wrote:
> Wasted way too many hours on this today since I was looking everywhere
> except for the Spring MyBatis setup as the culprit. I went away from using
> a Java config for my MyBatis stuff since there were issues with the whole
> issues of properties getting loaded and dealing with the Mapper scanner.
> Now, apparently even defining the following messes with the whole setting
> of properties using the PropertyPlaceholderConfigurer...
> <!--- NONE OF THESE WILL BE SET ! --->
> <bean id="oracleDS" class="org.apache.commons.dbcp.BasicDataSource">
> <property name="url" value="${oraUrl}"/>
> <property name="username" value="${username}"/>
> .....
> </bean>
> According to the docs I realize these issues happened with the
> MapperScanner http://www.mybatis.org/spring/mappers.html, but how do I
> avoid it when just creating a standard MapperFactoryBean? MapperFactory
> doesn't take an instance of sqlSessionFactoryBeanName like the
> MapperScanner does?
Hi Rick. I am sorry I have not much time to get deeply into this
issues so sorry if I overlook something important.
The scanner is a bean that runs early during the spring startup
process. It runs before the propertiesplaceholderconfigurer so there
may be a problem with the place holders and you already know. But this
cannot happen with a MapperFactoryBean because it is a normal bean an
will be started once the propertiesplaceholderconfigurer has finished
so the problem must be elsewhere...
> Note the same issue arises if you try to define another MapperScanner and
> you still end up instantiating a SqlSessionTemplate with a reference to
> sqlSessionFactory...
> <!-- This coupled with the mapper above causes the problem -->
> <bean id="batchSqlSessionTemplate"
> class="org.mybatis.spring.SqlSessionTemplate">
> <constructor-arg index="0" ref="sqlSessionFactoryForBatch"/>
> <constructor-arg index="1" value="BATCH"/>
> </bean>
> On Mon, May 14, 2012 at 10:51 PM, Rick R <ric...@gmail.com> wrote:
>> Wasted way too many hours on this today since I was looking everywhere
>> except for the Spring MyBatis setup as the culprit. I went away from using a
>> Java config for my MyBatis stuff since there were issues with the whole
>> issues of properties getting loaded and dealing with the Mapper scanner.
>> Now, apparently even defining the following messes with the whole setting
>> of properties using the PropertyPlaceholderConfigurer...
>> <!--- NONE OF THESE WILL BE SET ! --->
>> <bean id="oracleDS" class="org.apache.commons.dbcp.BasicDataSource">
>> <property name="url" value="${oraUrl}"/>
>> <property name="username" value="${username}"/>
>> .....
>> </bean>
>> According to the docs I realize these issues happened with the
>> MapperScanner http://www.mybatis.org/spring/mappers.html, but how do I avoid
>> it when just creating a standard MapperFactoryBean? MapperFactory doesn't
>> take an instance of sqlSessionFactoryBeanName like the MapperScanner does?
On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron <
eduardo.macar...@gmail.com> wrote:
> Hi Rick. I am sorry I have not much time to get deeply into this
> issues so sorry if I overlook something important.
> The scanner is a bean that runs early during the spring startup
> process. It runs before the propertiesplaceholderconfigurer so there
> may be a problem with the place holders and you already know. But this
> cannot happen with a MapperFactoryBean because it is a normal bean an
> will be started once the propertiesplaceholderconfigurer has finished
> so the problem must be elsewhere...
There definitely seems to be something odd going on though when you use a
combination of 1) multiple SqlSessionFactories and 2) mapper scanner and a
MapperFactoryBean definition.
For example, I'm trying to set up a simple example to show you what I'm
referring to, and based on this following code with more than one
SqlSessionFactoryBean defined... if you include the MapperFactoryBean as
part of the deployment, Spring can't decide which SqlSessionFactory to bind
to autowire as you can see in this highlighted screen shot:
https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg HOWEVER, the
odd thing is if I remove the MapperFactoryBean definition, then there are
no issues auto-wiring.
<!--- MAPPER SCANNER, this should map sqlSessionFactoryOne to the
Mappers scanned.. so why complain about not knowing
which sqlSessionFacotryBean to autowire when the MapperFactoryBean
is included below this definition
--->
> 2012/5/15 Rick R <ric...@gmail.com>:
> > Note the same issue arises if you try to define another MapperScanner and
> > you still end up instantiating a SqlSessionTemplate with a reference to
> > sqlSessionFactory...
> > <!-- This coupled with the mapper above causes the problem -->
> > <bean id="batchSqlSessionTemplate"
> > class="org.mybatis.spring.SqlSessionTemplate">
> > <constructor-arg index="0" ref="sqlSessionFactoryForBatch"/>
> > <constructor-arg index="1" value="BATCH"/>
> > </bean>
> > On Mon, May 14, 2012 at 10:51 PM, Rick R <ric...@gmail.com> wrote:
> >> Wasted way too many hours on this today since I was looking everywhere
> >> except for the Spring MyBatis setup as the culprit. I went away from
> using a
> >> Java config for my MyBatis stuff since there were issues with the whole
> >> issues of properties getting loaded and dealing with the Mapper scanner.
> >> Now, apparently even defining the following messes with the whole
> setting
> >> of properties using the PropertyPlaceholderConfigurer...
> >> <!--- NONE OF THESE WILL BE SET ! --->
> >> <bean id="oracleDS" class="org.apache.commons.dbcp.BasicDataSource">
> >> <property name="url" value="${oraUrl}"/>
> >> <property name="username" value="${username}"/>
> >> .....
> >> </bean>
> >> According to the docs I realize these issues happened with the
> >> MapperScanner http://www.mybatis.org/spring/mappers.html, but how do I
> avoid
> >> it when just creating a standard MapperFactoryBean? MapperFactory
> doesn't
> >> take an instance of sqlSessionFactoryBeanName like the MapperScanner
> does?
Ok a bit more info... I removed the MapperScanner completely and now in
both apps (the original and the one I was going to provide as an example),
I defined *ALL* my mappers as MapperFactoryBeans and then the properties
get set just fine (after removing the MapperScannerConfigurer.) Using
MapperScannerConfigurer seems to mess with things.. even when I have it
defined as the docs point out using sqlSessionFactoryBeanName:
I think I'm going to have to just be safe and rely on defining all my
Mappers in my xml :(.. sort of stinks since it's now one more ugly piece of
xml to maintain, but oh well. Possibly others aren't running into this
since they:
1) Aren't defining multiple SqlSessionFactories and/or 2) aren't relying
on auto-wiring of things.
I'd be interested in other examples out there of people using the latest
spring and spring-mybatis with multiple SqlSessionFactories defined and
using the MapperScannerConfigurer and leveraging auto-wiring of mappers.
On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron <
> eduardo.macar...@gmail.com> wrote:
>> Hi Rick. I am sorry I have not much time to get deeply into this
>> issues so sorry if I overlook something important.
>> The scanner is a bean that runs early during the spring startup
>> process. It runs before the propertiesplaceholderconfigurer so there
>> may be a problem with the place holders and you already know. But this
>> cannot happen with a MapperFactoryBean because it is a normal bean an
>> will be started once the propertiesplaceholderconfigurer has finished
>> so the problem must be elsewhere...
> There definitely seems to be something odd going on though when you use a
> combination of 1) multiple SqlSessionFactories and 2) mapper scanner and a
> MapperFactoryBean definition.
> For example, I'm trying to set up a simple example to show you what I'm
> referring to, and based on this following code with more than one
> SqlSessionFactoryBean defined... if you include the MapperFactoryBean as
> part of the deployment, Spring can't decide which SqlSessionFactory to bind
> to autowire as you can see in this highlighted screen shot:
> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg HOWEVER,
> the odd thing is if I remove the MapperFactoryBean definition, then there
> are no issues auto-wiring.
> <!--- MAPPER SCANNER, this should map sqlSessionFactoryOne to the
> Mappers scanned.. so why complain about not knowing
> which sqlSessionFacotryBean to autowire when the
> MapperFactoryBean is included below this definition
> --->
>> 2012/5/15 Rick R <ric...@gmail.com>:
>> > Note the same issue arises if you try to define another MapperScanner
>> and
>> > you still end up instantiating a SqlSessionTemplate with a reference to
>> > sqlSessionFactory...
>> > <!-- This coupled with the mapper above causes the problem -->
>> > <bean id="batchSqlSessionTemplate"
>> > class="org.mybatis.spring.SqlSessionTemplate">
>> > <constructor-arg index="0" ref="sqlSessionFactoryForBatch"/>
>> > <constructor-arg index="1" value="BATCH"/>
>> > </bean>
>> > On Mon, May 14, 2012 at 10:51 PM, Rick R <ric...@gmail.com> wrote:
>> >> Wasted way too many hours on this today since I was looking everywhere
>> >> except for the Spring MyBatis setup as the culprit. I went away from
>> using a
>> >> Java config for my MyBatis stuff since there were issues with the whole
>> >> issues of properties getting loaded and dealing with the Mapper
>> scanner.
>> >> Now, apparently even defining the following messes with the whole
>> setting
>> >> of properties using the PropertyPlaceholderConfigurer...
>> >> <!--- NONE OF THESE WILL BE SET ! --->
>> >> <bean id="oracleDS" class="org.apache.commons.dbcp.BasicDataSource">
>> >> <property name="url" value="${oraUrl}"/>
>> >> <property name="username" value="${username}"/>
>> >> .....
>> >> </bean>
>> >> According to the docs I realize these issues happened with the
>> >> MapperScanner http://www.mybatis.org/spring/mappers.html, but how do
>> I avoid
>> >> it when just creating a standard MapperFactoryBean? MapperFactory
>> doesn't
>> >> take an instance of sqlSessionFactoryBeanName like the MapperScanner
>> does?
This problem/bug seems to be in the class
SqlSessionDaoSupport
It tries to autowire both, a sqlSessionFactory and a sqlSessionTemplate with @Autowired. If the later is found it will be used, regardless whether it belongs itself to the correct SqlSessionFactory. The requested SqlSession points to the wrong database in the end.
This will lead to the effect, that you cannot use SqlSessionTemplate and MapperScanner together if multiple databases/SqlSessionFactories are defined.
In my opinion, SqlSessionDaoSupport should not use @Autowired.
One can overcome this problem by disabling autowireing for the SqlSessionTemplate:
From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Rick R
Sent: Dienstag, 15. Mai 2012 18:42
To: mybatis-user@googlegroups.com
Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
Ok a bit more info... I removed the MapperScanner completely and now in both apps (the original and the one I was going to provide as an example), I defined *ALL* my mappers as MapperFactoryBeans and then the properties get set just fine (after removing the MapperScannerConfigurer.) Using MapperScannerConfigurer seems to mess with things.. even when I have it defined as the docs point out using sqlSessionFactoryBeanName:
I think I'm going to have to just be safe and rely on defining all my Mappers in my xml :(.. sort of stinks since it's now one more ugly piece of xml to maintain, but oh well. Possibly others aren't running into this since they:
1) Aren't defining multiple SqlSessionFactories and/or 2) aren't relying on auto-wiring of things.
I'd be interested in other examples out there of people using the latest spring and spring-mybatis with multiple SqlSessionFactories defined and using the MapperScannerConfigurer and leveraging auto-wiring of mappers.
On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com<mailto:ric...@gmail.com>> wrote:
On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron <eduardo.macar...@gmail.com<mailto:eduardo.macar...@gmail.com>> wrote:
Hi Rick. I am sorry I have not much time to get deeply into this
issues so sorry if I overlook something important.
The scanner is a bean that runs early during the spring startup
process. It runs before the propertiesplaceholderconfigurer so there
may be a problem with the place holders and you already know. But this
cannot happen with a MapperFactoryBean because it is a normal bean an
will be started once the propertiesplaceholderconfigurer has finished
so the problem must be elsewhere...
There definitely seems to be something odd going on though when you use a combination of 1) multiple SqlSessionFactories and 2) mapper scanner and a MapperFactoryBean definition.
For example, I'm trying to set up a simple example to show you what I'm referring to, and based on this following code with more than one SqlSessionFactoryBean defined... if you include the MapperFactoryBean as part of the deployment, Spring can't decide which SqlSessionFactory to bind to autowire as you can see in this highlighted screen shot: https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg HOWEVER, the odd thing is if I remove the MapperFactoryBean definition, then there are no issues auto-wiring.
<!--- MAPPER SCANNER, this should map sqlSessionFactoryOne to the Mappers scanned.. so why complain about not knowing
which sqlSessionFacotryBean to autowire when the MapperFactoryBean is included below this definition
--->
> Note the same issue arises if you try to define another MapperScanner and
> you still end up instantiating a SqlSessionTemplate with a reference to
> sqlSessionFactory...
> <!-- This coupled with the mapper above causes the problem -->
> <bean id="batchSqlSessionTemplate"
> class="org.mybatis.spring.SqlSessionTemplate">
> <constructor-arg index="0" ref="sqlSessionFactoryForBatch"/>
> <constructor-arg index="1" value="BATCH"/>
> </bean>
> On Mon, May 14, 2012 at 10:51 PM, Rick R <ric...@gmail.com<mailto:ric...@gmail.com>> wrote:
>> Wasted way too many hours on this today since I was looking everywhere
>> except for the Spring MyBatis setup as the culprit. I went away from using a
>> Java config for my MyBatis stuff since there were issues with the whole
>> issues of properties getting loaded and dealing with the Mapper scanner.
>> Now, apparently even defining the following messes with the whole setting
>> of properties using the PropertyPlaceholderConfigurer...
>> <!--- NONE OF THESE WILL BE SET ! --->
>> <bean id="oracleDS" class="org.apache.commons.dbcp.BasicDataSource">
>> <property name="url" value="${oraUrl}"/>
>> <property name="username" value="${username}"/>
>> .....
>> </bean>
>> According to the docs I realize these issues happened with the
>> MapperScanner http://www.mybatis.org/spring/mappers.html, but how do I avoid
>> it when just creating a standard MapperFactoryBean? MapperFactory doesn't
>> take an instance of sqlSessionFactoryBeanName like the MapperScanner does?
> It tries to autowire both, a sqlSessionFactory and a sqlSessionTemplate with
> @Autowired. If the later is found it will be used, regardless whether it
> belongs itself to the correct SqlSessionFactory. The requested SqlSession
> points to the wrong database in the end.
> This will lead to the effect, that you cannot use SqlSessionTemplate and
> MapperScanner together if multiple databases/SqlSessionFactories are
> defined.
> In my opinion, SqlSessionDaoSupport should not use @Autowired.
> One can overcome this problem by disabling autowireing for the
> SqlSessionTemplate:
> In your own service classes, you have to force autowireing with
> @Resource(name="batchExecutor")
> SqlSessionTemplate batchExecutor;
> Felix
> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com]
> On Behalf Of Rick R
> Sent: Dienstag, 15. Mai 2012 18:42
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory and
> PropertyPlaceholderConfigurer
> Ok a bit more info... I removed the MapperScanner completely and now in both
> apps (the original and the one I was going to provide as an example), I
> defined *ALL* my mappers as MapperFactoryBeans and then the properties get
> set just fine (after removing the MapperScannerConfigurer.) Using
> MapperScannerConfigurer seems to mess with things.. even when I have it
> defined as the docs point out using sqlSessionFactoryBeanName:
> I think I'm going to have to just be safe and rely on defining all my
> Mappers in my xml :(.. sort of stinks since it's now one more ugly piece of
> xml to maintain, but oh well. Possibly others aren't running into this since
> they:
> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't relying on
> auto-wiring of things.
> I'd be interested in other examples out there of people using the latest
> spring and spring-mybatis with multiple SqlSessionFactories defined and
> using the MapperScannerConfigurer and leveraging auto-wiring of mappers.
> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
> <eduardo.macar...@gmail.com> wrote:
> Hi Rick. I am sorry I have not much time to get deeply into this
> issues so sorry if I overlook something important.
> The scanner is a bean that runs early during the spring startup
> process. It runs before the propertiesplaceholderconfigurer so there
> may be a problem with the place holders and you already know. But this
> cannot happen with a MapperFactoryBean because it is a normal bean an
> will be started once the propertiesplaceholderconfigurer has finished
> so the problem must be elsewhere...
> There definitely seems to be something odd going on though when you use a
> combination of 1) multiple SqlSessionFactories and 2) mapper scanner and a
> MapperFactoryBean definition.
> For example, I'm trying to set up a simple example to show you what I'm
> referring to, and based on this following code with more than one
> SqlSessionFactoryBean defined... if you include the MapperFactoryBean as
> part of the deployment, Spring can't decide which SqlSessionFactory to bind
> to autowire as you can see in this highlighted screen shot:
> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg HOWEVER, the
> odd thing is if I remove the MapperFactoryBean definition, then there are no
> issues auto-wiring.
>> Note the same issue arises if you try to define another MapperScanner and
>> you still end up instantiating a SqlSessionTemplate with a reference to
>> sqlSessionFactory...
>> <!-- This coupled with the mapper above causes the problem -->
>> <bean id="batchSqlSessionTemplate"
>> class="org.mybatis.spring.SqlSessionTemplate">
>> <constructor-arg index="0" ref="sqlSessionFactoryForBatch"/>
>> <constructor-arg index="1" value="BATCH"/>
>> </bean>
>> On Mon, May 14, 2012 at 10:51 PM, Rick R <ric...@gmail.com> wrote:
>>> Wasted way too many hours on this today since I was looking everywhere
>>> except for the Spring MyBatis setup as the culprit. I went away from
>>> using a
>>> Java config for my MyBatis stuff since there were issues with the whole
>>> issues of properties getting loaded and dealing with the Mapper scanner.
>>> Now, apparently even defining the following messes with the whole setting
>>> of properties using the PropertyPlaceholderConfigurer...
All mappers directing to database_2/sglSessionFactory_2 are now going to database_1. The reason is the Dual-Autowireing in SqlSessionDaoSupport.
The MapperScannerConfigurer now prefers the autowired sqlSessionTemplate over the explicitly wired sqlSessionFactory. It should be the other way around?
I even didn't see the point to use a sqlSessionTemplate template in SqlSessionDaoSupport at all, since it creates a template with the "sqlSessionFactory" anyways?
-----Original Message-----
From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
Sent: Donnerstag, 24. Januar 2013 16:38
To: mybatis-user@googlegroups.com
Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
Hi Felix,
If there is more than one factory then you cannot use autowire because you need to specify which one should be injected in your mappers/daos.
Does it fail if you explicitly inject the right template?
2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com<mailto:Felix.Ku...@globalfoundries.com>>:
> This problem/bug seems to be in the class
> SqlSessionDaoSupport
> It tries to autowire both, a sqlSessionFactory and a
> sqlSessionTemplate with @Autowired. If the later is found it will be
> used, regardless whether it belongs itself to the correct
> SqlSessionFactory. The requested SqlSession points to the wrong database in the end.
> This will lead to the effect, that you cannot use SqlSessionTemplate
> and MapperScanner together if multiple databases/SqlSessionFactories
> are defined.
> In my opinion, SqlSessionDaoSupport should not use @Autowired.
> One can overcome this problem by disabling autowireing for the
> SqlSessionTemplate:
> In your own service classes, you have to force autowireing with
> @Resource(name="batchExecutor")
> SqlSessionTemplate batchExecutor;
> Felix
> From: mybatis-user@googlegroups.com<mailto:mybatis-user@googlegroups.com>
> [mailto:mybatis-user@googlegroups.com]
> On Behalf Of Rick R
> Sent: Dienstag, 15. Mai 2012 18:42
> To: mybatis-user@googlegroups.com<mailto:mybatis-user@googlegroups.com>
> Subject: Re: More property setting woes ... even with MapperFactory
> and PropertyPlaceholderConfigurer
> Ok a bit more info... I removed the MapperScanner completely and now
> in both apps (the original and the one I was going to provide as an
> example), I defined *ALL* my mappers as MapperFactoryBeans and then
> the properties get set just fine (after removing the
> MapperScannerConfigurer.) Using MapperScannerConfigurer seems to mess
> with things.. even when I have it defined as the docs point out using sqlSessionFactoryBeanName:
> I think I'm going to have to just be safe and rely on defining all my
> Mappers in my xml :(.. sort of stinks since it's now one more ugly
> piece of xml to maintain, but oh well. Possibly others aren't running
> into this since
> they:
> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't
> relying on auto-wiring of things.
> I'd be interested in other examples out there of people using the
> latest spring and spring-mybatis with multiple SqlSessionFactories
> defined and using the MapperScannerConfigurer and leveraging auto-wiring of mappers.
> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com<mailto:ric...@gmail.com>> wrote:
> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
> <eduardo.macar...@gmail.com<mailto:eduardo.macar...@gmail.com>> wrote:
> Hi Rick. I am sorry I have not much time to get deeply into this
> issues so sorry if I overlook something important.
> The scanner is a bean that runs early during the spring startup
> process. It runs before the propertiesplaceholderconfigurer so there
> may be a problem with the place holders and you already know. But this
> cannot happen with a MapperFactoryBean because it is a normal bean an
> will be started once the propertiesplaceholderconfigurer has finished
> so the problem must be elsewhere...
> There definitely seems to be something odd going on though when you
> use a combination of 1) multiple SqlSessionFactories and 2) mapper
> scanner and a MapperFactoryBean definition.
> For example, I'm trying to set up a simple example to show you what
> I'm referring to, and based on this following code with more than one
> SqlSessionFactoryBean defined... if you include the MapperFactoryBean
> as part of the deployment, Spring can't decide which SqlSessionFactory
> to bind to autowire as you can see in this highlighted screen shot:
> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg > HOWEVER, the odd thing is if I remove the MapperFactoryBean
> definition, then there are no issues auto-wiring.
> All mappers directing to database_2/sglSessionFactory_2 are now going to
> database_1. The reason is the Dual-Autowireing in SqlSessionDaoSupport.
> The MapperScannerConfigurer now prefers the autowired sqlSessionTemplate
> over the explicitly wired sqlSessionFactory. It should be the other way
> around?
> I even didn’t see the point to use a sqlSessionTemplate template in
> SqlSessionDaoSupport at all, since it creates a template with the
> “sqlSessionFactory” anyways?
> -----Original Message-----
> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com]
> On Behalf Of Eduardo Macarron
> Sent: Donnerstag, 24. Januar 2013 16:38
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory and
> PropertyPlaceholderConfigurer
> Hi Felix,
> If there is more than one factory then you cannot use autowire because you
> need to specify which one should be injected in your mappers/daos.
> Does it fail if you explicitly inject the right template?
> 2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
>> This problem/bug seems to be in the class
>> SqlSessionDaoSupport
>> It tries to autowire both, a sqlSessionFactory and a
>> sqlSessionTemplate with @Autowired. If the later is found it will be
>> used, regardless whether it belongs itself to the correct
>> SqlSessionFactory. The requested SqlSession points to the wrong database
>> in the end.
>> This will lead to the effect, that you cannot use SqlSessionTemplate
>> and MapperScanner together if multiple databases/SqlSessionFactories
>> are defined.
>> In my opinion, SqlSessionDaoSupport should not use @Autowired.
>> One can overcome this problem by disabling autowireing for the
>> SqlSessionTemplate:
>> In your own service classes, you have to force autowireing with
>> @Resource(name="batchExecutor")
>> SqlSessionTemplate batchExecutor;
>> Felix
>> From: mybatis-user@googlegroups.com
>> [mailto:mybatis-user@googlegroups.com]
>> On Behalf Of Rick R
>> Sent: Dienstag, 15. Mai 2012 18:42
>> To: mybatis-user@googlegroups.com
>> Subject: Re: More property setting woes ... even with MapperFactory
>> and PropertyPlaceholderConfigurer
>> Ok a bit more info... I removed the MapperScanner completely and now
>> in both apps (the original and the one I was going to provide as an
>> example), I defined *ALL* my mappers as MapperFactoryBeans and then
>> the properties get set just fine (after removing the
>> MapperScannerConfigurer.) Using MapperScannerConfigurer seems to mess
>> with things.. even when I have it defined as the docs point out using
>> sqlSessionFactoryBeanName:
>> I think I'm going to have to just be safe and rely on defining all my
>> Mappers in my xml :(.. sort of stinks since it's now one more ugly
>> piece of xml to maintain, but oh well. Possibly others aren't running
>> into this since
>> they:
>> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't
>> relying on auto-wiring of things.
>> I'd be interested in other examples out there of people using the
>> latest spring and spring-mybatis with multiple SqlSessionFactories
>> defined and using the MapperScannerConfigurer and leveraging auto-wiring
>> of mappers.
>> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
>> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
>> <eduardo.macar...@gmail.com> wrote:
>> Hi Rick. I am sorry I have not much time to get deeply into this
>> issues so sorry if I overlook something important.
>> The scanner is a bean that runs early during the spring startup
>> process. It runs before the propertiesplaceholderconfigurer so there
>> may be a problem with the place holders and you already know. But this
>> cannot happen with a MapperFactoryBean because it is a normal bean an
>> will be started once the propertiesplaceholderconfigurer has finished
>> so the problem must be elsewhere...
>> There definitely seems to be something odd going on though when you
>> use a combination of 1) multiple SqlSessionFactories and 2) mapper
>> scanner and a MapperFactoryBean definition.
>> For example, I'm trying to set up a simple example to show you what
>> I'm referring to, and based on this following code with more than one
>> SqlSessionFactoryBean defined... if you include the MapperFactoryBean
>> as part of the deployment, Spring can't decide which SqlSessionFactory
>> to bind to autowire as you can see in this highlighted screen shot:
>> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg >> HOWEVER, the odd thing is if I remove the MapperFactoryBean
>> definition, then there are no issues auto-wiring.
-----Original Message-----
From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
Sent: Thursday, January 24, 2013 6:28 PM
To: mybatis-user@googlegroups.com
Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
Are you using mybatis-spring 1.1.1?
There is a test with that exact scenario that passes OK.
> All mappers directing to database_2/sglSessionFactory_2 are now going to
> database_1. The reason is the Dual-Autowireing in SqlSessionDaoSupport.
> The MapperScannerConfigurer now prefers the autowired sqlSessionTemplate
> over the explicitly wired sqlSessionFactory. It should be the other way
> around?
> I even didn't see the point to use a sqlSessionTemplate template in
> SqlSessionDaoSupport at all, since it creates a template with the
> "sqlSessionFactory" anyways?
> -----Original Message-----
> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com]
> On Behalf Of Eduardo Macarron
> Sent: Donnerstag, 24. Januar 2013 16:38
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory and
> PropertyPlaceholderConfigurer
> Hi Felix,
> If there is more than one factory then you cannot use autowire because you
> need to specify which one should be injected in your mappers/daos.
> Does it fail if you explicitly inject the right template?
> 2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
>> This problem/bug seems to be in the class
>> SqlSessionDaoSupport
>> It tries to autowire both, a sqlSessionFactory and a
>> sqlSessionTemplate with @Autowired. If the later is found it will be
>> used, regardless whether it belongs itself to the correct
>> SqlSessionFactory. The requested SqlSession points to the wrong database
>> in the end.
>> This will lead to the effect, that you cannot use SqlSessionTemplate
>> and MapperScanner together if multiple databases/SqlSessionFactories
>> are defined.
>> In my opinion, SqlSessionDaoSupport should not use @Autowired.
>> One can overcome this problem by disabling autowireing for the
>> SqlSessionTemplate:
>> In your own service classes, you have to force autowireing with
>> @Resource(name="batchExecutor")
>> SqlSessionTemplate batchExecutor;
>> Felix
>> From: mybatis-user@googlegroups.com
>> [mailto:mybatis-user@googlegroups.com]
>> On Behalf Of Rick R
>> Sent: Dienstag, 15. Mai 2012 18:42
>> To: mybatis-user@googlegroups.com
>> Subject: Re: More property setting woes ... even with MapperFactory
>> and PropertyPlaceholderConfigurer
>> Ok a bit more info... I removed the MapperScanner completely and now
>> in both apps (the original and the one I was going to provide as an
>> example), I defined *ALL* my mappers as MapperFactoryBeans and then
>> the properties get set just fine (after removing the
>> MapperScannerConfigurer.) Using MapperScannerConfigurer seems to mess
>> with things.. even when I have it defined as the docs point out using
>> sqlSessionFactoryBeanName:
>> I think I'm going to have to just be safe and rely on defining all my
>> Mappers in my xml :(.. sort of stinks since it's now one more ugly
>> piece of xml to maintain, but oh well. Possibly others aren't running
>> into this since
>> they:
>> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't
>> relying on auto-wiring of things.
>> I'd be interested in other examples out there of people using the
>> latest spring and spring-mybatis with multiple SqlSessionFactories
>> defined and using the MapperScannerConfigurer and leveraging auto-wiring
>> of mappers.
>> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
>> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
>> <eduardo.macar...@gmail.com> wrote:
>> Hi Rick. I am sorry I have not much time to get deeply into this
>> issues so sorry if I overlook something important.
>> The scanner is a bean that runs early during the spring startup
>> process. It runs before the propertiesplaceholderconfigurer so there
>> may be a problem with the place holders and you already know. But this
>> cannot happen with a MapperFactoryBean because it is a normal bean an
>> will be started once the propertiesplaceholderconfigurer has finished
>> so the problem must be elsewhere...
>> There definitely seems to be something odd going on though when you
>> use a combination of 1) multiple SqlSessionFactories and 2) mapper
>> scanner and a MapperFactoryBean definition.
>> For example, I'm trying to set up a simple example to show you what
>> I'm referring to, and based on this following code with more than one
>> SqlSessionFactoryBean defined... if you include the MapperFactoryBean
>> as part of the deployment, Spring can't decide which SqlSessionFactory
>> to bind to autowire as you can see in this highlighted screen shot:
>> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg >> HOWEVER, the odd thing is if I remove the MapperFactoryBean
>> definition, then there are no issues auto-wiring.
> -----Original Message-----
> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
> Sent: Thursday, January 24, 2013 6:28 PM
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
> Are you using mybatis-spring 1.1.1?
> There is a test with that exact scenario that passes OK.
>> All mappers directing to database_2/sglSessionFactory_2 are now going to
>> database_1. The reason is the Dual-Autowireing in SqlSessionDaoSupport.
>> The MapperScannerConfigurer now prefers the autowired sqlSessionTemplate
>> over the explicitly wired sqlSessionFactory. It should be the other way
>> around?
>> I even didn't see the point to use a sqlSessionTemplate template in
>> SqlSessionDaoSupport at all, since it creates a template with the
>> "sqlSessionFactory" anyways?
>> -----Original Message-----
>> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com]
>> On Behalf Of Eduardo Macarron
>> Sent: Donnerstag, 24. Januar 2013 16:38
>> To: mybatis-user@googlegroups.com
>> Subject: Re: More property setting woes ... even with MapperFactory and
>> PropertyPlaceholderConfigurer
>> Hi Felix,
>> If there is more than one factory then you cannot use autowire because you
>> need to specify which one should be injected in your mappers/daos.
>> Does it fail if you explicitly inject the right template?
>> 2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
>>> This problem/bug seems to be in the class
>>> SqlSessionDaoSupport
>>> It tries to autowire both, a sqlSessionFactory and a
>>> sqlSessionTemplate with @Autowired. If the later is found it will be
>>> used, regardless whether it belongs itself to the correct
>>> SqlSessionFactory. The requested SqlSession points to the wrong database
>>> in the end.
>>> This will lead to the effect, that you cannot use SqlSessionTemplate
>>> and MapperScanner together if multiple databases/SqlSessionFactories
>>> are defined.
>>> In my opinion, SqlSessionDaoSupport should not use @Autowired.
>>> One can overcome this problem by disabling autowireing for the
>>> SqlSessionTemplate:
>>> In your own service classes, you have to force autowireing with
>>> @Resource(name="batchExecutor")
>>> SqlSessionTemplate batchExecutor;
>>> Felix
>>> From: mybatis-user@googlegroups.com
>>> [mailto:mybatis-user@googlegroups.com]
>>> On Behalf Of Rick R
>>> Sent: Dienstag, 15. Mai 2012 18:42
>>> To: mybatis-user@googlegroups.com
>>> Subject: Re: More property setting woes ... even with MapperFactory
>>> and PropertyPlaceholderConfigurer
>>> Ok a bit more info... I removed the MapperScanner completely and now
>>> in both apps (the original and the one I was going to provide as an
>>> example), I defined *ALL* my mappers as MapperFactoryBeans and then
>>> the properties get set just fine (after removing the
>>> MapperScannerConfigurer.) Using MapperScannerConfigurer seems to mess
>>> with things.. even when I have it defined as the docs point out using
>>> sqlSessionFactoryBeanName:
>>> I think I'm going to have to just be safe and rely on defining all my
>>> Mappers in my xml :(.. sort of stinks since it's now one more ugly
>>> piece of xml to maintain, but oh well. Possibly others aren't running
>>> into this since
>>> they:
>>> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't
>>> relying on auto-wiring of things.
>>> I'd be interested in other examples out there of people using the
>>> latest spring and spring-mybatis with multiple SqlSessionFactories
>>> defined and using the MapperScannerConfigurer and leveraging auto-wiring
>>> of mappers.
>>> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
>>> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
>>> <eduardo.macar...@gmail.com> wrote:
>>> Hi Rick. I am sorry I have not much time to get deeply into this
>>> issues so sorry if I overlook something important.
>>> The scanner is a bean that runs early during the spring startup
>>> process. It runs before the propertiesplaceholderconfigurer so there
>>> may be a problem with the place holders and you already know. But this
>>> cannot happen with a MapperFactoryBean because it is a normal bean an
>>> will be started once the propertiesplaceholderconfigurer has finished
>>> so the problem must be elsewhere...
>>> There definitely seems to be something odd going on though when you
>>> use a combination of 1) multiple SqlSessionFactories and 2) mapper
>>> scanner and a MapperFactoryBean definition.
>>> For example, I'm trying to set up a simple example to show you what
>>> I'm referring to, and based on this following code with more than one
>>> SqlSessionFactoryBean defined... if you include the MapperFactoryBean
>>> as part of the deployment, Spring can't decide which SqlSessionFactory
>>> to bind to autowire as you can see in this highlighted screen shot:
>>> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg >>> HOWEVER, the odd thing is if I remove the MapperFactoryBean
>>> definition, then there are no issues auto-wiring.
-----Original Message-----
From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
Sent: Donnerstag, 24. Januar 2013 21:50
To: mybatis-user@googlegroups.com
Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
Felix, in that case, it would be really helpful that you can reproduce your error using that post so we can have a look at it.
2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
> Yes, it's 1.1.1.
> -----Original Message-----
> From: mybatis-user@googlegroups.com
> [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
> Sent: Thursday, January 24, 2013 6:28 PM
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory
> and PropertyPlaceholderConfigurer
> Are you using mybatis-spring 1.1.1?
> There is a test with that exact scenario that passes OK.
>> All mappers directing to database_2/sglSessionFactory_2 are now going
>> to database_1. The reason is the Dual-Autowireing in SqlSessionDaoSupport.
>> The MapperScannerConfigurer now prefers the autowired
>> sqlSessionTemplate over the explicitly wired sqlSessionFactory. It
>> should be the other way around?
>> I even didn't see the point to use a sqlSessionTemplate template in
>> SqlSessionDaoSupport at all, since it creates a template with the
>> "sqlSessionFactory" anyways?
>> -----Original Message-----
>> From: mybatis-user@googlegroups.com
>> [mailto:mybatis-user@googlegroups.com]
>> On Behalf Of Eduardo Macarron
>> Sent: Donnerstag, 24. Januar 2013 16:38
>> To: mybatis-user@googlegroups.com
>> Subject: Re: More property setting woes ... even with MapperFactory
>> and PropertyPlaceholderConfigurer
>> Hi Felix,
>> If there is more than one factory then you cannot use autowire
>> because you need to specify which one should be injected in your mappers/daos.
>> Does it fail if you explicitly inject the right template?
>> 2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
>>> This problem/bug seems to be in the class
>>> SqlSessionDaoSupport
>>> It tries to autowire both, a sqlSessionFactory and a
>>> sqlSessionTemplate with @Autowired. If the later is found it will be
>>> used, regardless whether it belongs itself to the correct
>>> SqlSessionFactory. The requested SqlSession points to the wrong
>>> database in the end.
>>> This will lead to the effect, that you cannot use SqlSessionTemplate
>>> and MapperScanner together if multiple databases/SqlSessionFactories
>>> are defined.
>>> In my opinion, SqlSessionDaoSupport should not use @Autowired.
>>> One can overcome this problem by disabling autowireing for the
>>> SqlSessionTemplate:
>>> In your own service classes, you have to force autowireing with
>>> @Resource(name="batchExecutor")
>>> SqlSessionTemplate batchExecutor;
>>> Felix
>>> From: mybatis-user@googlegroups.com
>>> [mailto:mybatis-user@googlegroups.com]
>>> On Behalf Of Rick R
>>> Sent: Dienstag, 15. Mai 2012 18:42
>>> To: mybatis-user@googlegroups.com
>>> Subject: Re: More property setting woes ... even with MapperFactory
>>> and PropertyPlaceholderConfigurer
>>> Ok a bit more info... I removed the MapperScanner completely and now
>>> in both apps (the original and the one I was going to provide as an
>>> example), I defined *ALL* my mappers as MapperFactoryBeans and then
>>> the properties get set just fine (after removing the
>>> MapperScannerConfigurer.) Using MapperScannerConfigurer seems to
>>> mess with things.. even when I have it defined as the docs point out
>>> using
>>> sqlSessionFactoryBeanName:
>>> I think I'm going to have to just be safe and rely on defining all
>>> my Mappers in my xml :(.. sort of stinks since it's now one more
>>> ugly piece of xml to maintain, but oh well. Possibly others aren't
>>> running into this since
>>> they:
>>> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't
>>> relying on auto-wiring of things.
>>> I'd be interested in other examples out there of people using the
>>> latest spring and spring-mybatis with multiple SqlSessionFactories
>>> defined and using the MapperScannerConfigurer and leveraging
>>> auto-wiring of mappers.
>>> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
>>> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
>>> <eduardo.macar...@gmail.com> wrote:
>>> Hi Rick. I am sorry I have not much time to get deeply into this
>>> issues so sorry if I overlook something important.
>>> The scanner is a bean that runs early during the spring startup
>>> process. It runs before the propertiesplaceholderconfigurer so there
>>> may be a problem with the place holders and you already know. But
>>> this cannot happen with a MapperFactoryBean because it is a normal
>>> bean an will be started once the propertiesplaceholderconfigurer has
>>> finished so the problem must be elsewhere...
>>> There definitely seems to be something odd going on though when you
>>> use a combination of 1) multiple SqlSessionFactories and 2) mapper
>>> scanner and a MapperFactoryBean definition.
>>> For example, I'm trying to set up a simple example to show you what
>>> I'm referring to, and based on this following code with more than
>>> one SqlSessionFactoryBean defined... if you include the
>>> MapperFactoryBean as part of the deployment, Spring can't decide
>>> which SqlSessionFactory to bind to autowire as you can see in this highlighted screen shot:
>>> https://img.skitch.com/20120515-s9w2t9eb2p1cu7qj3t46axehk.jpg >>> HOWEVER, the odd thing is if I remove the MapperFactoryBean
>>> definition, then there are no issues auto-wiring.
Thanks for filling the issue. I think I managed to provide a fix for
it please give it a try.
Regarding the @Autoriwred annotations, I do also think they do more
harm than good.
We used them to autowire the factory beans generated by the scanner
but I think that can also be achieved by activating the autowire only
for that beans during its creation:
if (!explicitFactoryUsed && !explicitTemplateUsed) {
definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE);
}
The problem is that I am afraid that removing @Autowire is a breaking
change and it is too late for that. :(
2013/1/25 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
> -----Original Message-----
> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
> Sent: Donnerstag, 24. Januar 2013 21:50
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
> Felix, in that case, it would be really helpful that you can reproduce your error using that post so we can have a look at it.
> 2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
>> Yes, it's 1.1.1.
>> -----Original Message-----
>> From: mybatis-user@googlegroups.com
>> [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
>> Sent: Thursday, January 24, 2013 6:28 PM
>> To: mybatis-user@googlegroups.com
>> Subject: Re: More property setting woes ... even with MapperFactory
>> and PropertyPlaceholderConfigurer
>> Are you using mybatis-spring 1.1.1?
>> There is a test with that exact scenario that passes OK.
>>> All mappers directing to database_2/sglSessionFactory_2 are now going
>>> to database_1. The reason is the Dual-Autowireing in SqlSessionDaoSupport.
>>> The MapperScannerConfigurer now prefers the autowired
>>> sqlSessionTemplate over the explicitly wired sqlSessionFactory. It
>>> should be the other way around?
>>> I even didn't see the point to use a sqlSessionTemplate template in
>>> SqlSessionDaoSupport at all, since it creates a template with the
>>> "sqlSessionFactory" anyways?
>>> -----Original Message-----
>>> From: mybatis-user@googlegroups.com
>>> [mailto:mybatis-user@googlegroups.com]
>>> On Behalf Of Eduardo Macarron
>>> Sent: Donnerstag, 24. Januar 2013 16:38
>>> To: mybatis-user@googlegroups.com
>>> Subject: Re: More property setting woes ... even with MapperFactory
>>> and PropertyPlaceholderConfigurer
>>> Hi Felix,
>>> If there is more than one factory then you cannot use autowire
>>> because you need to specify which one should be injected in your mappers/daos.
>>> Does it fail if you explicitly inject the right template?
>>> 2013/1/24 Kurth, Felix <Felix.Ku...@globalfoundries.com>:
>>>> This problem/bug seems to be in the class
>>>> SqlSessionDaoSupport
>>>> It tries to autowire both, a sqlSessionFactory and a
>>>> sqlSessionTemplate with @Autowired. If the later is found it will be
>>>> used, regardless whether it belongs itself to the correct
>>>> SqlSessionFactory. The requested SqlSession points to the wrong
>>>> database in the end.
>>>> This will lead to the effect, that you cannot use SqlSessionTemplate
>>>> and MapperScanner together if multiple databases/SqlSessionFactories
>>>> are defined.
>>>> In my opinion, SqlSessionDaoSupport should not use @Autowired.
>>>> One can overcome this problem by disabling autowireing for the
>>>> SqlSessionTemplate:
>>>> In your own service classes, you have to force autowireing with
>>>> @Resource(name="batchExecutor")
>>>> SqlSessionTemplate batchExecutor;
>>>> Felix
>>>> From: mybatis-user@googlegroups.com
>>>> [mailto:mybatis-user@googlegroups.com]
>>>> On Behalf Of Rick R
>>>> Sent: Dienstag, 15. Mai 2012 18:42
>>>> To: mybatis-user@googlegroups.com
>>>> Subject: Re: More property setting woes ... even with MapperFactory
>>>> and PropertyPlaceholderConfigurer
>>>> Ok a bit more info... I removed the MapperScanner completely and now
>>>> in both apps (the original and the one I was going to provide as an
>>>> example), I defined *ALL* my mappers as MapperFactoryBeans and then
>>>> the properties get set just fine (after removing the
>>>> MapperScannerConfigurer.) Using MapperScannerConfigurer seems to
>>>> mess with things.. even when I have it defined as the docs point out
>>>> using
>>>> sqlSessionFactoryBeanName:
>>>> I think I'm going to have to just be safe and rely on defining all
>>>> my Mappers in my xml :(.. sort of stinks since it's now one more
>>>> ugly piece of xml to maintain, but oh well. Possibly others aren't
>>>> running into this since
>>>> they:
>>>> 1) Aren't defining multiple SqlSessionFactories and/or 2) aren't
>>>> relying on auto-wiring of things.
>>>> I'd be interested in other examples out there of people using the
>>>> latest spring and spring-mybatis with multiple SqlSessionFactories
>>>> defined and using the MapperScannerConfigurer and leveraging
>>>> auto-wiring of mappers.
>>>> On Tue, May 15, 2012 at 12:18 PM, Rick R <ric...@gmail.com> wrote:
>>>> On Tue, May 15, 2012 at 11:07 AM, Eduardo Macarron
>>>> <eduardo.macar...@gmail.com> wrote:
>>>> Hi Rick. I am sorry I have not much time to get deeply into this
>>>> issues so sorry if I overlook something important.
>>>> The scanner is a bean that runs early during the spring startup
>>>> process. It runs before the propertiesplaceholderconfigurer so there
>>>> may be a problem with the place holders and you already know. But
>>>> this cannot happen with a MapperFactoryBean because it is a normal
>>>> bean an will be started once the propertiesplaceholderconfigurer has
>>>> finished so the problem must be elsewhere...
>>>> There definitely seems to be something odd going on though when you
>>>> use a combination of 1) multiple SqlSessionFactories and 2) mapper
>>>> scanner and a MapperFactoryBean definition.
>>>> For example, I'm trying to set up a simple example to show you what
>>>> I'm referring to, and based on this following code with more than
>>>> one SqlSessionFactoryBean defined... if you include the
>>>> MapperFactoryBean as part of the deployment, Spring can't decide
>>>> which SqlSessionFactory to bind to autowire as you can see in this highlighted screen shot:
Eduardo,
you're your code change seems to fix the issue. Thank you.
Yes, in my opinion these @Autowire annotations should be avoided. Both, from sqlSessionTemplate and sqlSessionFactory.
I would even go further and throw an exception if the user tries to wire both, a factory and a template since wiring both makes no sense and usually causes problems/undefined state.
BtW. in "SQLSessionTemplate" (trunk) there has been a function added
@Override
public void destroy() throws Exception {
// fix to avoid Spring 3.2 complaining that calling close() fails
}
This seems to work only with Spring 3.2, not with 3.1 as the pom requests.
Please remove "@Override" to fix this.
Cosmetic problem: In the code changes, your refer to the bug number 762, actually it's 763
-----Original Message-----
From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
Sent: Sonntag, 27. Januar 2013 09:57
To: mybatis-user@googlegroups.com
Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
Felix, I think we can remove the @Autowire from setSqlSessionTemplate.
I hope that removes some of the know weird side effects.
Just a few people may be affected by the change so I think it is worth.
We are not so sure about removing also the @Autowire from setSqlSessionFactory but are open to users opinion.
What do you think? Should we remove both for MyBatis-Spring 1.2.0?
It's probably simpler to break the compatibility and provide a
migration guide. Also most users probably work with a single
datasource so the impact might be minimal.
<Felix.Ku...@globalfoundries.com> wrote:
> Eduardo,
> you're your code change seems to fix the issue. Thank you.
> Yes, in my opinion these @Autowire annotations should be avoided. Both, from sqlSessionTemplate and sqlSessionFactory.
> I would even go further and throw an exception if the user tries to wire both, a factory and a template since wiring both makes no sense and usually causes problems/undefined state.
> BtW. in "SQLSessionTemplate" (trunk) there has been a function added
> @Override
> public void destroy() throws Exception {
> // fix to avoid Spring 3.2 complaining that calling close() fails
> }
> This seems to work only with Spring 3.2, not with 3.1 as the pom requests.
> Please remove "@Override" to fix this.
> Cosmetic problem: In the code changes, your refer to the bug number 762, actually it's 763
> -----Original Message-----
> From: mybatis-user@googlegroups.com [mailto:mybatis-user@googlegroups.com] On Behalf Of Eduardo Macarron
> Sent: Sonntag, 27. Januar 2013 09:57
> To: mybatis-user@googlegroups.com
> Subject: Re: More property setting woes ... even with MapperFactory and PropertyPlaceholderConfigurer
> Felix, I think we can remove the @Autowire from setSqlSessionTemplate.
> I hope that removes some of the know weird side effects.
> Just a few people may be affected by the change so I think it is worth.
> We are not so sure about removing also the @Autowire from setSqlSessionFactory but are open to users opinion.
> What do you think? Should we remove both for MyBatis-Spring 1.2.0?
