cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Some issues with logging and tests
Date Sun, 30 Sep 2012 13:33:38 GMT
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.

Mime
View raw message