Remove dependency on jersey

[tdiesler]

The use of jersey prevents this component to get integrated with WildFly and RedHat EAP. Perhaps it'd be possible to use the standard APIs for JAX-RS communication?

CrossRef: wildfly-extras/wildfly-camel#1984

[JoshDM]

There is a problem with Jersey and WildFly / JBoss compatibility and the com.sun.jersey.api.client.ClientResponse class, specifically the getLastModified() and getResponseDate() methods which use the dateDelegate variable.

In ClientResponse class, this code exists:

HeaderDelegate<Date> dateDelegate = RuntimeDelegate.getInstance().createHeaderDelegate(Date.class);

In ClientResponse.getLastModified() and GetResponseDate() this code exists:

return (d != null) ? dateDelegate.fromString(d) : null;

dateDelegate is always NULL because the HeaderDelegate for class Date is not set in the JBoss/Wildfly instance. When the ClientResponse methods which reference dateDelegate are called, an unexpected NullPointerException is thrown.

Of note, a resolution to this issue on a broader scale is documented on Stack Overflow:

https://stackoverflow.com/q/11133844/985906

There are multiple methods to solve this :

Method 1 - CONFIGURATION

Configure HeaderDelegate correctly within WildFly / JBoss

Method 2 - FIX JERSEY

Override com.sun.jersey.api.client.ClientResponse with a local implementation that implements getLastModified() and getResponseDate() with calls that do not throw NPE.

You can use a DateFormat for the RFC1123 date pattern "EEE, dd MMM yyyy HH:mm:ss 'GMT'" to properly parse the date from the headers "Last-Modified" and "Date".

// replace this line in both methods
        return (d != null) ? RFC1123 .parse(d) : null;
//        return (d != null) ? dateDelegate.fromString(d) : null;

Method 3 - FIX ATMOS API DIRECTLY

In the API, revise AtmosApiClient.fillResponse(T response, ClientResponse clientResponse) and wrap the calls to clientResponse.getLastModified() and clientResponse.getResponseDate() with compensating code per Method 2, pulling the headers directly via clientResponse.getHeaders().getFirst(headerString).

Method 4 - OVERRIDE ATMOS API

My preferred solution, which does require monitoring AtmosApiClient in future versions for changes is as follows... Implement a custom AtmosApiClient extending *.jersey.AtmosApiClient and override fillResponse(), which is a protected method, and wrap the code per Method 3.

[twincitiesguy]

Unfortunately, Jersey 1.x is the only version that provides full request wrapping via filters. We use this for automatic retries (there is no reasonable way to do that in generic JAX-RS or in Jersey 2.x -- but we are open to suggestions). I would love to drop our dependency on the older library, but quite frankly, in the vast majority of deployments, it works quite well.

Given the above 4 methods proposed by @JoshDM:

• Method 1 we have no control over
• Method 2 I think justifies a PR to the jersey repo (ahem.. Josh)
• We will implement Method 3 in the next release
• Method 4 is a downstream workaround, which should be unnecessary after the above-mentioned release

[JoshDM]

"(ahem... Josh)"

😆

Stu, you know I'm super-busy; plus I've got a work-around. I suspect the Jersey folks might just kick it back as an issue with JBoss since Method 1 exists.

[twincitiesguy]

Ok. Just figured since you already had the code in the above comment, it wouldn't take very long to paste it into a fork.

[JoshDM]

Technically it's an application server problem.

[twincitiesguy]

Well, then I will leave it to our users. Should anyone want to pursue this change in Jersey 1, feel free to open a PR with the above (Method 2) suggestion.

[twincitiesguy]

Method 3 above has been implemented and released on 3.0.2. I'm closing the issue as this should be a sufficient workaround.