I have an application with Spring 4.x and Primefaces 7. Now I need to introduce push functionality. Starting from Primefaces 7, push function was removed (in previous releases it was provided by atmosphere framework). Now in release notes of version 7, the developer team suggests using Omnifaces or JFS 2.3. I tried to integrate Omnifaces but, if I understand correctly, the #Push tag is interpreted by CDI only and ignored by Spring. I've all my beans and services managed with Spring. Is there a way to make #Push to works with Spring?
For JFS 2.3 I've the same problem.
Related
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.
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
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.
According to you what are the risks of using Spring 4 with the jersey-spring3 integration module?
I have tried to use Spring 4.0 with the jersey spring example and the example still works but i'm unable to identify risks linked to this usage.
I have started using Jersey 2.7 and Spring 4.0.x recently in a project. I have setup a context hierarchy to inject beans, so far, I have discovered only one limitiation but that does not seem relate to Spring 4 but rather to the module itself or the HK2 Spring Bridge.
To give more insight about my use. I have a XJC/JAXB-backed which is consumed by a common service, repository and exposed through JAX-WS, and now hopefully through JAX-RS.
The multi-context stuff works now with #Autowiredwith 2.8-SNAPSHOT. I have applied my changes and the 2.8-SNAPSHOT to 2.7. Here is the diff.
Edit (Michael-O; 2014-10-17): Here is a modified Spring module based off 2.11 with multi-context support.
Not an answer to original question, just related information
This may be a little premature, but the new Major 3.0 version of Jersey will be using Spring 4, in the new jersey-spring4 module. The new Major version will be built with Java 8. Though a new Major version will be released, the 2.x line will still be actively developed to keep support for Java 7
I'll update this post once 3.0 has been release.
For anyone interested, you can see this mailing list to see what the Jersey team has to say about the new 3.x line.
Not sure if you came across any issues but I currently face one. It is described in other thread.
Simply, using jersey-spring3 2.12 and spring 4.1.0.RELEASE in one maven project leads to following class incompatibility:
2014-09-14 01:15:44.175:WARN:oejuc.AbstractLifeCycle:main: FAILED org.eclipse.jetty.server.handler.HandlerCollection#696
db620[org.eclipse.jetty.server.handler.ContextHandlerCollection#27abb6ca[o.e.j.m.p.JettyWebAppContext#737d100a{/,file:/C
:/Users/Josef/Workspace/TransitCenter/src/main/webapp/,STARTING}{file:/C:/Users/Josef/Workspace/TransitCenter/src/main/w
ebapp/}], org.eclipse.jetty.server.handler.DefaultHandler#6968c1d6, org.eclipse.jetty.server.handler.RequestLogHandler#7
d986d83]: java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependenc
yComparator()Ljava/util/Comparator;
java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependencyComparato
r()Ljava/util/Comparator;
at org.springframework.context.annotation.AnnotationConfigUtils.registerAnnotationConfigProcessors(AnnotationCon
figUtils.java:136)