As per PETALSDISTRIB-133, technical errors should be kept as errors and not transformed to fault.
Now that PETALSCDK-130 is closed, FaultException, DocumentException, SOAP11FaultServerException and SOAP11FaultClientException should be removed from the CDK.
Note: these exception were used previously by components to build faults that were coherent with their WSDL: for that case, we should provide utils to create Fault from a Document or other XML in-memory representation of a fault.
But that shouldn't be done using Java exceptions (except maybe for the case of the POJO that seems to be relying on it... maybe we should move that "exception-based fault handling" logic to the pojo if we think current users of the component are exploiting them! (or provides an easy to use alternative)).
As per PETALSDISTRIB-133, technical errors should be kept as errors and not transformed to fault.
Now that PETALSCDK-130 is closed, FaultException, DocumentException, SOAP11FaultServerException and SOAP11FaultClientException should be removed from the CDK.
Note: these exception were used previously by components to build faults that were coherent with their WSDL: for that case, we should provide utils to create Fault from a Document or other XML in-memory representation of a fault.
But that shouldn't be done using Java exceptions (except maybe for the case of the POJO that seems to be relying on it... maybe we should move that "exception-based fault handling" logic to the pojo if we think current users of the component are exploiting them! (or provides an easy to use alternative)).
Environment:
-
Issue Links
Depends
This issue depends on:
PETALSCDK-130
Technical errors should NOT be transformed to Fault, and even less SOAPFault
PETALSSEJSR-28
Technical errors should NOT be transformed to Fault