<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi colleagues, and thanks for taking time and looking into.<br>
<br>
'On-topic' first: I am really new to the SLF4J world (though I like
it), so my judgements may be shallow. I admit that some new API for
bridging SLF4J with substitution engines might make the whole design
better. I'll be glad to support the new API, should it appear. Yet I
do not feel that things are too bad now with substitution wrappers
regarding CPU efficiency at trace/debug levels. The original
org.slf4j.cal10n.
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
LocLogger class does take necessary care to check if the requested
logging level is enabled before doing anything CPU-expensive. So
does my I15dLogger, as it was written under strong influence of the
former one. Sorry if javadocs produce different impression. I'll get
javadocs more clear on this in the next release.<br>
<br>
Now maybe a little 'off-topic', if i18n is off-topic for SLF4J :)
Gettext is really a great tool, and should I need to
internationalize an existing application, it might be one of the
first candidates to consider. Still its core design has a downside
that 'consumer/resource' links are ordinary strings, like with
standard ResourceBundle approach, and so are prone to getting out of
sync; tools are available to detect these cases, but they require
extra build phases. And extra build phases are also not an advantage
IMHO... A definite advantage of gettext is in its pluralization
facilities. This is something that my 'nobundle' library still needs
to take care of...<br>
<br>
But getting this discussion deeper may get off-topic indeed. And
I'll be pleased to know your further comments. Should you prefer to
continue in private mail, I'll be glad to :) And I would especially
appreciate if somebody could look into the I15dLogger code to see if
everything is right with delicate SLF4J features...<br>
<br>
Regards,<br>
Sergey<br>
<br>
<br>
<div class="moz-cite-prefix">On 19.06.13 03:24, Chris Pratt wrote:<br>
</div>
<blockquote
cite="mid:CAALdY0xY_dy6VGVmnJ13Rz2cUQQLLq=BnsqGk0L5d0VzTSTY3Q@mail.gmail.com"
type="cite">
<div dir="ltr">Toolforger, I totally agree. I would love to merge
the formatter from <a moz-do-not-send="true"
href="http://code.google.com/p/anodyzed">http://code.google.com/p/anodyzed</a>
directly into a pluggable SLF4j interface, now that the newest
SLF4j supports variable arguments. I already check
isLevelEnabled before doing any formatting, but it would be much
easier for end users if it was pluggable.
<div style="">
(*Chris*)</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Jun 18, 2013 at 3:33 PM,
Toolforger <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:toolforger@durchholz.org" target="_blank">toolforger@durchholz.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
SOMEWHAT OFF-TOPIC FOR SLF4J<br>
<br>
I'd seriously suggest reading the background information in
the gettext documentation.<br>
gettext is a great improvement over most of its would-be
successors, and I'm awfully sorry to say that your approach
does not constitute an exception. (I'm willing to elaborate
in private mail, this is indeed off-topic for slf4j.)<br>
<br>
Also, from the Javadoc, it seems that you're doing
substitution in <a moz-do-not-send="true"
href="http://logger.info" target="_blank">logger.info</a>,
logger.warn etc, before slf4j has a chance to check whether
the message should even get printed.<br>
That's negating SLF4J's mission statement of minimum
overhead in the do-not-log case. This is a serious problem
for trace messages, and sometimes for debug messages, too.<br>
<br>
NOW ON-TOPIC FOR SLF4J - FEATURE REQUEST<br>
<br>
I18n for SLF4J's messages is essentially not very useful
because some languages require a different sentence fragment
order, which means that parameter order might have to be
changed and SLF4J does not allow that. (Plural handling can
be done, but it's not very<br>
What I would like to see is an API for plugging in alternate
substitution engines. This should be called afterSLF4J has
determined that the message indeed needs to be logged.<br>
Engines that I can easily see use cases for are:
slf4j-native with {}; JDK MessageFormat with (among other
things) {0}/{1}/...; gettext; and the i18n facilities of
ICU4J. Since a program might consist of many libraries from
different sources, this should probably be configurable on a
per-package basis, and hardcoded in Java because the choice
of substitution syntax is hardcoded, too.<br>
<br>
Feedback on this feature request welcome.
<div class="HOEnZb">
<div class="h5"><br>
_______________________________________________<br>
slf4j-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a><br>
<a moz-do-not-send="true"
href="http://mailman.qos.ch/mailman/listinfo/slf4j-user"
target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
slf4j-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a>
<a class="moz-txt-link-freetext" href="http://mailman.qos.ch/mailman/listinfo/slf4j-user">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a></pre>
</blockquote>
<br>
</body>
</html>