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