I used to configure -Djava.security.egd=file:/dev/./urandom in my Dockerfile for Spring Boot applications.
In https://spring.io/guides/gs/spring-boot-docker/ a comment was added that this is not required any more for newer versions:
To reduce Tomcat startup time we added a system property pointing to "/dev/urandom" as a source of entropy. This is not necessary with more recent versions of Spring Boot, if you use the "standard" version of Tomcat (or any other web server).
I am looking for any references for this change in Tomcat or Spring Boot repos, and which Spring Boot versions are affected.
This problem should have been resolved by the JDK Enhancement Proposal : JEP 123, Configurable Secure Random-Number Generation.
According to the JDK 8 Security Enhancements official Oracle document, the /dev/./urandom workaround is no more necessary from JDK 8.
SHA1PRNG and NativePRNG were fixed to properly respect the SecureRandom seed source properties in the java.security file. (The obscure workaround using file:///dev/urandom and file:/dev/./urandom is no longer required.)
Related
I'm writing a lib for projects using different versions of Spring. The lib itself is based on Spring too ( more precisely, Spring Cloud Sleuth). For now, I use different versions for different projects( version1 for projects using Spring boot 2.0.x, version2 for projects using Spring boot 2.3.x, etc). Apparently, the maintenance took a lot of time and made some confusion. Is there a runtime mechanism like #Conditional but for dependencies?
First, check the Spring Cloud compatibility matrix. As you can see, different Spring Cloud versions support different Boot versions.
I would do the same for your library and maintain different versions of it.
Your can have optional dependencies on Sleuth and set things up using #Conditional annotations (e.g.: #ConditionalOnClass) but I would not recommend that.
Sleuth 2.2.x (Hoxton) uses Brave's API (btw 2.x is not supported anymore, you should upgrade). Sleuth 3.0.x (2020.0.x aka Ilford) and 3.1.x (2021.0.x aka Jubilee) have their own API and they abstract the tracer libraries away. You can use these interfaces/classes to detect the version and configure them differently but when you compile your library you can have classpath issues because you have 2.2.x, 3.0.x, and 3.1.x on your classpath.
Another thing you can do is modularize your library and put all of those things that does not depend on Spring into a "core" module then create smaller adapter/autoconfiguration/starter modules for every version of Spring Cloud you want to support.
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?
Is there any Spring 5.0.6.RELEASE osgified version patch available? We have to to do quick release so need to upgrade older spring but currently our framework uses OSGI based container, though spring has officially stopped supported OSGI. Is it possible to have patched version of latest Spring framework?
Though I know it's better to convert to Spring based container but since time doesn't allow I'm in search of any osgified version of Spring jars.
Apache Servicemix produces osgified versions of a lot of well known libraries, Spring included: https://github.com/apache/servicemix-bundles
Currently the latest osgfied version of Spring is "5.0.5.RELEASE", with "5.0.6.RELEASE" probably due to come in the near future. Otherwise, getting servicemix pom.xml for 5.0.5.RELEASE and manually changing Spring version should work (from 5.0.5 to 5.0.6 there should be just internal implementation changes).
Since spring-boot comes with embedded tomcat containers, I was wondering how is the patching being done. If I decide to go for using embedded approach and a security vulnerability has been found out and the tomcat community has released a patch, how do I apply that patch to the embedded tomcat container which comes with the Spring-boot.
Any help would be greatly appreciated since it will help to decide to go the traditional route of standalone tomcats v's embedded.
According to this Spring blog post, you can specify any version of Tomcat you want. As long as it's released to the Maven repo, just add the following property to your Maven build properties specifying whatever version you like: <tomcat.version>8.0.3</tomcat.version>.
See http://mvnrepository.com/artifact/org.apache.tomcat.embed/tomcat-embed-core for versions currently available in Maven Central.
I'd like to take advantage of some JDK7 features. What issues might I run into given that I use Apache Tomcat 7.0.x (latest) and Spring 3.1 (latest)?
There were a few compilation gotchas where JDK 6 could infer the generic type properly where JDK 7 could not. This was apparently a bug in JDK 6 as referenced here.
If you are using container-specific resources (e.g., data sources, etc.) be sure to verify these are still operating properly (though this will be immediately obvious on Spring startup if any of these are wired in).
If you are using Spring Security, and you upgrade, you do not need to make any changes per se to get get things running. However, you should take advantage of their less verbose configuration options (especially for REST URL's) that are available in Spring Security 3.1.
Other than that, our upgrade was seamless.
With the last Ubuntu update (11.10) I switched to JDK 7 (OpenJDK 1.7.0_147). I'm using Spring 3.0, Tomcat 6, and JRE 6 on the server (we have both VM and "physical" server installations). The code, compiled with JDK 7 runs on this configuration without any problems. I'm sure, switching to Spring 3.1 won't cause any changes. Not so sure about Tomcat 7, but hopefully this information will be useful to you.
You might run into a problem if you're using Java 7 features in a JSP. Tomcat by default user Java 1.6 for JSP compilation. See http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Production%20Configuration
To solve the problem you'll want to override the compilerSourceVM and compilerSourceVM init parameters in your application's web.xml file. More on that here: https://stackoverflow.com/a/20194823/1029261