+1 for get more meaningful exception message.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Tuesday, December 18, 2012 at 10:02 PM, Aki Yoshida wrote: > Hi Willem, Team, > > I am working on CXF-4689 that requests for a feature to return the > runtime exception information. Initially, as this question was raised > on users@cxf [1], I suggested the requester to use the > exceptionMessageCauseEnabled property. However, this did not work, as > this option only writes additionally ex.getMessage() and this is null > in runtime exceptions. Furthermore, during this discussion, it was > pointed out that the jaxws spec section 10.2.2 specifies that the > faultstring value must be constructed from ex.toString() when > ex.getMessage() is null for runtime exceptions. > > As this potentially touches the security aspect, Glen and I discussed > over it [2] and I am looking for a solution using a configurable > property. > > In principle, the purpose of this exceptionMessageCauseEnabled, which > was introduced for CXF-3443 [3], is quite similar to the original > requester's use case. However, its behavior differs from what is > specified in the jaxws's faultstring rule and also from what the > javadoc in Message.java on this property says. So my question is > whether we can align the behavior of this property. > > Currently, this property constructs the faultstring from > > fault.getMessage() + " Caused by " + cause.getMessage() > > That means (using the behavior prior to my current temporary change in > Fault, which I intend to revert and replace it with a more appropriate > solution), > o Fault("fault happened", new RuntimeException("unexpected")) => > "fault happened Caused by unexpected". > o Fault(new RuntimeException("unexpected")) => "unexpected Caused by > unexpected" > o Fault(new RuntimeException()) => "null Caused by null". > > The second and third cases do not seem practical. One possibility is > to change the behavior based on the getMessage() value. > > For example, if we have > if fault.getMessge() is null but cause.getMessage() isn't null or both > are not null and equal, we can use cause.getMessage(). > if both fault.getMessage() and cause.getMessage() are null, we can use > cause.toString() > > With this rule, we get for the second and third cases the faultstring > that conforms to the jaxws faultstring rule. > o Fault(new RuntimeException("unexpected")) => "unexpected" > o Fault(new RuntimeException()) => "java.lang.RuntimeException". > > Do you think we can unify this behavior? Or do you think we should > introduce a separate property to turn on this jaxws's faultstring > generation rule? > > 1. > http://cxf.547215.n5.nabble.com/SOAPFault-message-improvement-in-CXF-when-there-is-unchecked-NPE-tc5719398.html#a5719568 > 2. https://issues.apache.org/jira/browse/CXF-4684 > 3. https://issues.apache.org/jira/browse/CXF-3442 > > Regards, Aki > > 2012/12/10 Aki Yoshida <[email protected] (mailto:[email protected])>: > > Hi Dan, > > > > The spec seems to say that ex.toString() is only used for message-less > > runtime exceptions from service endpoints or SOAPFaultException from > > handlers. That would mean unexpected runtime exceptions from the > > processing runtime are not exposed into the faultstring by default. > > This could be intentional from security concerned people of not > > wanting to expose technical details of unexpected runtime errors. > > Maybe that would be overly concerned but it could be. > > > > In that case, I thought we could follow the same rule and limit the > > use of ex.toString() to only service endpoints exceptions. > > > > Thanks for your comments. As you suggest, we will probably look at > > what RI is doing. > > > > regards, aki > > > > 2012/12/10 Daniel Kulp <[email protected] (mailto:[email protected])>: > > > > > > On Dec 10, 2012, at 3:29 AM, Aki Yoshida <[email protected] > > > (mailto:[email protected])> wrote: > > > > > > > Hi, > > > > There is a mail thread on users@cxf regarding the soap faultstring > > > > generation rule. > > > > http://mail-archives.apache.org/mod_mbox/cxf-users/201212.mbox/%3CCANXr88J3iiWU_d_xrBDv0x5msKH9FiWVP-DcQA9fOWC_3p%3DFvQ%40mail.gmail.com%3E > > > > > > > > Could someone familiar with section 10.2.2 of the jaxws spec comment > > > > on this, in particular, what is exactly meant as the exception from > > > > service endpoints. > > > > > > > > This section differentiates these service endpoints exceptions from > > > > those runtime exceptions raised by jaxws handlers. I am not sure if > > > > some of the cxf interceptors are to be interpreted as jaxws handlers > > > > (strictly speaking of the terminology, not, but logically some of them > > > > are playing the same role, hence my question). As I commented in the > > > > above mail thread, we need to apply this faultstring generation at the > > > > appropriate place depending on the interpretation of this section. > > > > > > > > > > > > > > > Honestly, this is an area where I think either interpretation would be > > > arguable if an issue came up. There are basically 3 places for the > > > exception: > > > > > > 1) Service Endpoint > > > > > > 2) JAX-WS Handler > > > > > > 3) CXF interceptor > > > > > > > > > For (1) and (2), I think it might be best to just write a small sample > > > and see what the RI does and go with that. If we behave the same as the > > > RI, there really wouldn't be much argument. > > > > > > That would leave (3). I don't really have a preference one way or another > > > on this. I guess whatever the the RI does for (2) would be appropriate, > > > but I'm not really feeling strongly one way or the other. Ideally, none > > > of *OUR* interceptors would be throwing an NPE as we'd have proper guards > > > in place and we'd be throwing proper exceptions, but that's certainly a > > > pie-in-the-sky goal. > > > > > > > > > > > > -- > > > Daniel Kulp > > > [email protected] - http://dankulp.com/blog > > > Talend Community Coder - http://coders.talend.com > > >
