Hi, Thanks Willem, I just submitted the revised fix that uses the exceptionMessageCauseEnabled property to construct the faultstring for both use cases.
regards, aki 2012/12/18 Willem jiang <[email protected]>: > +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 >> > >> > > >
