We are upgrading our existing Spring Boot (1.5) application to 2.0.0.
We connect with multiple databases and use the org.springframework.boot.autoconfigure.jdbc.DataSourceBuilder class.
I added the dependency:
compile group: 'org.springframework.boot',
name: 'spring-boot-autoconfigure',
version: '2.0.0.RELEASE'
However, I am not able to compile the project: This class (DataSourceBuilder) does not exist in the 2.0.0 version jar.
In order to rule out gradle issues, I manually downloaded the jar and added it to the classpath. This class does not exist in the version.
Also extracted and searched the jar but this class is missing.
Can anyone help me resolve it?
The class was moved to another package. Its FQN is now org.springframework.boot.jdbc.DataSourceBuilder: https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/jdbc/DataSourceBuilder.html
Old class (Spring Boot 1.x)
org.springframework.boot.autoconfigure.jdbc.DataSourceBuilder
New class (Spring Boot 2.x)
import org.springframework.boot.jdbc.DataSourceBuilder;
Related
I try to import a custom .dll inside my Gradle project. I add the dependencie inside build.gradle
dependencies {
implementation group: 'net.java.dev.jna', name: 'jna', version: '5.6.0'
}
but when I try to run the gradle build I receive this error
..java:170: error: cannot find symbol
CustomLibrary INSTANCE = (CustomLibrary) Native.load("xxx", CustomLibrary.class);
^
symbol: method load()
location: class Native
1 error
Any suggestions?
You have a transitive dependency on an older version of JNA in another dependency.
As you have tagged this with spring boot that is the likely cause. Older Spring Boot versions used a 4.x (I think 4.3) JNA dependency and the syntax has changed.
The POM for Spring Boot uses a property jna.version that you could override if you were using Maven, but I don't think that is (easily) possible using Gradle. However, updating to the latest version of Spring Boot should solve your problem.
I want to migrate old Spring project which is using this dependency:
org.springframework.boot.actuate.autoconfigure.endpoint.condition.ConditionalOnEnabledEndpoint
This Class requires import of:
'org.springframework.boot:spring-boot-actuator-autoconfigure:2.0.2.RELEASE'
I tried to use the latest version:
'org.springframework.boot:spring-boot-actuator-autoconfigure:2.6.4' but ConditionalOnEnabledEndpoint is not available. Do you know which class should be used?
It doesn't exist anymore (see https://docs.spring.io/spring-boot/docs/2.6.4/api/). In version 2.2.0 it was deprecated in favour of #ConditionalOnAvailableEndpoint (see https://docs.spring.io/spring-boot/docs/2.2.0.RELEASE/api/org/springframework/boot/actuate/autoconfigure/endpoint/condition/ConditionalOnEnabledEndpoint.html).
I am trying to set up sentry in my project with version 1.7.30. It is a spring boot project with gradle, i am using the sentry spring boot starter dependency with:
implementation group: 'io.sentry', name: 'sentry-spring-boot-starter', version: '1.7.30'
implementation group: 'io.sentry', name: 'sentry-logback', version: '1.7.30'
I have a company sentry dashboard for this version. I have set the DNS in application.properties. My application.properties look like this:
sentry.dsn=xxxxx
I am able to capture the exception with Sentry.capture(e) any where, but while using lombok, with #Slf4j annotation logging, with log.error(e) I am unable to capture exception and its not reflecting in my dashboard. I have tried it with version 4.3 and it was working in that. But once i came to version 1.7.30 i am only able to do it manually with Sentry.capture() function.
You're mixing configuration options from Sentry SDK 3.x+ with Sentry 1.7.x. Sentry + Logback auto-configuration and properties like sentry.logging.minimum-event-level works only in the new SDK.
If you must use 1.7.x you have to configure Logback appender in logback.xml.
https://docs.sentry.io/platforms/java/legacy/logback/
I've built my own starter and the autoconfigure step fails with dependency conflict.
These are the spring boot versions both my starter and upstream project are using
'spring-boot-gradle-plugin', version2.1.8.RELEASE
'spring-boot-autoconfigure', version: '2.4.1'
***************************
APPLICATION FAILED TO START
***************************
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration$EnableWebMvcConfiguration.lambda$addResourceHandlers$0(W
ebMvcAutoConfiguration.java:411)
The following method did not exist:
'org.springframework.web.servlet.config.annotation.ResourceHandlerRegistration org.springframework.web.servlet.config.annotation.Re
sourceHandlerRegistration.addResourceLocations(org.springframework.core.io.Resource[])'
The method's class, org.springframework.web.servlet.config.annotation.ResourceHandlerRegistration, is available from the following loca
tions:
jar:file:/opt/eureka/app.jar!/BOOT-INF/lib/spring-webmvc-5.3.2.jar!/org/springframework/web/servlet/config/annotation/ResourceHandl
erRegistration.class
The class hierarchy was loaded from the following locations:
org.springframework.web.servlet.config.annotation.ResourceHandlerRegistration: jar:file:/opt/eureka/app.jar!/BOOT-INF/lib/spring-we
bmvc-5.3.2.jar!/
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.springframework.web.servlet.config.an
notation.ResourceHandlerRegistration
From your log I see one of two possible problems:
Somewhere you override spring-webmvc-5.3.2 to a higher or lower version
Problem in your starter code (if it configure your WebMvc)
Try mvn dependency:tree or gradle dependencies to explore dependencies.
Attached your starter code.
I had to use spring boot 2.4.1 to avoid the conflict.
I'm trying to implement a jsr 356 websocket connection from within a war deployed in jetty.
I'm using this as a guide: http://aredko.blogspot.com/2013/11/java-websockets-jsr-356-on-jetty-91.html
(I can find lots of tutorials on basically using jsr 356 with an embedded jetty server, but none on building a websocket connection within an existing server - are there any good ones out there?)
Whenever I run the code listed above, I get the following error:
java.lang.LinkageError: loader constraint violation: when resolving method "org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer.configureContext(Lorg/eclipse/jetty/servlet/ServletContextHandler;)Lorg/eclipse/jetty/websocket/jsr356/server/ServerContainer;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, com/me/stuff/data/DataServer, and the class loader (instance of org/eclipse/jetty/start/Classpath$Loader) for resolved class, org/eclipse/jetty/websocket/jsr356/server/deploy/WebSocketServerContainerInitializer, have different Class objects for the type y.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer.configureContext(Lorg/eclipse/jetty/servlet/ServletContextHandler;)Lorg/eclipse/jetty/websocket/jsr356/server/ServerContainer; used in the signature
which refers to the code
ServerContainer container = WebSocketServerContainerInitializer.configureContext(context);
I'm at a loss to figure this out. I'm using the following lines from gradle to bring in the websocket stuff:
providedCompile (
[ group: 'javax.websocket', name: 'javax.websocket-api', version: '+'],
[ group: 'javax.ws.rs', name: 'javax.ws.rs-api', version: '+' ]
)
compile (
[ group: 'org.eclipse.jetty.websocket', name: 'javax-websocket-server-impl', version: '+'],
[ group: 'org.eclipse.jetty.websocket', name: 'javax-websocket-client-impl', version: '+']
)
I see that both the javax-websocket-server-impl jar and the javax.websocket-api jar contain ServerContainer classes...but I'm only including one of those in my war file. Is jetty pulling from its own internal older version? Or am I completely misreading the source of the issue?
The jetty version I have is: jetty-9.2.1.v20140609
The websocket jars should not be in your WAR.
Remove the following jars from your WAR's WEB-INF/lib/ directory.
javax.websocket-api-*.jar - the javax.websocket API jar
javax-websocket-server-impl-*.jar - the jetty server javax.websocket.server.* implementation jar
javax-websocket-client-impl - the jetty javax.websocket.* (client) jar
This is because you are coding/compiling against javax.websocket.* API classes.
The API and the implementation of the API are provided by Jetty itself.
This is no different than when you code against the servlet-api. (namely, that you don't include the servlet-api and the implementation of the servlet-api in your WAR)