What will be the problem if I come to use Spring-beans namespace 3.0 and Spring security namespace version 3.2 ?
There will be no problem with the namespaces.
The only concern is that, the underlying frameworks (Spring and Spring Security) must been compatible.
In some cases it is wise to use the namespace that matches the underlying framework versions. But in most cases newer frameworks can handle older namespaces
the new Spring versions are almost compatible to namespace 3.0
in Spring Security they often invented new features so sometimes you need the matching namespace to configure the required features))
And Spring Security this is from Spring Security 3.2 Reference:
Spring Security builds against Spring Framework 3.2.13.RELEASE, but is
also tested against Spring Framework 4.1.6.RELEASE. This means you can
use Spring Security 3.2.10.CI-SNAPSHOT with Spring Framework
4.1.6.RELEASE. The problem that many users will have is that Spring Security’s transitive dependencies resolve Spring Framework
3.2.13.RELEASE causing all sorts of strange classpath problems.
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.
I'm working on application which uses Spring Core in version 4.3.14 and Spring Web in version 4.2.13. We don't use Spring MVC. Also, from Spring Web we use just very limited set of classes:
XmlWebApplicationContext (so classes from org.springframework.web.context)
RestTemplate (so classes from org.springframework.web.client, here i expect some problems)
some util classes which probably can be refactored to use something else
My question is:
We want to migrate to Spring 5.x. Is such a migration really possible? Or should i expect some severe problems with application startup (class incompatibilites etc). This source for example: https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x#whats-new-in-version-50 says that Servlet 3.1 is required
From the other side, here https://spring.io/blog/2015/06/10/feedback-welcome-spring-5-system-requirements JUERGEN HOELLER wrote that migration to Spring 5 will be a soft one. So i assume that if Application uses only features from JEE6 + Servlet 3.0, then it can be that it will also work on Spring 5.x with JEE6-compatible appserver
Does anyone have an experience in that?
As always, Spring Framework upgrades its baseline with new major versions. In this case, we're requiring JDK8+ and Java EE7+.
In practice, this means that the compiled code depends on those APIs and doesn't use reflection anymore to adapt to them. In your case, this is not only about Servlet, but also JPA, JMS, bean validation and other specs.
Your application might work fine with the arrangement you're mentioning, but the Spring team will not guarantee support for this setup.
In custom Spring Boot Autoconfiguration projects I usually have some dependencies which are marked as optional. As I need them for compilation, but expect users of my autoconfig to include them manually in their own POM, or they will be provided by the Spring Boot dependencies.
How do I ensure that users of different Spring Boot versions can use my autoconfig without dependecy/version problems?
I see two non-optimal solutions; are there more?
Hoping that the API stays the same
Just hope that the API of my dependencies stays stable over minor version changes, so that if I developed and compiled my Autoconfig e.g. with Spring Boot 1.4.x, the API which I used is still the same with 1.5.x, etc.
I then wouldn't necessarily expect it to work e.g. for Spring Boot 2.x, and would put a corresponding note into the readme.
Explicitly tracking each Spring Boot version
Explicitly build a version for at least each minor Spring Boot version, but possibly even for each Patch version? Who knows when a breaking API change could happen. I would then need to document for which exact Spring Boot version my autoconfig is intended. But this is a lot of work.
Of course Spring Boot's own autoconfig project is developed in lockstep with Spring Boot, so that any problems will be fixed in the same release.
But my own autoconfig might have been developed once and not expect many changes afterwards. How do I ensure that my autoconfig keeps working as long as possible even as the "users" of my autoconfig are updating their Spring Boot version dependencies?
our application currently uses JBoss Portal with JAAS as the authentication/authorization mechanism. The version of Spring we are currently using is 3.2.14. For various reasons we are unable to upgrade Spring right now.
We are going to be migrating to Spring Security shortly and are wondering if Spring Security 4.2.2 will be compatible with Spring 3.2.14. My thoughts are that since Spring Security is a separate project it should be OK?
I can't seem to find any information on the compatibility issues between major versions of Spring and major versions of Spring Security.
For Spring Security 4.2.2, the minimum recommended Spring version is 4.3.5.
This is stated in the SpringSecurityCoreVersion class which is located in the org.springframework.security.core package.
Please what is the compatible release version for Spring Security for Spring 3.2.8 release ?
There is little dependancy between Spring Security versions and Spring Framework versions. I have already used Spring Security 3.1.x with Spring Framework 3.1.x and 3.2.x.
If you have no reason to do differently (portability of code) you should choose the more recent General Available version that is compatible with your other components.
Doc for latest GA (4.0.1) says that it builds against Spring Framework 4.1.6.RELEASE, but should work with 4.0.x => no good.
Doc for previous GA (3.2.7) says that is builds against Spring Framework 3.2.13.RELEASE, but is also tested against Spring Framework 4.1.6.RELEASE
It would be my first choice, but if you use maven, you will have to control what is actually imported via transitive dependancy and eventually force 3.2.8 versions for all used Spring Framework components to avoid mixing different versions, or better upgrade to 3.2.13 since it is only a patch level different version.
Of course, you can also make use of the fact that previous Spring Security version (3.2.6) explicitely builds against Spring Framework 3.2.8.RELEASE, as said by #zeisi
According to the Docs it would be 3.2.6, see Spring Security Docs