Develop Reference

MyBatis MapperScannerConfigurer to scan base package from classpath

I have configured MapperScannerConfigurer in spring application context as follow:
<bean name="mapperScannerConfigurer" class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="sqlSessionFactoryBeanName" value="sqlSessionFactory" />
<property name="basePackage" value="path.to.package.from.classpath.dao" />
</bean>
Here basePackage is in a jar file that is set in classpath.
One of the mapper from the package is autowired in the one of the services I am using. Looks like MyBatis is failing here to scan package from classpath as I am getting error stating no such Bean found:
No qualifying bean of type 'path.to.package.from.classpath.dao.UserMapper' available: expected at least 1 bean which qualifies as autowire candidate.
I have searched online and found nothing which has similar scenario.

I am going to answer here my own question as it may help someone facing the similar issue.
The problem was in the way I created jar in the first place. iBatis might have a different way of scanning the packages as it was working and I thought the same could work with MyBatis. But MyBatis may have a different mechanism for scanning packages. It appears it is looking for directory entries in the jar and if it does not find it, it will throw this exception. So make sure you choose the option Add directory entries while creating the jar as shown below:

java.lang.ClassNotFoundException When Filepath is Correct

I'm working with Spring right now and have been trying to resolve a number of Failed to load ApplicationContext errors. This latest one is because it can't find a specific class when creating a bean structured like the following:
<bean id="problematicBean"
class="com.domain.application.search.problematicBean">
<property name="missingClass">
<bean class="com.domain.application.search.MissingClass">
</bean>
</property>
</bean>
I've triple checked and the filepath used in the bean class is correct. Other beans with identical paths (at least to the point of applicaiton) work perfectly. The file exists exactly where it should be for this classpath to work. The only difference is that this is a groovy file. Does anyone know why my application can't find the class?

What is the logic behind creating Autowired instance in case if container is having multiple instance

I have a question regarding Autowiring. Let me explain the scenario first.
I have 3 projects. ProjectA, ProjectB ,ProjectC. ProjectA is having dependency of ProjectB and ProjectC through pom.xml.
I have class Test.java in ProjectA which is having a property :
#Autowired
JdbcTemplate jdbcTemplate;
ProjectB and ProjectC each having following entry in their respective context xml file :
<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
<property name="dataSource" ref="dataSource" />
</bean>
Now, My question is,JdbcTemplate instance of which project (ProjectB or ProjectC ? ) above mentioned Autowired proeprty will refer to?
In other words , Based on what logic it will create that instance ?

I would simplify things little bit. Let me call ProjectA the Application and ProjectB and ProjectC the libraries.
Usually a library doesn't have to have context.xml or any other spring configuration inside, because it will not have a DI container of its own - the application (that uses it) will. So the application has a configuration of DI container and the application's configuration decides how to instantiate dependencies.
I believe this is true even if a library contains some spring configurations - those should be ignored.

How to get hibernate mapping files from another project using xml based config?

I'm working with spring and hibernate. Currently I have the context config file like this
<bean id="sessionFactory"
class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<!-- other properties -->
<property name="mappingDirectoryLocations" value="classpath:mappings/" />
</bean>
the *.hbm.xml mappings are in the same project.
Now I plan to pull some entities together with the mappings out, so they can be shared with other projects. The question is, how should I configure the sessionFactory bean to get *.hbm.xml files from the newly created project?
I tried mappingJarLocations but got error saying that the class path is not valid.

Instead of classpath: use classpath*:.
Check What is the difference between "classpath:" and "classpath:/" in Spring XML? for a extended answer on the differences between the 2.

AFASIK, Hibernate looks for mentioned hbm files in all the jars in classpath. You need to mention only the files.

Importing Spring beans from other Maven modules inside a WAR?

I have a new web app that is packaged as a WAR as part of a multi-module Maven project. The applicationContext.xml for this WAR references beans that are imported from the "service" module, which in turn imports beans from the "dao" module. The import statement in applicationContext.xml looks like this:
<import resource="classpath*:service.xml" />
and the one inside the service.xml file looks like this:
<import resource="classpath*:dao.xml" />
Neither Spring STS, nor Eclipse show any warnings or errors in my bean files. I reference the imported beans all over the place. The Maven build works fine and the DAO integration tests all pass (they use the beans). I don't have any service integration tests yet.
But when I start up the WAR in Jetty I get an error:
Error creating bean with name 'securityService'
Cannot resolve reference to bean 'userDAO' while setting constructor argument
All of the imported bean XML files can be found inside their respective JAR files in the WEB-INF/lib directory. Indeed, the service bean that threw the error is itself defined inside the service.xml file inside the service module's JAR file.
Apparently the service module can't find the bean that it imported from the dao module. Obviously I don't understand something...seems like this should this Just Work?

I enabled DEBUG logging for 'org.springframework' in order to see if I could learn anything. What I found were messages to the effect that the DAO beans had been created, but there was also a message about them having no name or id.
I check the file, and they all did have an id. So what was it? I check the XML namespace and saw:
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"
and noticed it was old (I am using Spring 3.0.2) and changed it to:
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
Once I changed it, Spring instantly threw half a dozen errors regarding beans that were defined incorrectly (but never used apparently). Once I fixed those errors, everything Just Worked. I've since gone through the entire system checking Spring XML file namespace versions.
Thanks to all for the help. Can't believe I wasted a day on this stupidity!!

The difference between the classpath:thingy.xml and classpath*:thingy.xml notation is that the former uses the standard classpath mechanism to resolve one resource (using ClassLoader.getResource(name)), whereas the latter will use ClassLoader.getResources(name) to retrieve all matching resources on the classpath, a distinction that should be irrelevant in your situation as I guess there is only one dao.xml file on the class path.
I think your problem is different, you are missing a leading slash.
Use this for a single resource
<import resource="classpath:/dao.xml" />
and this for multiple resources
<import resource="classpath*:/dao.xml" />
See
Spring Reference: The classpath*
prefix
Sun JavaDocs: ClassLoader

It should be like
<import resource="classpath:service.xml"/>

Are you having multiple applicationContexts and possibly the parent context is referring to a bean defined in the child context?