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

[architsinha]

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:

1. Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
2. 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 so many of existing dependencies just to include one additional module.

[RupW]

No, if you look at the very first commit you'll see that it's always used org.glassfish.jersey, i.e. 2.x:

https://github.com/wildbit/postmark-java/blob/37115ad77cc69a5fd8331d75e4276971d14523d6/pom.xml#L53

It wouldn't be too difficult to backport postmark-java to use Jersey 1.x if you needed to though. This structure is used to pass extra request headers in bulk: Jersey 1.x only supports adding headers individually, so what structure you use to pass them around doesn't really matter e.g. you could use Apache or Guava's multi valued maps, or jersey-core 1.x has MultivaluedMapImpl albeit this is typed to String, String not String, Object. You'd then need to loop through this in HttpClient.execute() calling .header individually on the WebResource (which you need instead of the WebTarget from Jersey 2.x) with each header.

There are other syntax changes you'd need too, but it should be achievable. Or you could find some other library to use (e.g. Jared Holdcroft's unofficial postmark-java from before there was an official one, which uses GSON not Jersey, if that does what you need?) or just make an HTTPS request to the API yourself.

Or another idea: set up a separate ClassLoader for postmark-java so that you can have both versions of Jersey loaded independently.

[ibalosh]

Hi guys,

That is definitely an interesting question.

@RupW thanks for jumping in on the topic. That is the perfect answer and what my thoughts are too.
Separate ClassLoader seems like the best choice to me since it gives you best of both worlds (newer library for Postmark and older for the project due compatibility). We could adapt library to an older version, but we are pro using newer versions since they are better choice in long run.

I will think about this one bit more, but overall I think that it's the best using two different versions of the library with class loaders in this case.

You could use Jared's version of Postmark library, but it's very outdated (many endpoints we added to API are not supported there, and our official library is easier to use with more options).

[ibalosh]

Hey guys,

I had some spare time today to play with jersey 1.x and created a jersey1x branch.

I did not use older versions of Jersey before, but it was pretty easy to change the HttpClient class for Postmark library to make it work. From what I see it works ok, tests passed.

Let me know if that solution would work, you can try out current jersey1x branch on your side by building the jar and trying it with local dependency in maven pom.xml file you have in place.

Igor

[ibalosh]

I made a very small release which covers a change of header type so it's passed to methods with type MultivaluedMap (interface). This makes it bit less strict, and should make porting to old Jersey version even easier. Only changes needed would need to be done on HttpClient and Postmark classes.

That's closest we can provide, to make old Jersey work.

Example moved to:

https://github.com/wildbit/postmark-java/tree/jersey-1.x