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

[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

[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]

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