Develop Reference

Spring Boot 2 Upgrade not able to resolve class name as property

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!

Flyway can't find classpath:db/migrations

I just started right now a new project in Intellij using Spring Boot ver 2.1.3 and Flyway 5.2.4 with Java 11.
After try to start my project i got :
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flyway' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.flywaydb.core.Flyway]: Factory method 'flyway' threw exception; nested exception is java.lang.IllegalStateException: Cannot find migrations location in: [classpath:db/migration] (please add migrations or check your Flyway configuration)
I have the following folders:
As you can see i have "db/migration" but without any migration, i just started right now. Debugging the class FlywayAutoConfiguration i got the following:
So, i tried to return all files in "classpath:", see:
Note that i just have "application.properties" file.

It is not that much useful or accurate answer.
But This issue make you frustrated so that i give this solution.
Note: Strange but it's true, Sometime it's not allow copy paste because your folder created db.migration and it expact db->migration(It's not same in this scenario). So whenever you start from scratch. Go to the resource folder -> Create DB folder -> Create migration folder -> Create database file with Version_SubVersion__Name(As defined below).
Normally this happens in following cases,
Path is not proper try using set locations param value.
db.migrate folder not contain any file.
Check name of file : V1_1__(short_desc)
Try to run using, mvn compile flyway:migrate
In my case i already place sql file over there but still it gives same error,
Basically i place this sql file using copy paste from somewhere.
When i try to add one new file on same place using IDE (Intellij : Right click on migration folder -> new -> Flyway migration -> versioned migration), then it ask me(warning) about some delicate allowance(normally we mention in database configuration i also place there still), and it start working.

Flyway requires at-least one script, disable it until u need it by using following command in application.properties file
spring.flyway.enabled=false

I believe that Flyway requires at least one migration script to initialize. Try adding a simple sql creation script into your migration folder and give it another try. Alternatively you can disable the flyway dependency until you need it.

I had a similar error, and solved it as follows: I added these commands
spring.flyway.baselineOnMigrate=true
spring.flyway.check-location=true
spring.flyway.locations=classpath:db/migration
spring.flyway.schemas=public
spring.flyway.enabled=true
to application.properties

I had the same issue. When I created the directory, I simply typed db.migration - the same way one would do with package names. InteliJ will display both db.migration and db/migration directories as db.migration, so while it may look correct in IntelliJ, flyway requires the latter.

Even when having your migration files in the db/migration folder, flyway won't detect it.
Then you will have to fix this by explicitly setting the locations in your application.properties (or appliocation.yml) by adding:
spring.flyway.locations=classpath:db/migration
N.B: Also you need to have at least one script to initialize flyway, you can even put an empty one. But you need to have at least one script

As #Guy suggested in his answer, I created an SQL file in the migration folder and left it empty. Named v1_0__mock_flyway.sql in the migration folder classpath:db/migration. Error solved.

If you have tried everything above and it still does not apply the migrations.
Be sure you have followed the steps in the previous answers
A db.migration folder exists in your resources folder
The sql scripts are named with respect to the correct naming convention, such as V1__init.sql
The following config exists in your application.properties/application.yml
spring.flyway.locations=classpath:db/migration
Do a clean build
-> mvn clean
Then restart your spring boot app, this worked for me.

Spring XML files are not being found by Maven exec

Summary: I have a very basic Java 1.8 and Spring 4.0.5 project, I'm using Maven 3.2.3 to manage it. Maven exec cannot seem to see my Spring context, even though it appears to me that it is in the classpath.
My spring context is in
<project root>/src/main/resources/spring/ch2-beans.xml
and I load it using:
ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("/spring/ch2-beans.xml");
after a "mvn clean compile" I see
<project root>/target/classes/spring/ch2-beans.xml
and when I run:
mvn -X exec:java -Dexec.mainClass="com.wiley.beginning.spring.ch2.Main"
I see the following debug output which makes me think the classpath is indeed correct:
[DEBUG] Collected project classpath [/Users/me/Documents/workspace/BeginningSpring/chapter2/spring-book-ch2/target/classes]
[DEBUG] Adding to classpath : file:/Users/me/Documents/workspace/BeginningSpring/chapter2/spring-book-ch2/target/classes/
Yet I get the following error:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [spring/ch2-beans.xml]; nested exception is java.io.FileNotFoundException: class path resource [spring/ch2-beans.xml] cannot be opened because it does not exist
Can anyone point me in the direction of sorting this out? What I've posted above is the result of many different attempts to solve this, and I'm stumped by the error when it certainly appears that the file path should be in the classpath, so perhaps this is something that has changed since I last coded (a while ago..). Thanks!
Update..
Thinking that it might be some classpath issue with exec:java I ran the same code inside a unit test, executed within maven. Same error. I've also tried loading the xml file as "classpath:/spring/ch2-beans.xml", did not fix it.

There was a hyphen in the file name of the Spring configuration I was trying to load, and it appears that the classloader won't accept that. Hyphens are illegal in identifier names in Java, apparently this applies also to external resources.
Once I removed the hyphen from the xml file name, it was found.
On a related note, I'm pretty annoyed with the "Beginning Spring" book example which uses these hyphenated names.

Annotation-specified bean name conflicts with existing, non-compatible bean definition

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.

CDI stops working when using weld-se-core and weld-servlet-core?

I am playing with Weld-SE. I have a project which has pluggable modules. With one module, weld works. When other module, which uses weld-servlet-core, is put on classpath (with it's deps), CDI stops working, giving errors like "Unable to resolve dependency XY" or (after removing that #Inject) this:
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor</class> in jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml#11 is neither annotated #Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466)
...
Although the class has #Interceptor (and the same class works fine with the other module).
When I debug WeldBootstrap#startContainer(Environment environment, Deployment deployment),
deployment.beanDeploymentArchive.beanClasses contains the interceptor
("org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor").
I've checked the dependencies and TattleTale report, they all seem fine.
Any ideas what should I look at / try next?
The project is at http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0/ To see the error, run mvn dependency:copy-dependencies java -cp ... org.jboss.jawabot.JawaBotApp Or simply run the web module in NetBeans.
Thanks, Ondra
Update: JIRA: https://issues.jboss.org/browse/WELD-940
Also, I found that it might be caused by a bug in Weld's scanning extension, <weld:scan>.

It was caused by using Weld's scanning extension, <weld:scan>:
An <includes> element contained package wildcard which resulted in matching classes in both "packages" (which is .jar in CDI / Weld's terminology IIUC).
I am not sure if I used it improperly or it's a bug.
See JIRA: https://issues.jboss.org/browse/WELD-940