0

I have a REST client code working OK locally in a server but failing to unmarshall JSON into Java when packaged and deployed to Bluemix with same Liberty versión (8.5.5.9). Failing code:

Response response = get("/v0.1/path/" + var + "/path/" + var2);
return response.readEntity(MyClass.class);

In bluemix I get this exception:

2016-05-29T13:32:26.16+0200 [App/0] ERR Caused by: java.lang.NullPointerException 2016-05-29T13:32:26.16+0200 [App/0]
ERR at org.apache.cxf.jaxrs.impl.tl.ThreadLocalProviders.getContextResolver(ThreadLocalProviders.java:50) 2016-05-29T13:32:26.16+0200 [App/0] ERR at [internal classes] 2016-05-29T13:32:26.16+0200 [App/0] ERR at com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider._locateMapperViaProvider(JacksonJsonProvider.java:206) 2016-05-29T13:32:26.16+0200 [App/0] ERR at com.fasterxml.jackson.jaxrs.base.ProviderBase.locateMapper(ProviderBase.java:853) 2016-05-29T13:32:26.16+0200 [App/0] ERR at com.fasterxml.jackson.jaxrs.base.ProviderBase.readFrom(ProviderBase.java:764) 2016-05-29T13:32:26.16+0200 [App/0] ERR at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1356) 2016-05-29T13:32:26.16+0200 [App/0] ERR ... 13 more

The REST result by the server is OK. In fact, if I get that JSON code as String and use a Jackson mapper to unmarshall it , it works ok, but not if I do it the standard JAX-RS 2.0 client way:

  return response.readEntity(MyClass.class);

which will fail with error above.

Edit: Liberty Versions used:

The build pack wee run locally (JAX-RS 2.0 client requests working OK) is:

(WebSphere Application Server 8.5.5.9/wlp-1.0.12.cl50920160227-1523) on Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_77-b03 (en_US)

The one in BlueMix (JAX-RS 2.0 client requests throwing NPE at CXF class):

 (WebSphere Application Server 2016.5.0.0/wlp-1.0.13.20160430-1625) on IBM J9 VM, version pxa6480sr3-20160428_01 (SR3) (en_US)

Thanks for any help

icordoba
  • 1,834
  • 2
  • 33
  • 60
  • Do you mean the same code: Response response = get("/v0.1/path/" + var + "/path/" + var2); return response.readEntity(MyClass.class); works fine in Liberty server but fails in bluemix? Can you share more info where do you wirte this code in bluemix? Is it an application deployed in Liberty? – Iris Ding Jun 01 '16 at 04:42
  • Yes, it works in our local liberty (checked in Linux, Windows and Mac) but when we deploy the application in Bluemix (we perform a full server package using Eclipse), for version 8.5.5.9, everything works but this problem when unmarshalling into Java. We have also tried getting the JSON String and unmarshalling using Jackson Mapper, and it works OK in LIberty... but not using the readEntity() method in response. – icordoba Jun 01 '16 at 16:25
  • Can you try to package the server with --include=usr option? In this case, the liberty binary will not be packaged. Then you can push this into blueMix. Details please see : https://console.ng.bluemix.net/docs/runtimes/liberty/optionsForPushing.html#packaged_server – Iris Ding Jun 02 '16 at 02:56
  • Hello, yes, we always package the server with --include=usr option. BTW, I just confirmed that in a different project, we are having exactly the same problem. No JAX-RS 2.0 direct unmarshalling working on BlueMix Liberty but working in local Liberty. – icordoba Jun 02 '16 at 13:01
  • you mean you have the same problem without bluemix?Is it possible to send your application to me? – Iris Ding Jun 03 '16 at 08:23
  • No, the problem only arises when we push our app to BlueMix. Locally, JAX-RS 2.0 client requests work perfect. (BTW, I edited the question to include info about versions) – icordoba Jun 03 '16 at 08:25
  • did you try to run it locally also with the IBM J9VM? there might be slightly differences in the implementations. – The86Freak Jun 05 '16 at 16:33
  • I personally haven't (I use MacOS) but I can ask a developer in my company to try. Anyway, if that does not work locally with IBM JVM, it would confirm the problem is with the JVM (which is very likely) but that won't solve the problem as we need to have it running in BlueMix. – icordoba Jun 05 '16 at 16:35

3 Answers3

0

We currently experience the same problem with our application and Liberty Buildpack Version: v2.9-20160519-1249

It must be a problem with the current buildpack version, because we didn't change our application code and it was working fine with previous deployments to Bluemix.

As a workaround you can explicitly specify a previous liberty buildpack version when deploying your app to Bluemix. Either by using the '-b' parameter on the 'cf push' command or by defining the 'buildpack:" property in your manifest.yml file. Have a look at the following links for details:

  • new-console.ng.bluemix.net/docs/cfapps/byob.html
  • docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#buildpack

You can find out the name of the liberty buildpacks available either via 'cf buildpacks' command or here: bpversions.mybluemix.net

Unfortunately, even the previous version liberty_for_java_v2_8-20160430-1011 seems to have the problem described in this thread. Only the oldest version available liberty-for-java_v2_3-20151208-1311 from December last year, is not affected by this problem.

So currently, the only option seems to be to deploy your app via:

$ cf push MYAPP -b liberty-for-java_v2_3-20151208-1311

Joerg
  • 1
  • 1
0

We are aware of this issue and it's being worked through a Support Ticket. Will update when we have more info.

RandalAnders
  • 1,431
  • 9
  • 16
0

IBM has recommended us to use the OpenSource Liberty build pack. It is based on 8.5.5.9, the same official download version, and also seems to have solved the problem. To do this we use this manifest.yml

buildpack: https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack.git
env:
    IBM_JVM_LICENSE: L-PMAA-A3Z8P2
    IBM_LIBERTY_LICENSE: L-MCAO-9SYMVC
    JBP_CONFIG_IBMJDK: "version: 1.8.+"

Until they fix the issue I like this workaround as allows to make sure the version deployed in BlueMix is the someone as the one we use locally to develop and test.

icordoba
  • 1,834
  • 2
  • 33
  • 60