cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject aligning exceptionMessgeCauseEnabled for CXF-4689 (Re: interpretation of jaxws 10.2.2 exception handling
Date Tue, 18 Dec 2012 14:02:49 GMT
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

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 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
  o Fault("fault happened", new RuntimeException("unexpected")) =>
"fault happened Caused by unexpected".
  o Fault(new RuntimeException("unexpected")) => "unexpected Caused by
  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

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?


Regards, Aki

2012/12/10 Aki Yoshida <>:
> 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 <>:
>> On Dec 10, 2012, at 3:29 AM, Aki Yoshida <> wrote:
>>> Hi,
>>> There is a mail thread on users@cxf regarding the soap faultstring
>>> generation rule.
>>> 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
>> -
>> Talend Community Coder -

View raw message