I'm using Spring 3.2.0 in a legacy project with Mybatis 3.3.0 and Mybatis Spring 1.2.3.
I have several projects that use this technology and they need to have similar new code added to a library that will allow me to interact with an outside system, and during this interaction I need to call several methods in the database in this new code.
I created an interface and put it in a package, say:
com.mycompany.myapp.dao.MyNewService
That interface has a few methods. All of those are defined in a Mybatis mapper file, MyNewService.xml in that same package path.
I create a .jar file of all this code.
In my main application, I added a dependency to this .jar file and it ends up inside of WEB-INF\lib\MyHelpers.jar
In that application, I have a root application context spring file and I attempt to use a mybatis MapperScannerConfigurer to find this new bean/service via:
<!--scan for mappers and let them be autowired -->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.mycompany.myapp.dao" />
<property name="sqlSessionFactoryBeanName"
value="sqlSessionFactory" />
</bean>
When I run this code, it appears that it cannot find this service in that package path which I know is in WEB-INF\lib\MyHelpers.jar.
The application produces a warning on startup:
WARN (ClassPathMapperScanner.java:167) - No MyBatis mapper was
found in '[com.mycompany.myapp.dao]' package.
Please check your configuration.
The code later fails during dependency injection with a massive stacktrace which essentially says:
2017-03-08 15:38:39,625 [[ACTIVE] ExecuteThread: '0' for queue:
'weblogic.kernel.Default (self-tuning)'] ERROR
(org.springframework.web.servlet.DispatcherServlet:466) - Context
initialization failed
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'orderDetailsController': Injection of
autowired dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not
autowire field: private com.mycompany.myapp.dao.MyNewService
com.mycompany.otherapp.controller.OrderDetailsController.myNewService
; nested exception is
org.springframework.beans.factory.NoSuchBeanDefinitionException: No
matching bean of type [com.mycompany.myapp.dao.MyNewService ] found
for dependency: expected at least 1 bean which qualifies as autowire
candidate for this dependency. Dependency annotations:
{#org.springframework.beans.factory.annotation.Autowired(required=true)}
If I dig into that Mybatis code, its simply not finding the resource from the package path inside that .jar when it's using some ResourceResolver code. IF I move my code into my project directly rather than adding the .jar dependency, the code works fine without error.
The concern of course is that I have to put this same code across six projects, so I thought I'd have it in this .jar file and use the MapperScannerConfigurer. We use that in all the projects but all the .xml is within the applications WEB-INF\classes when deployed, it is not inside a .jar file within WEB-INF\lib.
Any ideas how to accomplish this? In summary, it would be akin to:
Making a file called Model.jar based on Mybatis interfaces and .xml mapper files
Adding this as a dependency that appears in WEB-INF\lib
configuring the main spring applicationContext file using the syntax I have above.
If you need more clarification, I can certainly add it.
Related
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:
We have an application where one of our internal libraries has defined a bean like this
<bean id="myBean" class="${myBean.type}"/>
We have a Spring Cloud Config Server which feeds properties to this application on startup, which also contains the property myBean.type. This setup is currently working fine with no issues. I then made the following change to my pom
Earlier
<spring.boot.version>1.5.16.RELEASE</spring.boot.version>
<spring.cloud.version>Edgware.RELEASE</spring.cloud.version>
<spring.version>4.3.19.RELEASE</spring.version>
Now
<spring.boot.version>2.0.9.RELEASE</spring.boot.version>
<spring.version>5.0.13.RELEASE</spring.version>
<spring.cloud.version>Finchley.SR2</spring.cloud.version>
Then I started getting this error on startup
An attempt was made to call the method org.springframework.beans.factory.support.BeanDefinitionBuilder.addConstructorArg(Ljava/lang/Object;)Lorg/springframework/beans/factory/support/BeanDefinitionBuilder; but it does not exist. Its class, org.springframework.beans.factory.support.BeanDefinitionBuilder, is available from the following locations:
jar:file:/I:/Library/MavenRepository/org/springframework/spring-beans/5.0.13.RELEASE/spring-beans-5.0.13.RELEASE.jar!/org/springframework/beans/factory/support/BeanDefinitionBuilder.class
It was loaded from the following location:
file:/I:/Library/MavenRepository/org/springframework/spring-beans/5.0.13.RELEASE/spring-beans-5.0.13.RELEASE.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.springframework.beans.factory.support.BeanDefinitionBuilder
Looking at this, I excluded the artifact org.apache.cxf:cxf-api:jar:2.7.18:compile from all the jars that depended on it & upgraded cxf jars versions to 3.2.5. Now the startup is going ahead but it is giving me the following error:
org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [${myBean.type}] for bean with name 'myBean' defined in class path resource [xyz.xml]; nested exception is java.lang.ClassNotFoundException: ${myBean.type}
I am not sure if removal of cxf-api is causing this issue, or upgrade of Spring Boot 2, or is it something else that is going wrong here!
I am developing a simple maven + spring application and i am getting the following error. It says two of my classes have a conflict. so i deleted the second class but i am still getting the same error. I tried restarting the server but it still says my class exists. Can somebody help?
Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse configuration class [com.nibm.config.RootConfig]; nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'employeeController' for bean class [com.nibm.hibernate.controller.EmployeeController] conflicts with existing, non-compatible bean definition of same name and class [com.nibm.controller.EmployeeController]
I was able to solve a similar problem by using IntelliJ's function "Rebuild".
The reason was an orphan .class file after the corresponding .java file had already been deleted.
You get the exception because you have two spring beans of the same class.
This exception is thrown by
org.springframework.context.annotation.ClassPathBeanDefinitionScanner#isCompatible
And looking at that implementation it looks as if you create a bean of type EmployeeController in your RootConfig and additionally by ComponentScan.
To fix the problem remove the bean from the RootConfig or change your ComponentScan, so this bean is not found by it.
You can set a breakpoint in the constructor of EmployeeController. From the stack you can get more information about how and why the bean is created.
I faced the same problem and it was because class with same name exist at two locations as mentioned in the Exception itself which are conflicting and after removing one issue got fixed.
I was getting this same ConflictingBeanDefinitionException..."conflicts with existing, non-compatible bean definition of same name and class" when running JUnit tests with #RunWith(SpringRunner.class)/ #SpringBootTest from inside Intellij.
Execution via gradle:build of the same tests were running fine.
This began to happen after I had refactored the packaging of several #Components which lead me to believe something was holding a reference to the class under it's previous package name.
No amount of gradle build/clean would seem to clear it.
Doing a Build -> Rebuild Project in IntelliJ was what cleared this issue for me.
I'm using Spring 2.5.4 and am creating a Java application that I'm deploying onto Weblogic.
I have a class in an external library (which included in the WEB-INF/classes directory of the resulting WAR file of my application) that I want to use in my code. I've created an instance variable for an object of the class in my code and added the #Autowired annotation and a getter and setter. In my application context file I have declared a bean of the library class' type and added the following:
<context:annotation-config />
<context:component-scan base-package="com.mycompany" />
... in order to register an AutowiredAnnotationBeanPostProcessor that will scan the classes and process the annotation.
When I try and deploy the application, I get the following error:
java.lang.IllegalStateException: Annotation-specified bean name 'myBean' for bean
class [com.mycompany.package.ClassName] conflicts with existing, non-compatible
bean definition of same name and class [com.mycompany.otherPackage.ClassName]
I think this is because there's a class in the library which has the same name as one in my application code (both class' package names start with "com.mycompany"). Nb. this is NOT the class that I have added, but a different one. Is there any way I can circumvent this problem without changing the name of the class in my application?
Thanks for any assistance.
Old question but throwing my 2c of bad experience with similar problem.
If you have 2 classes with same name, but in different packages was there a time when you had your other class referenced by the failing Spring context? If so, I'd recommend to clean the AS cached files (typically the place where the WAR is extracted), clean/rebuild your WAR and deploy again. Restarting the app server is also recommended.
I found that application servers and web containers alike (Weblogic, WAS, Jboss, Tomcat) tend to leave behind the old classes and when application is deployed those stale .class files are loaded in JVM via some old references, which most of the time messes up the Spring context loader.
Typical scenario is when you have renamed/moved a class from one package to another, or even kept the package name the same but moved it to another module (jar). In such cases cached (left over) files in the AS work directory can cause big headaches. Wiping out the work directory in your AS should resolve the issue outright.
You should use #qualifier to avoid this kind of conflict please refer section 3.9.3.
I fixed the problem by removing the autowiring completely and accessing the bean by explicitly creating a reference to it through the application context and the getBean() method.
This would better fit as a comment to #Pavel Lechev's answer, but I don't have enough rep to comment yet.
For other's finding this, here's what I did to solve this problem. I am using Wildfly 9.0.2.Final and, IntelliJ IDEA 2016.1.3 Build #IU-145.1617. These steps should presumably work with JBoss as well.
Stop Wildfly server.
Navigate to $WILDFLY_HOME/standalone/. Delete the three following folders: lib/, log/ and temp/.
In IntelliJ, Build > Build Artifacts > All Artifacts > Clean (or just the artifacts you are deploying).
In IntelliJ, Build > Rebuild Project
Restart Wildfly and redeploy your artifact(s).
These steps remedied my issue of duplicate bean names detected in the Spring context after refactoring a package name upstream from a couple of Controllers.
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?