Using Jersey-spring with Spring 4.0 - spring

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)

Related

Jersey Support is Jersey 2.35 not Jersey 3.x

I have a server I built a few years ago which provides both REST endpoints and websocket.
It packages as a jar file (as opposed to war) with an embedded Jetty server. Rest is provided by Jersey(2.26). Jersey and JEE Websocket are each ContextHandlers configured into Jetty. The server was built on Java 8.
I want to update the server. My main goals of the update is move to Java 17 and from JEE->Jakarta.
I just found Helidon and thought it to be the perfect solution, particularly since it even has an example of a server that combines REST and websocket.
As I started working with Helidon I found to my disappointment that helidon-webserver-jersey pulls in Jersey2.35 (JEE) not Jersey3.x (Jakarta).
I know that Jersey is doing parallel development in 2.x and 3.x, but I'm still surprised that something as new as Helidon connects to 2.x not 3.x.
I'm curious what the reasoning was behind that decision and if there are plans in the near future to move to Jersey3.x
I haven't started on the websocket piece yet, but I'm guessing its JEE not Jarkata as well. Is that true?
Jersey 3.x as well as the full "jakartification" of Helidon will come with version 3.x.
3.0.0-M1 is already available: https://medium.com/helidon/helidon-3-0-0-m1-release-7dad655cd469

Is there a version of postmark java client library which uses jersey 1.x instead of 2.x?

I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.

Is there any Spring 5.0.6.RELEASE osgified version patch available?

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).

How long will Spring 3.x continue to be supported?

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.

Is it possible to run Mule 2.2.1 on spring 3?

We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.

Resources