cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject Re: aligning exceptionMessgeCauseEnabled for CXF-4689 (Re: interpretation of jaxws 10.2.2 exception handling
Date Wed, 19 Dec 2012 12:10:45 GMT
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 <willem.jiang@gmail.com>:
> +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 <elakito@gmail.com (mailto:elakito@gmail.com)>:
>> > 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 <dkulp@apache.org (mailto:dkulp@apache.org)>:
>> > >
>> > > On Dec 10, 2012, at 3:29 AM, Aki Yoshida <elakito@gmail.com (mailto:elakito@gmail.com)>
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
>> > > dkulp@apache.org - http://dankulp.com/blog
>> > > Talend Community Coder - http://coders.talend.com
>> >
>>
>
>
>

Mime
View raw message