We have a lot of spring code written in our AEM application. We are using spring dm to run the code in osgi.
Now we would like to migrate our code to JDK 11 which requires us to migrate spring framework to 5.1 onwards. Is there a spring dm version with support springframework 5.1 onwards.
Are there any other alternative approaches to do such migration ??
regards,
I have tried to figure out which version of spring-data-jdbc to use with Spring Boot 1.5.20.RELEASE (= Spring Framework 4.3.23.RELEASE) - but I can't find that info anywhere.
Is it because spring-data-jdbc only work with Spring Boot 2.x / Spring Framework 5.x?
Specifically I want to use #Query, #EnableJdbcRepositories, etc.
When I look at the release notes for Spring Data Ingalls SR20 (the release train that matches Boot 1.5.20.RELEASE / Framework 4.3.23.RELEASE) it looks like spring-data-jdbc is only supported in Lovelace (Boot 2.x and Framework 5.x): https://spring.io/blog/2019/04/10/spring-data-lovelace-sr6-kay-sr14-ingalls-sr20-released
EDIT & ANSWER: As per comment from #JensSchauder: spring-data-jdbc is a (fairly) new project created from scratch. There is no way to use it with Spring Framework 4.
If you look at the spring-data-jdbc pom.xml it uses spring-data-parent to manage Spring Framework version by defining and applying spring.version property. You must ensure that this Spring Framework version is compatible with whatever version you are using.
The first available spring-data-jdbc:1.0.0.RELEASE version uses spring-data-parent:2.1.0.RELEASE parent which requires Spring Framework 5.1:
<spring>5.1.0.RELEASE</spring>
It's not be recommended to use spring-data-jdbc with lower Spring Framework version. Since Spring Boot 1.5.X uses Spring Framework 4.X the answer would be no.
I am new to Spring and I am trying to extend BaseCommandController but Eclipse doesn't show it. I can extend AbstractController but not BaseCommandController. I have added all jar files from spring-framework 4.2.2.RELEASE.
What should I do to solve this problem?
You are not able to extend BaseCommandController because it is deprecated since Spring 3 and got removed in Spring 4.
The Spring way is now to use annotations as mentioned in the deprecation comment:
#deprecated as of Spring 3.0, in favor of annotated controllers
You should have a look at the Getting Started guide of Spring MVC where you can find a good example of the #Controller annotation
I've recently inherited a project that's built on some older technologies, including iBATIS 2.x, and Struts 1.x. Both of those seem to be supported (though #Deprecated) in Spring 3.2.x, and not at all in Spring 4.x:
org.springframework.orm.ibatis, Object Relational Mapping (ORM) Data Access - iBATIS SQL Maps
org.springframework.web.struts, Integrating with other web frameworks - Apache Struts 1.x and 2.x
However, before I start the effort of migrating to Spring 3, I want to know how much longer I can expect to see it supported by the upstream developers. Would I have enough time to keep running Spring 3 while I migrate other parts of my application to newer tools, and then finally migrate over to Spring 4? Or should I focus on upgrading all of these other things before I can get onto Spring?
I hardly understand your problem. iBATIS 2.x and Struts 1.x are both no longer supported. They can work fine, as does Spring 2.x, but if a security problem is discovered, it will not be fixed.
If you contemplate migrating to Spring 3.x, you should also contemplate the migration to MyBatis and Struts 2.x (or Spring MVC ?) unless you have special requirements.
BTW, Spring 3.0 and 3.1 series are no longer supported either, and support for 3.2 should end when 4.2 will reach General Availability status, as Spring Framework generally offers support for current version, and the 2 previous (legacy) ones.
Spring 3.X will be end-of-life as of Dec 31 2016, but there will only be maintenance releases until that time (no feature development will happen).
I just work on project that uses Spring 4 with MyBatis. There is project MyBatis-Spring that integrates these two. Works like charm.
Don't know how to help with second bullet, cause we are using Spring MVC.
Seems that they've just posted a blog post that includes clarification on this topic:
Furthermore, please note that the 3.2.x line - and therefore the
entire 3.x generation - is approaching its end of life in 2015. We are
still committed to basic maintenance for critical issues; however,
don’t expect more than two or three further 3.2.x releases down the
road.
Source: Spring Framework 4.1.4 & 4.0.9 & 3.2.13 released
So, it seems that I'd have at least a few months of 3.x being supported to work on transitioning everything.
For my current project I'm required to use Struts 1.2.4. But I also wanted to utilize Spring 4.1.x.
To compensate for the missing Struts support since Spring 4, I copied the code from the spring-struts 3.2.13 package and created a Spring 4.1.5 compatible spring-struts-forwardport package.
Obviously this is not the most elegant solution, but maybe this can help you solve your problem.
I guess this package will also work with the next Spring 4.1 releases.
Some time ago I heard a rumor saying Spring 4.1 is going to support JSF 2.2. In particular, SpringBeanFacesELResolver would be able to create view scoped controller beans. Spring 3 only supports application scope, request scope and session scope. As far as I know Spring 4.0 supports the same scopes.
Unfortunately, I don't find the reference on Spring 4.1 and JSF 2.2 (except my own web site, where I mention I had heard the rumor). Are there any plans concerning Spring 4.1 and JSF 2.2?
BTW: I know there are several questions on StackOverflow dealing with Spring and JSF. My question is different in that it's specifically about Spring 4.1 and it's about native Spring support. In particular, it's not about how to implement ViewScope myself.
Rafael Ponte told me today #ViewScope can be used with the latest Spring 3.2 version. See the full story (including Rafaels comments) at my blog.
As for Spring 4.1: the plans to support JSF 2.2 have been dropped. The JIRA issue on the topic has been moved to "contribution welcome" - in other words they're waiting for us to implement it ourselves and to submit our solution to the Spring team.