BTW, using the resource-bundle to perform formatting instead of slf4j, will
cause some additional overhead.
First, the slf4j {} formatter, is optimized, since it doesn't need to do any
fancy pattern parsing or conversion.
Second, you will need to guard *all* logger calls with their ifXxxEnabled()
variants to avoid unwanted string concatenation when the level is not enabled.
For example the new version of the code I mentioned before:
<snip>
logger.info(Messages.getMessage("clientResponseIsErrorCode", statusCode));
</snip>
This will always perform the formatting of the message, even if I have all wink
logging set to WARN and above.
But, if you left what was there before:
<snip>
logger.info(Messages.getMessage("clientResponseIsErrorCode"), statusCode);
</snip>
And then changed the resource bundle's messages to use {} instead of {0}, then
slf4j could delay the formatting until the time it knows that its going to emit
that log event.
--jason
On May 29, 2010, at 11:18 PM, Jason Dillon wrote:
> I'm seeing lots of stuff like:
>
> <snip>
> WARN [main] o.a.w.c.i.r.m.ResourceMetadataCollector - Sub-Resource locator
> {0} is annotated with Consumes/Produces. These annotations are ignored for
> sub-resource locators
> WARN [main] o.a.w.c.i.r.m.ResourceMetadataCollector - Sub-Resource locator
> {0} is annotated with Consumes/Produces. These annotations are ignored for
> sub-resource locators
> INFO [main] o.a.w.c.i.a.ApplicationFileLoader - Loading application from
> jar:file:/Users/jason/.m2/repository/org/apache/wink/wink-json-provider/1.1-incubating/wink-json-provider-1.1-incubating.jar!/META-INF/wink-application
> INFO [qtp1421876889-13] o.a.w.s.i.r.ResourceRegistry - Could not find any
> method in class {0} that supports {1}
> INFO [qtp1421876889-13] o.a.w.s.i.RequestProcessor - {0} occurred during the
> handlers chain invocation
> INFO [main] o.a.w.c.i.ResourceImpl - Client response is an error code: {0}
> </snip>
>
> due to logger calls like:
>
> <snip>
> logger.info(Messages.getMessage("clientResponseIsErrorCode"), statusCode);
> </snip>
>
> From the looks of it (at least for this specific line) its been fixed.
> Logging is completely useless with 1.1, I think you guys should roll out a
> 1.1.1 with logging fixed.
>
> --jason
