This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "SLF4J: Simple Logging Facade for Java".
The branch, master has been updated
via 8a69afbdd1ae182456d87f774fc3f5f32ca33106 (commit)
Ralph Goers wrote:
In cases like event logging it may be that the event logs
are viewed by customer service reps speaking in multiple languages. In
that case the locale of the person viewing the log is important (which
may be days or months after the log entry was recorded).
Very good po
On Aug 19, 2009, at 2:15 PM, Ceki Gulcu wrote:
Ralph Goers wrote:
* The provision of the Locale should be an orthogonal concept to
the logging of messages and the creation of the Logger. This
should be handled via the MDC.
"could be handled via the MDC". There are other ways to do it but
On Aug 19, 2009, at 1:58 PM, Ceki Gulcu wrote:
Ralph Goers wrote:
As I've said, I'm not at all in favor of SLF4J "doing" I18N. It is
better to do it under a framework such as Spring's MessageSource
interface where you can either use the default implementation,
which uses ResourceBundles
Ralph Goers wrote:
* The provision of the Locale should be an orthogonal concept to the
logging of messages and the creation of the Logger. This should be
handled via the MDC.
"could be handled via the MDC". There are other ways to do it but that
is probably the simplest.
Pushing the locale
Ralph Goers wrote:
As I've said, I'm not at all in favor of SLF4J "doing" I18N. It is
better to do it under a framework such as Spring's MessageSource
interface where you can either use the default implementation, which
uses ResourceBundles, or easily provide your own. As I said, I'm also
On Aug 19, 2009, at 11:21 AM, Pete Muir wrote:
I think we are making progress here, and actually there isn't too
much work to do. Let me paraphrase to make sure I am understanding
you correctly.
* The source of messages should be abstracted behind an interface. A
default implementation t
Pete Muir wrote:
This is valid in Java 5 and above. For example:
public interface Logger {
public enum LogMessages {
WRONG_PASSWORD
}
public static class Test {
public void test() {
Logger logger = new Logger() {
public void warn(Enum message) {
On 19 Aug 2009, at 19:43, Ceki Gulcu wrote:
Pete Muir wrote:
Sorry, I was being loose with my language. I meant using an
enumerated type such as
enum LogMessages {
WRONG_PASSWORD, RIGHT_PASSWORD
}
log.warn(WRONG_PASSWORD);
What would the signature of log.warn() look like? Is the follow
Pete Muir wrote:
Sorry, I was being loose with my language. I meant using an enumerated
type such as
enum LogMessages {
WRONG_PASSWORD, RIGHT_PASSWORD
}
log.warn(WRONG_PASSWORD);
What would the signature of log.warn() look like? Is the following legal java?
interface Logger {
void
On 19 Aug 2009, at 19:18, Ceki Gulcu wrote:
Comments inline.
Pete Muir wrote:
Hi,
As discussed here https://jira.jboss.org/jira/browse/WBRI-290, we
would like to switch to slf4j as our logger (it offers a logging
facade, supports MDC/NDC and parameter replacement).
However, as Takeshi hig
I think we are making progress here, and actually there isn't too much
work to do. Let me paraphrase to make sure I am understanding you
correctly.
* The source of messages should be abstracted behind an interface. A
default implementation that uses resource bundles could be provided
for
Comments inline.
Pete Muir wrote:
Hi,
As discussed here https://jira.jboss.org/jira/browse/WBRI-290, we would
like to switch to slf4j as our logger (it offers a logging facade,
supports MDC/NDC and parameter replacement).
However, as Takeshi highlights here
https://jira.jboss.org/jira/brow
On Aug 19, 2009, at 8:31 AM, Pete Muir wrote:
Hi Ralph,
Whether or not resource bundles suck in our opinion, they are the
standard approach to this so I believe we can't just dismiss them.
Let me rephrase. It isn't just that they suck. In my environment
resource bundles don't work for I1
Hi Ralph,
Whether or not resource bundles suck in our opinion, they are the
standard approach to this so I believe we can't just dismiss them.
I'm also unsure how, in your approach, a framework would provide
i8ln'ized log messages which would be used?
On 17 Aug 2009, at 22:41, Ralph Goers
http://bugzilla.slf4j.org/show_bug.cgi?id=145
--- Comment #1 from Ceki Gulcu 2009-08-19 11:26:21 ---
If both are present *simulatenously* , slf4j calls will be delegated to log4j,
and log4j calls redirected to SLF4j, resulting in an endless recursion.
simulatenously is a typo
--
Configur
http://bugzilla.slf4j.org/show_bug.cgi?id=145
Summary: Typos in http://slf4j.org/legacy.html
Product: SLF4J
Version: 1.5.x
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: minor
Priority: P1
Compon
http://bugzilla.slf4j.org/show_bug.cgi?id=31
Ceki Gulcu changed:
What|Removed |Added
CC|lis...@qos.ch |
--
Configure bugmail: http://bugzilla.slf4j
18 matches
Mail list logo