I've recently upgrading spring boot from 2.1.0 to 2.1.6 and now HttpServletRequest.getLocalAddr() does not behave as expected anymore.
For context, I have a web client and a spring server. When the client connects to the server, the latter sends its IP address to the former.
In 2.1.0 and up to 2.1.5 it worked as expected: getLocalAddr returns the local address of the spring server. However, in 2.1.6 it now returns the local address of the client.
Spring-boot 2.1.5 use tomcat 9.0.19
Spring-boot 2.1.6 should use tomcat 9.0.20 according to the release not but when I execute mvn dependency:tree I find that it uses 9.0.21.
I'd like to know if I'm using getLocalAddr properly or not and eventually if I should raise the issue to spring-boot or tomcat.
I've confirmed that the issue occurs in spring 2.1.6 with tomcat 9.0.21.
The issue does not occur in spring 2.1.5 with tomcat 9.0.19
I'm not able to provide a minimal working example, but here is a bit of code demonstrating my usage.
#RestController
public class DeviceControllerImpl {
//omitting
#GetMapping("/configuration")
public String sendConfig(HttpServletRequest http_request) {
String ip = http_request.getLocalAddr();
}
}
I'm expecting getLocalAddr to return the local IP address of spring server, not the web client.
This was a regression bug in tomcat 9.0.21 which is the version provided by spring boot 2.1.6. There is a fix in 9.0.23. Details here: https://bz.apache.org/bugzilla/show_bug.cgi?id=63570
It was a regression in Tomcat version 9.0.22, but was fixed in version 9.0.23. Note however that version 9.0.23 is not on mvnrepository.com, so I would go for version 9.0.24.
To fix it for Spring Boot (and assuming the spring-boot-starter-parent is specified as your project's parent) just specify the new version of Tomcat in your POM's properties:
<tomcat.version>9.0.24</tomcat.version>
See:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63570
https://mvnrepository.com/artifact/org.apache.tomcat.embed/tomcat-embed-core
Related
In start.spring.io, when Spring Boot 2.7.1 is selected it reports that Apache Camel "Requires Spring Boot >= 2.0.0.M1 and < 2.7.0-M1" (see screenshot below).
Is there a specific reason for this or where can I find more information on this?
The Camel team have not yet indicated that camel-spring-boot-starter supports Spring Boot 2.7. Until they're ready to support 2.7, the combination is disabled. Support for Spring Boot 2.7 seems to be part of Camel 3.18 which, at the time of writing, has not been released.
The application is created using spring boot version 1.2.5 Release. I can see that it includes an embedded tomcat version which is 8.0.23. Is it possible to upgrade to a recent tomcat version, let's say, tomcat 9 with spring boot 1.2.5 and still run the application? Or do we need to upgrade the spring boot version to be compatible with tomcat 9? Is there any documentation for the spring boot version compatibility with Tomcat? Thank you.
Why do you want to upgrade it? What is the newer version of tomcat going to bring?
I personally go with the defaults for the spring version unless there is a specific need or issue.
That being said this question may have some pointers
How to change embedded tomcat's version in existing spring boot app?
You may be able to just set the property
9.0.5
It would be preferable to upgrade to the latest Spring Boot release (currently 2.2.5-RELEASE) to avail yourself of the latest features. There are many tutorials, migration guides, problem solutions, etc., out there to guide you, of which here are just a couple:
https://spring.io/blog/2018/03/12/upgrading-start-spring-io-to-spring-boot-2
Global CORS configuration breaks when migrating to Spring Boot 2.0.x
You didn't specify a reason for keeping your Spring Boot version at 1.2.5-RELEASE and only upgrading tomcat, but if you really must, there are other answers, such as here: How to change embedded tomcat's version in existing spring boot app?
I'm building a Spring Boot application with neo4j. I have an issue connecting to a deployed database when I'm running on Spring Boot 2.2.4. In an other project with Spring Boot 2.0.5 it works, but when I upgrade that project to 2.2.4 it also breaks with the same exception.
The weird thing is that it also works on 2.2.4 locally when using a local Docker image.
I get the following exception when I try to connect to a deployed neo4j instance in the cloud using an uri of the form bolt://35.xx.xx.xx:7687 AND on Spring Boot 2.2.4:
If I run my docker image and I change the connection uri to bolt://localhost:7687 it also works perfectly fine on Spring Boot 2.2.4.
Even in my gitlab CI/CD pipeline the test works fine using a service inside the pipeline, also with the same neo4j image.
This is my build.gradle:
And these are the versions effectively installed:
I also can always use browser to connect to my database that's why I assume that it has something to do with the versions instead of my cloud configuration.
Anyone any idea what I have to change on my configuration?
Thanks in advance!
We run following versions:
neo4j 3.5.14
Spring Boot 2.2.4
Java 11
EDIT 1
As someone proposed, I also setup a very simplistic example application (https://neo4j.com/developer/java/) using just the neo4j driver v4 with my GCP instance of Neo4J. This works perfectly fine.
EDIT 2
My application.properties looks like this:
spring.data.neo4j.uri=bolt://35.xxx.xxx.xxx:7687 # <- in prod
spring.data.neo4j.uri=bolt://localhost:7687 # <- in dev
spring.data.neo4j.uri=bolt://neo4j:7687 # <- in CI/CD
spring.data.neo4j.username=neo4j
spring.data.neo4j.password=****
spring.data.neo4j.embedded.enabled=false
The different environments are splitted in seperate property files that set the spring active profile. Im always testing this with replacing the localhost one in the application-dev.properties to the public ip.
My final setup (and solution) was to use only following dependencies:
implementation 'org.springframework.boot:spring-boot-starter-data-neo4j'
implementation 'org.neo4j.driver:neo4j-java-driver-spring-boot-starter:4.0.0.1'
And use following settings in the properties file:
org.neo4j.driver.uri=bolt://35.xx.xx.xx:7687
org.neo4j.driver.authentication.username=neo4j
org.neo4j.driver.authentication.password=neo4j
org.neo4j.driver.config.encrypted=false
Encryption wasn't the problem, but the settings had to be set to org.neo4j.driver instead of the org.springramework.boot dependency. The springframework dependency is still needed to use #Query etc in the repositories, thats why I needed both.
Is there something in Maven that will tell me that if I'm using version 1.5.4 of spring-boot then I need at least version Camden.SRX for spring-cloud-starter-parent?
I was getting non-helpful errors that a class was not found as I was using Spring 1.5.4 and Brixton for cloud.
Is there a way to use Maven to find matching/compatible versions?
when I use the spring session starter for spring boot 1.3.5 and set the version for spring session to 1.2 it comes to conflicts. Seems that it is not compatible and I have to wait for boot 1.4. OK...
To get it running I just added a dependency to spring session 1.2, without the starter and added a class which extends AbstractHttpSessionApplicationInitializer.
This works when I run it in an external tomcat but not when I run it in the embedded tomcat of boot 1.3.5.
Can I use SS 1.20 in SB 1.3.5?
Thank you
One step forward
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
if(auth == null || !(auth.getPrincipal() instanceof UserDetailsImpl))
return null;
...
Here is always null returned although auth.getPrincipal() is an instance of UserDetailsImpl.
Seems to be a classloader issue.
But why does it work in an external tomcat? Any other classloading strategies here?
In short: yes, you can use Spring Session 1.2.x with Spring Boot 1.3.x without any problems.
Spring Session project contains many samples to help users get started with Spring Session (documentation on these samples is available here). Among these samples is also one that resembles your use case - Boot JDBC sample.
As shown in the samples and the docs you should use #EnableJdbcHttpSession annotation to bootstrap Spring Session JDBC support. If your app by any chance also uses Redis, you should exclude the SessionAutoConfiguration provided by Spring Boot 1.3 since your combination of dependencies will trigger the auto-configuration of Redis-backed Spring Session, which is something you don't want if you'd like to use JDBC-backed session store.