| Summary: | JSR 105 exceptions should not have it's own 'cause' field | ||
|---|---|---|---|
| Product: | Security - Now in JIRA | Reporter: | Zoran Regvart <zregvart> |
| Component: | Signature | Assignee: | XML Security Developers Mailing List <security-dev> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | Java 1.4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
There is a reason behind this design. JSR 105 was designed to run on JDK 1.2 and up. This is documented in the API dependencies of the JSR 105 specification: http://jcp.org/aboutJava/communityprocess/final/jsr105/index.html . The Exception(Throwable cause) constructor did not get added to the JDK until version 1.4, so we could not use them. Having said that, Apache XML Security requires JDK 1.4 and up, so we should be able to change this implementation of JSR 105 to invoke these constructors. Sean, thanks for the prompt reply. Being that you are one of the maintenance leads of the JSR, what are the chances of updating the required JDK to 1.4, or even 1.5 -- the xml-dsig API would certainly benefit from generics? (In reply to comment #2) > Sean, thanks for the prompt reply. Being that you are one of the maintenance > leads of the JSR, what are the chances of updating the required JDK to 1.4, or > even 1.5 -- the xml-dsig API would certainly benefit from generics? No immediate plans. There are other minor API changes I would like to make as well, but all in all the API has been holding up pretty well since it was finalized. Also I would be interested in seeing if we could create a smaller API that would be more suitable for memory constrained platforms or for those that don't need all the bells and whistles of XML Signature. There is also the ongoing work of XML Signature 2.0 in the W3C XML Security working group and that will probably require changes to the API if it gains traction. |
All of the Exceptions in javax.xml.crypto.** packages are designed so that they have a Throwable cause field, this is an anti-pattern and should be avoided. Proper way of containing root cause for the exception is to call Exception(Throwable cause) or Exception(String message, Throwable cause) super constructor. To be fair this is somewhat indicated in the javadocs by the: "Note that the detail message associated with * <code>cause</code> is <i>not</i> automatically incorporated in * this exception's detail message." but I fail to see the reason for this design decision. The only reason I could hypothesize is that the root cause could contain sensitive information, but in that case implementation that threw the exception should not include any sensitive information, or should appropriately obfuscate the same. Implementing the exceptions by using appropriate super constructors would reduce the complexity of the current implementation, and would be inline with best practices for creating one's own exceptions.