Consider upgrading to WSS4J 3.0.0.

[jezovuk]

As far as I can tell, WSS4J version currently required by spring-ws is 2.4.1. According to WSS4J web site and release notes, 3.0.0 is the first "Jakartified" version.

See actual commit implementing the change in WSS4J for additional details. In light of #1213 and general push away from javax and towards jakarta API-s, upgrade seems like a reasonable thing to do (if I'm not missing something, which I might be, since I'm not a heavy spring-ws user).

[cachescrubber]

Hi @gregturn, afaik spring-boot 3.2 release is scheduled for this autumn - imo this issue alone would justify a 4.1.0 release. I would really like to see spring-boot 3.2 dependency management picking this up.

[gregturn]

For starters, I have tested Spring WS against WSS4j 3.0.0, and it seems to work with no changes. As for creating another Spring WS release version, I'm not yet convinced we need that. A single 3rd party dependency's major feature upgrade isn't quite enough for that.

And to clarify, Spring Boot 3.2 is currently based on Spring WS 4.0.x.

If we include testing against "wss4j-next" in our CI solution, then that may offer enough confidence for you to simply exclude Wss4j from your own build and supplant it with 3.0.0 instead.

[jezovuk]

Hi @gregturn. I'm not sure I understand your position completely.

Are you suggesting that spring-ws will continue using WSS4J 2.4.x for foreseeable future (instead of switching to 3.x) or merely that there will be no dedicated spring-ws release just for the sake of WSS4J upgrade?

If everything works ok with WSS4J 3.x (as your testing results indicate), why not switch to that version as required dependency (whenever it fits the spring-ws release schedule, not necessarily in a dedicated spring-ws release)?
IIUC, WSS4J 3.x uses jakarta namespaces, so it would be in line with #1213 to (eventually) switch to that version.

[gregturn]

Spring WS has yet to see a reason to launch 4.1.x line at this point in time. We don't have any sweeping changes at this point to make.

If Wss4j 2.4 is using pre-Jakarta EE 9 stuff, we haven' heard (yet) of that. I don't know if that either means its mostly used internally, or if people using Spring WS with Wss4j haven't made the jump. But either way, it passes our testing.

To maintain binary compatibility, we typically don't make a switch to a new major version (2.4 -> 3.0) without a minor version change in Spring WS (4.0 -> 4.1). Part of the reason for coming out with Spring WS 4.0 was to bump other libraries that were vital to pick up Jakarta EE 9.

This would be the first time I've heard of Wss4j having issues with Jakarta EE 9. Perhaps our testing doesn't expose it? If you were to procure a test scenario that exposed such a situation where Spring WS 4.0 combined with Wss4j 3.0 caused a Jakarta EE 9 issue, that would give us grounds to solve such a problem.

But as things currently stand, it looks like simply upgrading a project to use Wss4j 3.0 won't run into any issues with Spring WS 4.0.

[cachescrubber]

I should have explained in more depth why I think spring-ws should pick up wss4j 3.0.0, even at the cost of a new minor release.

The main reason I still think this would justify a new minor release line of spring-ws (4.1.x) is to complete the JakartaEE migration. Ideally, wss4j 3.0.0 would have have been part of spring-ws 4.0.x, probably it was a near miss. Now that it is available upgrade spring-ws and take advantage of the upcoming spring-boot minor release in order to pick it up. Many projects have yet to migrate to spring-boot 3 / JakartaEE9+. Possible future issues like #1360 could be avoided in the first place.

Another reason is plain dependency management. Wss4j 2.4.1 has transitive dependencies which have serious security issues (BouncyCastle, for example). In the meantime, wss4j 2.4.2 and 3.0.2 have been released. It would be great value for spring-ws users to get regular dependency updates by simply using a current spring-boot parent or spring-boot-dependencies bom.

[jezovuk]

@gregturn Thanks for the answer.

I mostly agree with what @cachescrubber wrote. I do not have an explicit problem using spring-ws 4.0.x with wss4j 2.4.1, but judging from wss4j jakarta upgrade changes it seems quite possible that there some problematic use cases might exist.

[gregturn]

@cachescrubber I have discussed this issue with the Spring Boot team. Since there is no autoconfiguration nor version management that involves Wss4j, they are open to the possibility of an upgrade to a major version of Wss4j in a service release of Spring WS.

I think the criteria under which to make such a move in Spring WS would require exposing that Wss4j 2.4 does NOT work properly with Jakarta EE 8 but DOES work with Jakarta EE 9. Right now, it may be that we don't see this due to all method signatures and return types are not based upon Jakarta EE, but instead on interfaces that are still present in the JDK (e.g. javax.security and javax.xml.namespace), hence we can't see the issue.

Spring WS Security has lots of test cases concerning Wss4j. If you were to help us write a test case that exposed this Jakarta EE 9 lack of support, it would help us very much work toward making this transition.