Not passing causing exceptions to SOAPException makes troubleshooting very difficult

[glassfishrobot]

We recently had to troubleshoot a problem with some XML transformer library, which was being called by SAAJ. The troubleshooting became very painful because SAAJ likes to swallow the causing exception, thus we had a hard time to figure out the root causes, i.e. we had to patch SAAJ in order to get the needed information in the logs.

Please make sure that all caught exceptions that then get translated to SOAPExceptions get passed as the cause argument to the SOAPException.

[glassfishrobot]

Reported by vanto

[glassfishrobot]

vanto said: And here is the patch: https://gist.github.com/vanto/6241851. I hereby grant to use it under CDDL v1.1 and GPL v2 and any other license the project may decide to use in future.

[glassfishrobot]

gagordon said: Hi, thanks for pointing out the issues. Much of the code in this project has not been touched in over 10 years, as it has pretty much been in maintenance mode, and it is not likely that any major new code will be added any time soon. I can appreciate how those omissions would present a problem for someone using SAAJ in a specialized way as you are, such as setting the SOAP content from a specialized Source. For the typical user those error handling issues are less critical.

I am checking with some other folks as to whether there are any problems with adding the nested causes. If there are no concerns, I have the changes made in my local copies of the files and will check them in very soon. However, I need to check with the JAX-WS RI people as to whether this merits a new release, as the needs of JAX-WS RI typically dictate when a new SAAJ-RI release is made.

Thanks, Gary

[glassfishrobot]

gagordon said: We've discussed the change with the JAX-WS team, and the issue is not as straightforward as it may seem. In the case of nested exceptions in a Web Services stack, for security reasons, you might not always want to divulge the nested stack trace information, as it might show proprietary information about classes, etc.

JAX-WS has added a user configurable System property to enable the inclusion of nested exception information in the stack trace shown in the SOAP fault. Since a SAAJ SOAPMessage could be used as the response in a Provider Web Service implementation, we must abide by the same guidelines.

Therefore to fix this properly, we'd both need to add a System property that is false by default and also guard all thrown exceptions with a check for whether this property is set to know whether to include the cause. This could take some time to implement, and given that it does not add to the correct functioning of the code, I am going to unfortunately have to lower the priority on this issue. Given the code is open source and rarely changes, it looks like you have been able to solve your issue for now.

I will address the issue as soon as I can, but need to look at the JAX-WS code to understand all the implications.

[glassfishrobot]

gagordon said: Lowering priority as per previous comment posted.

[glassfishrobot]

vanto said: Hi Gary,

thanks for checking with the JAX-WS team and the explanations. I can understand the security issues, nevertheless I still think it is worth to find a solution for getting access to the nested exceptions. In our case, it was not a specialized way of using SAAJ but rather a commercial product which behaved differently on a production system than on a dev system. The problem was caused by a different class loading precedence, which caused to load a different TransformerFactory on the one system than on the other and thus showed a ~5 years old Xalan bug, which got hiccups with SOAP messages larger than 4MB. The exceptions we got from SAAJ were not helpful at all so we had to patch the jar on the production system, just to get access to nested exception and to then understand the problem. This approach, however, is something I consider highly dangerous and I'm pretty sure that other may run into similar problems as well. tl;dr: I perfectly understand your concerns and the priority lowering, but we of course would highly appreciate if you could find a solution that serves both, traceability and security

Thanks, Tammo

[glassfishrobot]

Was assigned to gagordon

[glassfishrobot]

This issue was imported from java.net JIRA SAAJ-71