Hi colleagues, and thanks for taking time and looking into.
'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.
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.
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...
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...
Regards,
Sergey
On 19.06.13 03:24, Chris Pratt wrote:
Toolforger, I totally agree. I would love to merge the formatter from
http://code.google.com/p/anodyzed 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.
(*Chris*)
On Tue, Jun 18, 2013 at 3:33 PM, Toolforger <[email protected]
<mailto:[email protected]>> wrote:
SOMEWHAT OFF-TOPIC FOR SLF4J
I'd seriously suggest reading the background information in the
gettext documentation.
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.)
Also, from the Javadoc, it seems that you're doing substitution in
logger.info <http://logger.info>, logger.warn etc, before slf4j
has a chance to check whether the message should even get printed.
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.
NOW ON-TOPIC FOR SLF4J - FEATURE REQUEST
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
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.
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.
Feedback on this feature request welcome.
_______________________________________________
slf4j-user mailing list
[email protected] <mailto:[email protected]>
http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
