I started using Jakarta half a year ago, as it was promised to be the de-facto way to build a SOAP client that speaks to a WSDL server. Oh boy: growing pains. Did not expect that 2 decades of developer experience in Java EE would amount to nothing, for the people who implemented Jakarta. As impressive as the effort may be, the inexplicable regressions we faced when we got forced to upgrade to version 3 proved quite cumbersome.
To summarize: custom logging handlers failed after upgrading to version 3, because the underlying implementation that exports a message as a SOAP message is broken.
I started using Jakarta half a year ago, as it was promised to be the de-facto way to build a SOAP client that speaks to a WSDL server. Oh boy: growing pains. Did not expect that 2 decades of developer experience in Java EE would amount to nothing, for the people who implemented Jakarta. As impressive as the effort may be, the inexplicable regressions we faced when we got forced to upgrade to version 3 proved quite cumbersome.
I’d love to hear more about specifics.
Sure! I wrote all about it over on Medium: https://medium.com/@aev_software/java-jakarta-soap-wsdl-client-fails-to-read-soap-message-for-logging-38087a63ea6d
To summarize: custom logging handlers failed after upgrading to version 3, because the underlying implementation that exports a message as a SOAP message is broken.