In our current app we want to use Jetty instead of Tomcat in our Spring Boot app. As i read in the documentation excluding tomcat and introducing Jetty would be enough.
build.gradle
dependencies {
compile("org.springframework.boot:spring-boot-starter-web") {
exclude module: "spring-boot-starter-tomcat"
}
compile("org.springframework.boot:spring-boot-starter-jetty")
}
But when i try to run the app with using:
# gradle bootRun
Tomcat is indeed gone, but Jetty is not started and the application just terminates with any noticeable error. Any hints on what i am doing wrong?
Works well for me with Boot 1.1.0.RELEASE.
You need to run Gradle command with --info(--debug) hint to get more info what's going on.
Related
Spring-boot BOM does not contain a dependency for tomcat-dbcp.
I have a Spring MVC project where I use a database connection pool for Hibernate ORM connections. This project is deployed in Tomcat. In my IntelliJ Idea development environment I use Tomcat embedded, by using the spring-boot-starter-tomcat. But the spring-boot-starter-tomcat does not define a dependency to tomcat-dbcp. Hence I decided to explicitly define a dependency to tomcat-dbcp in my build.gradle.kts file.
I had hoped that the Spring-boot BOM would have contained tomcat-dbcp, so that I would not need to specify it's version number and rely on the Spring Boot dependency management system to handle it's version number for me. But the Spring-boot BOM does not contain a dependency for tomcat-dbcp. Can Spring-Boot add it?
I came up with the following hack so as to not hard code the version number for tomcat-dbcp. Just added the following code to the build.gradle.kts file after dependencies section.
configurations.all {
resolutionStrategy.eachDependency {
if (requested.group == "org.apache.tomcat.embed" && requested.name == "tomcat-embed-core") {
dependencies {
providedRuntime("org.apache.tomcat", "tomcat-dbcp", requested.version) //to use tomcat connection pool in tomcat embedded mode.
}
}
}
}
I have a Gradle project that uses Spring Boot + Vaadin.
The Gradle plugins for Spring Boot and Vaadin configured as follows:
buildscript {
ext {
springBootVersion = '1.3.7.RELEASE'
}
...
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}"
classpath "fi.jasoft.plugin:gradle-vaadin-plugin:0.11.1"
}
}
The Vaadin version is specified as follows:
vaadin {
version '7.6.8'
widgetset 'com.vaadin.DefaultWidgetSet'
}
Vaadin dependencies are specified as follows:
dependencies {
compile 'com.vaadin:vaadin-spring-boot-starter:1.0.0'
compile 'com.vaadin:vaadin-server:${vaadin.version}'
compile 'com.vaadin:vaadin-client:${vaadin.version}'
...
}
This works fine, but as soon as I change the Spring Boot version to
springBootVersion = '1.4.0.RELEASE'
then I get the error:
Illegal character in path at index 89:
https://oss.sonatype.org/content/repositories/vaadin-snapshots/com/vaadin/vaadin-server/${vaadin.version}/vaadin-server-${vaadin.version}.pom
Update
Groovy (which Gradle uses) supports String interpolation only when using double quotes (") so changing the Vaadin dependencies to
dependencies {
compile "com.vaadin:vaadin-spring-boot-starter:1.0.0"
compile "com.vaadin:vaadin-server:${vaadin.version}"
compile "com.vaadin:vaadin-client:${vaadin.version}"
...
}
fixes it. Now the real question is why the single quotes work fine if I downgrade Spring Boot to 1.3.7-RELEASE.
If you are using a recent Spring Boot version you should upgrade your Gradle Vaadin plugin. Recent versions of the plugin has much better support for Spring Boot.
Here is a guide to get you started https://github.com/johndevs/gradle-vaadin-plugin/wiki/Creating-a-Spring-Boot-Project
I'm using Spring Boot and FlyWay together. I added the FlyWay dependency to my Gradle build file like this:
dependencies {
compile("org.springframework.boot:spring-boot-starter-data-jpa")
compile("org.springframework.boot:spring-boot-starter-web")
compile("org.postgresql:postgresql:9.4-1202-jdbc42")
compile("org.flywaydb:flyway-core")
testCompile("org.springframework.boot:spring-boot-starter-test")
}
I also added a db/migrations folder with an initial migration file. The migration works as expected. But now I want to clean by using the gradle flywayClean task. However, when I run this, I get an error saying the task can't be found. Is there another way I'm supposed to do this with Spring Boot?
To run gradle flywayClean, you have to apply the plugin: 'org.flywaydb.flyway'
See http://flywaydb.org/getstarted/firststeps/gradle.html
We have a web service project that relies on Netflix's Eureka and it has a dependency on Jersey client 1.x.
Our project is using gradle and in the project we have our src, unit, integration, and functional tests. For our functional tests we have a jar that we import in the testCompile gradle section that wraps a Jersey client to send requests to the web service.
Now my question is how can I get the netflix Jersey client dependency to be ignored in the testCompile so I can use the new Jersey 2.x client for the functional tests?
Build Scripts below:
Main service build script excerpt:
dependencies {
compile 'com.netflix.eureka:eureka-client:1.1.97'
compile 'com.sun.jersey:jersey-bundle:1.18'
testCompile 'some.domain:service-test-client:1.0.1'
}
service test client relevant parts:
dependencies {
compile 'org.glassfish.jersey.core:jersey-client:2.19'
compile 'org.glassfish.jersey.connectors:jeresey-apache-connector:2.19'
}
Relevant parts of the Eureka Client gradle script from github:
ext {
githubProjectName = 'eureka'
awsVersion='1.9.3'
servletVersion='2.5'
jerseyVersion='1.11'
governatorVersion='1.3.3'
archaiusVersion='0.6.5'
blitzVersion='1.34'
mockitoVersion='1.9.5'
junit_version='4.10'
mockserverVersion='3.9.2'
jetty_version='7.2.0.v20101020'
}
dependencies {
compile "com.sun.jersey:jersey-core:$jerseyVersion"
compile "com.sun.jersey:jersey-client:$jerseyVersion"
compile 'com.sun.jersey.contribs:jersey-apache-client4:1.11'
compile 'org.apache.httpcomponents:httpclient:4.2.1'
}
With the above setup I get method not found errors because when the tests are running some of the jersey 1.x classes are taking precedence over the classes brought in with the test-client jar.
You can use gradle dependency monitoring to find out what libraries are bringing in jersey.
./gradlew dependencies
You can pipe that into a file, and less your way into finding out who's bringing in jersey 1.*.
Then, just exclude it from those specifically, and compile your own:
compile("com.example.library:artifactId:x.y.z"){
exclude group:'org.glassfish.jersey', module:jersey-common
}
compile('org.glassfish.jersey.core:jersey-common:2.4.1')
I got same problem with jersey 1.x vs glassfish 2.x with Eureka (but with Spring Cloud). I'm trying this:
compile ("org.springframework.cloud:spring-cloud-starter-eureka:1.0.0.RELEASE")
{
exclude group:'com.sun.jersey', module: 'jsr311-api'
}
But then Eureka doesn't work for me...
I think I will try to switch to Eureka 2.0 with different jersey, but without spring cloud:
https://github.com/Netflix/eureka/wiki/Eureka-2.0-Architecture-Overview
http://mvnrepository.com/artifact/com.netflix.eureka check Eureka2 dependencies
maybe you can use them?
We got a couple of grails applications running, each with its own Log4j classes.
They need to be moved with a server that has log4j provided by Tomcat.
It it possible to get the grails applications to use the tomcat provided libraries?
Any help would be appreciated.
You can try excluding log4j from Grails depencies so that Tomcat provided log4j will be used:
grails.project.dependency.resolution = {
inherits("global") {
excludes "log4j"
}
}