webservices-rt.jar contains embedded slf4j api

[msevcenko]

The webservices-rt.jar bundle contains a copy of slf4j api jar, or more precisely some version of that api.

May I ask, what is the point of such bundling, instead of declaring it as a depednecy?

The unfortunate consequences of having a copy of the jar, include:

1. you cannot upgrade the slf4j api, namely to slf4j 2, which is required by some modules
2. more precisely, you cannot do it reliably, if you include original slf4j api jar, the JVM may use the original api or may use the copy, which may make things even more complicated

Is there any workaround to this problem? Or is there an unbundled version of webservices-rt, not having slf4j included?

[dmatej]

The reason is xmlsec, I have created a PR recently, but I was asked to split it to parts (it is a bigger step for next major version). I will get to that this week -> result will be removal of the whole dependency, so you can use any logging framework you want.
See #421

[lukasj]

The reason is xmlsec,

the are more reasons but it is true that xmlsec is the main one.

Possible workaround depends on the exact use-case. If no advanced features are used/required, consider using jax-ws ri directly (com.sun.xml.ws:jaxws-rt), if no advanced security features are used/required, exclusion of xmlsec dependency may be enough. If all metro features are needed, one can use either org.glassfish.metro:webservices-osgi or to get the finest control over all dependencies - org.glassfish.metro:wsit-api + org.glassfish.metro:wsit-impl. The latter artifacts are good for maven (and better if JPMS support is required), the former for Ant as they offer less files to manage (and provide no JPMS support).

[msevcenko]

Thanks for prompt response. Looks like that using the wsit-impl alone (with its numerous transitive dependencies) works for us ans solves the problem. Our app both consumes and exposes web services, but I don't think we use anything advanced. I checked that at least consuming web services works fine with this setup.

[dianalo]

We are still struggling with the slf4j-api included in webservices-extra-xmlsec.
We are depending on webservices-api:4.0.1 resp. webservices-rt:4.0.1 and deploy our application to a Tomcat 10.x.
In some cases, startup fails with an UnsupportedOperationException: "This code should never make it into the jar".
Coming from the slf4j-api included via webservices-extra-xmlsec and unfortunately loaded by the classloader.

As of today, is it still necessary for xmlsec to use the dependencies bundled in webservices-extra-xmlsec?
What problems could arise, when excluding webservices-extra-xmlsec and using xmlsec's original dependencies?

We also tried to swap webservices-rt:4.0.1by org.glassfish.metro:webservices-osgi resp. org.glassfish.metro:wsit-impl. But as expected just this didn't solve the problem. How exactly could we avoid the slf4j-api conflict by using these other dependencies?

Thank you for helping us.