java.lang.ClassNotFoundException: com.sun.xml.ws.spi.ProviderImpl
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at javax.xml.ws.spi.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.java:90)
at javax.xml.ws.spi.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java:123)
at javax.xml.ws.spi.ServiceLoaderUtil.newInstance(ServiceLoaderUtil.java:101)
at javax.xml.ws.spi.FactoryFinder.fromSystemProperty(FactoryFinder.java:122)
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:99)
at javax.xml.ws.spi.Provider.provider(Provider.java:96)
at javax.xml.ws.Service.<init>(Service.java:112)
Can you elaborate why you think that a non existing class in the java class path is related to docker?
I assume you get the error when you run your java application inside a container, created from an image you created yourself… so make sure you build your image in a way that all required dependencies of your code are available inside the image and know to the classpath. Looks like a pure java problem to me.
The same image working in lower version of docker with Hyper-V and WSL as well.
Extracted my app,jar and the verified the required jars are present.
I have tried with colleagues machines as well. Who were updated to latest docker they only facing this issue.
working fine, if we go back to older version of docker like 3.6 or below.
Please share with us why you think this makes sense from your perspective.
What docker does is, it starts the entrypointscript and/or command you defined in your Dockerfile.
Once it starts the java process, everything you see is the pure result of running your code in java. Forgive my lack of imagination, but I can not see how Docker should interfere or change the bahavior of the java process.
The only thing that would make sense is, if you test different tags of your image, like an old one that still works and the new that is broken.
Even with the
@meyay could imagine a better possible problem than I could. It would really make sense. For example if the old version stored the images somewhere else and when you downgrade, you get the old data again.
Despite the title, Hyper-V will not fail with a Java error message. That message comes from your application. Unless your application is doing something depending on the host kernel or host properties like vendor, the virtualization method should not matter.
It is still possible that there is a special configuration we don’t know about that affects your Java app, but that would not give a ClassNotFoundException.
To be clear, 3.6 is not a Docker version. That is the version of Docker Desktop. I don’t have any idea why that would matter. If you can share how you run the container and how you build the image if you build one, maybe we can notice something. Until that you can run a container from the image with a simple shell and check if the environment variables and any java related settings are correct.