Message Boards
Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)
Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)
Junior Member Posts: 59 Join Date: 3/31/15 Recent PostsHello,
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
RE: Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)
Liferay Legend Posts: 1554 Join Date: 9/24/09 Recent PostsActually, 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.
RE: RE: Liferay 7.2 and Java 11 upgrade problems (SOAP Client, jsonws)
Junior Member Posts: 59 Join Date: 3/31/15 Recent PostsThank you for your answer, Christoph.
I finally manged to get it working. Here is what I did:
- Created one CXF Endpoint in Control Panel > Configuration > System Settings > Web-API > CXF Endpoints
- Created a matching JAX-WS API in Control Panel > Configuration > System Settings > Web-API > JAX-WS API, referencing my CXF Endpoint
- 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).