cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Some issues with logging and tests
Date Sun, 30 Sep 2012 16:59:38 GMT
On 30/09/12 14:33, Benson Margulies wrote:
> I've got a case, for which I'm about to file a JIRA, in which I think
> that it's important that a particular situation leads to a log message
> with some minimal content with a particular log level. Have we got any
> tests for cases like this? I'm thinking about wiring up some sort of
> test rig for intercepting log messages for the purpose.
> Meanwhile, this particular case is perhaps worth a moment's discussion.
> In JAX-RS, consider the following circumstance:
> A resource accepts a parameter of bean type, and a mapper (in my case,
> the Jackson json mapper) is responsible for mapping from the incoming
> content to the bean. The incoming headers specify 'accept:
> application/json', since that's what the function (normally) produces.
> Now, someone debugging a python client sends a json blob with a
> misspelled item in it. The mapper throws an exception.
> WebApplicationExceptionMapper catches it and maps it to a 500,
> accompanying the action with a log message at DEBUG.
> The client gets a naked '500', no message anywhere. I suspect, but I'm
> not sure, that the mapper would send back some backtracey verbiage if
> the accept header were no so restrictive.
> On the one hand, a WARN would be handy, as it's a pain to have to go
> adjust the logging config just to see why the client isn't working. On
> the other hand, a production application might get thousands of
> malformed inputs a day, and might not want all this traffic in the
> log.
> Do we have a design principle (written down?) about how we decide what
> should be logged non-DEBUG? Should errors resulting from ill-behaved
> clients get that treatment? If not, I shouldn't write a JIRA or change
> any code here.
As I said in the previous message, it is to do with the 
over-optimization of WebApplicationExceptionMapper.

By the way, I'm not sure I agree with the fix to CXF-4528.
This is now getting complicated: one has to install a fault logger to 
get a stack trace, and, on top of that, the logging will happen twice, 
if property is set and FINE is active...

Let me propose something slightly different: if the fault logger is 
installed and it handled the exception: then do nothing else, the logger 
can log or ignore the error message, if not - do print the warn message 
because a number of times this issue has been raised - and this can be 
optimized if needed by turning 'printStackTrace' to false.


Sergey Beryozkin

Talend Community Coders


View raw message