Well, the issue is that the system is "working as designed", however, it
may not be working as the user THINKS it is designed.
For example, if I create an exception like:
public class FooException extends Exception {
String user, group;
public FooException(String msg, String user, String group) {
super(msg);
this.user = user;
this.group = group;
}
.... getter/setters for group/user ....
}
and throw that, I MAY expect the user and group to be added to the
details of the fault and then mapped into a FooException on the client
side. However, that won't happen with JAXB because it doesn't have a
default constructor so it would never be added to the context. Logging
at FINE basically would never tell me that the databinding couldn't
handle it.
That's pretty much why I made it log at WARNING. It falls into the "we
do have a default behavior to handle this, but it's probably not what
you want" realm of things that I do like to let the user know about.
Dan
On Friday 19 October 2007, Benson Margulies wrote:
> I'd vote for FINE. The system is 'working as designed'.
>
> If we push it to FINE, I'd not bother to keep track.
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 19, 2007 1:13 PM
> > To: cxf-user@incubator.apache.org
> > Cc: Benson Margulies
> > Subject: Re: JAXB + JAX-WS + faults
> >
> > On Friday 19 October 2007, Benson Margulies wrote:
> > > Should we reduce the logging noisiness of this process?
> >
> > That's a good question. I can definitely see taking the stack trace
>
> off
>
> > of it. That's just scary to users. I'd probably change the
> > message to:
> >
> > Exception occurred while writing user fault. {0} Delegating to
>
> binding
>
> > fault writing routines.
> >
> > Next question: what log level? FINE, INFO, WARNING?
> >
> > Next: should we keep track of the classes that we couldn't write and
>
> just
>
> > log on the FIRST time that type is encountered?
> >
> >
> > Thoughts?
> > Dan
> >
> > > > -----Original Message-----
> > > > From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> > > > Sent: Friday, October 19, 2007 1:01 PM
> > > > To: cxf-user@incubator.apache.org
> > > > Cc: Benson Margulies
> > > > Subject: Re: JAXB + JAX-WS + faults
> > > >
> > > >
> > > > Benson,
> > > >
> > > > This is a sideaffect of the fixes we did for the Aegis faults
> > > > with the JAX-WS frontend. By making the WebFaultOutInterceptor
>
> delegate
>
> > > > up to the normal fault handling, the databinding gets a crack at
> > > > trying to write the fault.
> > > >
> > > > In 2.0.2, if the exception didn't have an @WebFault, the
> > > > WebFaultOutInterceptor would ignore it and then the SOAPFaultOut
> > > > stuff would then just map the getMessage() call onto the wire an
>
> no
>
> > > > other
> > >
> > > data
> > >
> > > > would get sent on the wire.
> > > >
> > > > With 2.0.3, the superclass gets a chance which basically feeds
> > > > the
> > >
> > > fault
> > >
> > > > into the databinding writer. In this case, JAXB doesn't know
> > > > what to
> > >
> > > do
> > >
> > > > with it and throws an exception. The FaultOutInterceptor does
> > >
> > > swallow
> > >
> > > > that exception so it does properly go to the SOAPFaultOut stuff
> > > > as before, but I did log it so you know any detail that may be
> > > > in the Exception that you expected to be on the wire won't be
> > > > there.
>
> The
>
> > > > databinding had no clue what to do with it.
> > > >
> > > >
> > > > Dan
> > > >
> > > > On Thursday 18 October 2007, Benson Margulies wrote:
> > > > > Since moving to the latest 2.0.3 snapshot, I'm getting an
> > > > > exception when marshalling a fault declared on a 'throws'
>
> clause.
>
> > > > > No
> > >
> > > @WebFault.
> > >
> > > > > This didn't happen with 2.0.2 afaik.
> > > > >
> > > > > WARNING: Exception occurred while writing fault.
> > > > > org.apache.cxf.interceptor.Fault: Marshalling Error:
> > > > > com.basistech.ws.fortest.TestException is not known to this
> > > > > context at
>
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
