cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem jiang <willem.ji...@gmail.com>
Subject Re: aligning exceptionMessgeCauseEnabled for CXF-4689 (Re: interpretation of jaxws 10.2.2 exception handling
Date Tue, 18 Dec 2012 14:20:27 GMT
+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