NullPointerException occurs when using vSphere Management WebServices SDK with Java 11
Article ID: 311939
Updated On:
Products
VMware vCenter Server
Issue/Introduction
Symptoms:
Using vSphere Management SDK with Java 11 may result in NullPointerException. The exception is seen when com.vmware.vim25#VimService() attempts to call javax.xml.ws.Service constructor.
[29193] 2022-07-29 02:01:44.323 [ERROR] [Collector worker thread 18] com.emc.vcops.collectors.vmware.VmwareCollector [collect] [214] - error collecting vcenter ip=10.225.6.54
[29194] java.lang.NullPointerException: null
[29195] at javax.xml.ws.Service.<init>(Service.java:112) ~[jaxws-api-2.3.1.jar:?]
[29196] at com.vmware.vim25.VimService.<init>(VimService.java:38) ~[vim25-7.0.3-20034407.jar:?]
[29197] at com.emc.pie.adapters.vsphere.net.HttpsVimSession.<init>(HttpsVimSession.java:50) ~[vsphere-adapter-java-1.9.0-SNAPSHOT.jar:?]
[29198] at com.emc.vcops.collectors.vmware.VmwareCollector.collect
(VmwareCollector.java:161) ~[emc-vcops-adapter-collectors-vmware-7.1.0-SNAPSHOT.jar:?]
[29199] at com.emc.vcops.moxy.EmcAdapterInstance.collect
(EmcAdapterInstance.java:468) ~[emc-vcops-adapter.jar:?]
[29200] at com.emc.vcops.moxy.EmcAdapterInstance.onCollect
(EmcAdapterInstance.java:415) ~[emc-vcops-adapter.jar:?]
[29201] at com.integrien.alive.common.adapter3.AdapterBase.collectBase
(AdapterBase.java:772) ~[vrops-adapters-sdk.jar:?]
[29202] at com.integrien.alive.common.adapter3.AdapterBase.collect
(AdapterBase.java:557) ~[vrops-adapters-sdk.jar:?]
[29203] at com.emc.vcops.EmcAdapter.collect(EmcAdapter.java:522) ~[emc-vcops-adapter.jar:?]
[29204] at com.integrien.alive.collector.CollectorWorkItem3.run
(CollectorWorkItem3.java:47) ~[vcops-collector-1.0-SNAPSHOT.jar:?]
[29205] at com.integrien.alive.common.util.ThreadPool$WorkerItem.run
(ThreadPool.java:275) ~[vrops-adapters-sdk.jar:?]
[29206] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
[29207] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
Using vSphere Management SDK with Java 11 may result in NullPointerException. The exception is seen when com.vmware.vim25#VimService() attempts to call javax.xml.ws.Service constructor.
[29193] 2022-07-29 02:01:44.323 [ERROR] [Collector worker thread 18] com.emc.vcops.collectors.vmware.VmwareCollector [collect] [214] - error collecting vcenter ip=10.225.6.54
[29194] java.lang.NullPointerException: null
[29195] at javax.xml.ws.Service.<init>(Service.java:112) ~[jaxws-api-2.3.1.jar:?]
[29196] at com.vmware.vim25.VimService.<init>(VimService.java:38) ~[vim25-7.0.3-20034407.jar:?]
[29197] at com.emc.pie.adapters.vsphere.net.HttpsVimSession.<init>(HttpsVimSession.java:50) ~[vsphere-adapter-java-1.9.0-SNAPSHOT.jar:?]
[29198] at com.emc.vcops.collectors.vmware.VmwareCollector.collect
(VmwareCollector.java:161) ~[emc-vcops-adapter-collectors-vmware-7.1.0-SNAPSHOT.jar:?]
[29199] at com.emc.vcops.moxy.EmcAdapterInstance.collect
(EmcAdapterInstance.java:468) ~[emc-vcops-adapter.jar:?]
[29200] at com.emc.vcops.moxy.EmcAdapterInstance.onCollect
(EmcAdapterInstance.java:415) ~[emc-vcops-adapter.jar:?]
[29201] at com.integrien.alive.common.adapter3.AdapterBase.collectBase
(AdapterBase.java:772) ~[vrops-adapters-sdk.jar:?]
[29202] at com.integrien.alive.common.adapter3.AdapterBase.collect
(AdapterBase.java:557) ~[vrops-adapters-sdk.jar:?]
[29203] at com.emc.vcops.EmcAdapter.collect(EmcAdapter.java:522) ~[emc-vcops-adapter.jar:?]
[29204] at com.integrien.alive.collector.CollectorWorkItem3.run
(CollectorWorkItem3.java:47) ~[vcops-collector-1.0-SNAPSHOT.jar:?]
[29205] at com.integrien.alive.common.util.ThreadPool$WorkerItem.run
(ThreadPool.java:275) ~[vrops-adapters-sdk.jar:?]
[29206] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
[29207] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
Environment
VMware vCenter Server 7.0.3
Cause
This is a known bug in jaxws-ri (verion < 3.0.1) The issue happens if osgi-resource-locator is in Java 11 classpath, as explained in the below link :
https://github.com/eclipse-ee4j/jax-ws-api/issues/161
Call to Provider.provider() from javax.xml.ws.Service constructors returns null in Java 11 if osgi-resource-locator is in the classpath. This jar can be in the classpath as a result of a transitive dependency. The cause of the NullPointerException is the call to isOSGi() from javax.xml.ws.spi.FactoryFinder#find can return true in Java 11 even if the application is not OSGi; whereas in Java 8, the call would return false under the same circumstance.
https://github.com/eclipse-ee4j/jax-ws-api/issues/161
Call to Provider.provider() from javax.xml.ws.Service constructors returns null in Java 11 if osgi-resource-locator is in the classpath. This jar can be in the classpath as a result of a transitive dependency. The cause of the NullPointerException is the call to isOSGi() from javax.xml.ws.spi.FactoryFinder#find can return true in Java 11 even if the application is not OSGi; whereas in Java 8, the call would return false under the same circumstance.
Resolution
This issue was fixed in jaxws-ri version 3.0.1: https://github.com/eclipse-ee4j/jax-ws-api/pull/162/files .
Updating the jaxws-ri library version to 3.0.1 would have solved the issue. However, vSphere Management SDK Java bundles and uses jaxws-ri version 2.3.3, stubs generated with this jaxws-ri version has "javax.xml.ws.Service" in service stubs. Since, jaxws-ri changed their package namespace from javax.* to jakarta.*.
After updating the library, Stubs need to be re-generated and compiled. Follow the below steps.
Re-generate stubs using higher version of jaxws-ri.
1. Download jaxws-ri version 3.0.1 or higher and replace it with existing jaxws-ri under the SDK/libs directory.
a. Link to JAX WS RI Standalone Zipped Bundle via various repositories: https://mvnrepository.com/artifact/com.sun.xml.ws/jaxws-ri/3.0.1
2. Re-generate client bindings(ssoclient.jar/vim25.jar) using WSDL files from SDK. Since vsphere-ws
has a dependency on sso client, the sso client library and samples (sso.jar) need to be built first.
a. Existing samples across SDK's sub-directries, viz. ssoclient, vsphere-ws, eam, sms-sdk, spbm and vslm
must be updated. i.e. Following import statements should be changed from
"javax.xml.ws.*", "javax.xml.bind.*" and "javax.xml.soap.*"
to "jakarta.xml.ws.*", "jakarta.xml.bind.*" and "jakarta.xml.soap.*" respectively.
b. ssoclient : Scripts to build the sso jar and the samples are present under (SDK/ssoclient/java/JAXWS)
1. Run the command "build_ssoclient.bat" to compile and generate stubs
2. Run "build.bat" to compile sample programs
c. vsphere-ws : Re-generate vim25 jar using the build scripts under (SDK/vsphere-ws/java/JAXWS)
1. build_vim25.bat compile and generate stubs
2. build_samples.bat Compiles sample programs (before compiling samples update the import
statements)
d. For rest of the libraries repeat the steps under each sub directories, i.e. eam, sms-sdk, spbm and
vslm.
Note : build-*.sh scripts can also be used for re-generating and compiling client stubs.
For detailed steps follow README under each of the SDK component.
E.g for ssoclient "SDK/ssoclient/java/JAXWS/readme_java.html#stub_generation" and for vsphere-ws "SDK/vsphere-ws/java/JAXWS/readme_java.html"
Workaround:
No workaround available.
Updating the jaxws-ri library version to 3.0.1 would have solved the issue. However, vSphere Management SDK Java bundles and uses jaxws-ri version 2.3.3, stubs generated with this jaxws-ri version has "javax.xml.ws.Service" in service stubs. Since, jaxws-ri changed their package namespace from javax.* to jakarta.*.
After updating the library, Stubs need to be re-generated and compiled. Follow the below steps.
Re-generate stubs using higher version of jaxws-ri.
1. Download jaxws-ri version 3.0.1 or higher and replace it with existing jaxws-ri under the SDK/libs directory.
a. Link to JAX WS RI Standalone Zipped Bundle via various repositories: https://mvnrepository.com/artifact/com.sun.xml.ws/jaxws-ri/3.0.1
2. Re-generate client bindings(ssoclient.jar/vim25.jar) using WSDL files from SDK. Since vsphere-ws
has a dependency on sso client, the sso client library and samples (sso.jar) need to be built first.
a. Existing samples across SDK's sub-directries, viz. ssoclient, vsphere-ws, eam, sms-sdk, spbm and vslm
must be updated. i.e. Following import statements should be changed from
"javax.xml.ws.*", "javax.xml.bind.*" and "javax.xml.soap.*"
to "jakarta.xml.ws.*", "jakarta.xml.bind.*" and "jakarta.xml.soap.*" respectively.
b. ssoclient : Scripts to build the sso jar and the samples are present under (SDK/ssoclient/java/JAXWS)
1. Run the command "build_ssoclient.bat" to compile and generate stubs
2. Run "build.bat" to compile sample programs
c. vsphere-ws : Re-generate vim25 jar using the build scripts under (SDK/vsphere-ws/java/JAXWS)
1. build_vim25.bat compile and generate stubs
2. build_samples.bat Compiles sample programs (before compiling samples update the import
statements)
d. For rest of the libraries repeat the steps under each sub directories, i.e. eam, sms-sdk, spbm and
vslm.
Note : build-*.sh scripts can also be used for re-generating and compiling client stubs.
For detailed steps follow README under each of the SDK component.
E.g for ssoclient "SDK/ssoclient/java/JAXWS/readme_java.html#stub_generation" and for vsphere-ws "SDK/vsphere-ws/java/JAXWS/readme_java.html"
Workaround:
No workaround available.
Feedback
Yes
No
Powered by
