Message Boards

Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)

Bernd S, modified 3 Years ago.

Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)

Junior Member Posts: 59 Join Date: 3/31/15 Recent Posts

Hello,
I am currently upgrading a project, consisting of multiple portlets and a central service-builder generated backend.
While I managed the upgrade from Lifery DXP 7.0 to Liferay DXP 7.2 without any bigger problems, the trouble started when upgrading Java as well:

SOAP Client
My service-builder backend contains several SOAP clients for internal usage. With Java 11 they all throw this exception:

java.lang.ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl

This is understandable since, jax ws was removed from the JDK. Therefore I tried to add the necessary dependencies to my pom.xml but they had no effect.
Finally I stumbled over this reported issue, which tackles my problem.
Unfortunately the provided "solution" doesn't work for me, since it simply adds another layer to the exception:

Caused by: java.lang.ClassNotFoundException: com.sun.xml.internal.ws.spi.ProviderImpl cannot be found by com.my.bundle_1.0.0

Jsonws
Liferay is still using https://jodd.org which doesn't support anything above Java 11.
As a quick fix, I set the target version to 1.8 in my maven-compiler-plugin but this is only a temporary solution.
Is there any other way to get it working with Java 11.

To sum it up, I feel like Liferay is not really supporting Java 11 although it is metntioned in the compatibility matrix.

Best Regards,
Bernd

thumbnail
Christoph Rabel, modified 3 Years ago.

RE: Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)

Liferay Legend Posts: 1554 Join Date: 9/24/09 Recent Posts

Actually, the solution in the referenced issue should work for the missing ProviderImpl. The thing is, Liferay has implemented the Provider class itself and instead of com.sun.xml.internal.ws.spi.ProviderImpl the Liferay class com.liferay.jaxws.osgi.bridge.Provider should be used.

The problem is that it is really tricky to get it working. You need to follow all the steps in the ticket (and maybe check the referenced, older ticket, too). It simply should not look for the ProviderImpl class and work with a correct configuration.

Jodd:

Yeah, that one bugged me too. The unfortunate thing is that Liferay used the Jodd library and it simply didn't support Java 11 fully, at least not at the time of the 7.2 release. I don't remember details, but I could work around the Jodd issues.

 

Bernd S, modified 3 Years ago.

RE: RE: Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)

Junior Member Posts: 59 Join Date: 3/31/15 Recent Posts

Thank you for your answer, Christoph.

I finally manged to get it working. Here is what I did:

  1. Created one CXF Endpoint in Control Panel > Configuration > System Settings > Web-API > CXF Endpoints
  2. Created a matching JAX-WS API in Control Panel > Configuration > System Settings > Web-API > JAX-WS API, referencing my CXF Endpoint
  3. Used the classloader from Liferay for creating my service:
Bundle bundle = FrameworkUtil.getBundle(this.getClass()).getBundleContext().getBundle(0);
ClassLoader classLoader = bundle.adapt(BundleWiring.class).getClassLoader();
Thread thread = Thread.currentThread();
ClassLoader contextClassLoader = thread.getContextClassLoader();
thread.setContextClassLoader(classLoader);

try {
    // create service
    return service;
} finally {
    thread.setContextClassLoader(contextClassLoader);
}

The first line (retrieving the bungle) was actually the crucial one. At first I tried to get it only via

FrameworkUtil.getBundle(this.getClass())

This returned "com.my.bundle_1.0.0" which is my own bundle, which is the service builder generated project. But actually I had to get the Liferay bundle via:

FrameworkUtil.getBundle(this.getClass()).getBundleContext().getBundle(0);

Additionally I should mention that my call isn't in an OSGi component, therefore I had to use this methode. If youre are actually in an OSGi component (@Component) then you can simply get the BundleContext in the activation method:

@Activate 
@Modified 
protected void activate(BundleContext bundleContext, Map<String, Object> properties) { this.bundleContext = bundleContext; }

 

JODD:

I worked around it by setting the target version in my pom.xml (Maven) to 1.8. Not a perfect solution but since I am not using any newer features I can live with it for now (and probably have to).