From bugzilla-daemon at pixie.qos.ch Sun Aug 9 19:51:31 2009 From: bugzilla-daemon at pixie.qos.ch (bugzilla-daemon at pixie.qos.ch) Date: Sun, 9 Aug 2009 19:51:31 +0200 (CEST) Subject: [slf4j-dev] [Bug 144] New: Logger Interface Should (Arguably) Extend Serializable Message-ID: http://bugzilla.slf4j.org/show_bug.cgi?id=144 Summary: Logger Interface Should (Arguably) Extend Serializable Product: SLF4J Version: 1.5.x Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P3 Component: Core API AssignedTo: dev at slf4j.org ReportedBy: djgredler at gmail.com The fix to bug 71 made all Logger implementations serializable; however, it is not *guaranteed* that Logger instances are serializable because Logger does not extend the Serializable interface. This may not be doable due to backwards-compatibility concerns, but ideally Logger would extend Serializable, guaranteeing that all Logger implementations can be serialized. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From ceki at slf4j.org Mon Aug 10 17:41:55 2009 From: ceki at slf4j.org (ceki at slf4j.org) Date: Mon, 10 Aug 2009 17:41:55 +0200 (CEST) Subject: [slf4j-dev] svn commit: r1382 - slf4j/trunk/slf4j-site/src/site/pages Message-ID: <20090810154155.6A1782C5F30@pixie.qos.ch> Author: ceki Date: Mon Aug 10 17:41:55 2009 New Revision: 1382 Modified: slf4j/trunk/slf4j-site/src/site/pages/docs.html Log: - link to Jazoon 2009 presentation with audio Modified: slf4j/trunk/slf4j-site/src/site/pages/docs.html ============================================================================== --- slf4j/trunk/slf4j-site/src/site/pages/docs.html (original) +++ slf4j/trunk/slf4j-site/src/site/pages/docs.html Mon Aug 10 17:41:55 2009 @@ -50,6 +50,11 @@ SLF4J in 10 slides, by Ceki Gülcü +

SLF4J + and Logback projects, by C. Gülcü and S. Pennec + (Jazoon presentation with audio). +

Message-ID: 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 that uses resource bundles could be provided > for easy ootb experience. Yes, > * 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. > > IMO there are still a few questions to answer: > > * Takeshi original design allowed you to use Enums as keys for > messages. I'm personally not sure about this, I'm not really sure > what benefits it offers over Strings as keys Enums are usually associated with an integer "value" and a String description. The only value is that you might be able to get some optimization by using the integer value of the enum in some cases. I don't know that it is worth the effort to support it. > * How does a framework provide translated messages [1] to i8ln > layer? Can we also use the MDC here to push them in, and have the > appender read them? I'm not sure I understand the question. The framework will provide a method like: public String getMessage(String key, Object[] params); However the messages are stored is hidden behind the implementation of that interface. Something has to call getMessage(). Potential places are a) the application before calling SLF4J b) SLF4J before calling a logging implementation, c) In the logging implementation - such as in the Appender. > * Should there be a convention for the key used? For example a key > should use a FQN. No. The key is essentially a contract between the application and whatever the backing repository is. Everything else should be ignorant. > * How does the integrate with the various slf4j back ends? Do we > somehow want to map it to the JDK logging i8ln support? What about > log4j? If you take the approach I recommend - do it as late as possible - then it is outside the scope of SLF4J. It might be done in the Appender for the logging framework in use or it might actually happen in the application that is reading the log files based on the Locale of the user reading them. > > [1] I'm assuming that a framework developer will want to provide > translations for it's logging messages No. An I18N framework would only provide the format the messages have to be stored in. Applications using the framework will provide their own message sets and presumably have experts who can localize the message sets provided by the development team into the desired locales. > > Regarding your suggestion to enhance logback - I want to be able to > provide l10n for my log messages regardless of which logging back > end is in use (for example, the framework I am currently working on > currently targets JBoss AS, GlassFish, and Tomcat as possible > runtimes, which use a combination of JDK logging and log4j). Again, that depends. For example, Lillith (http://freshmeat.net/projects/lilith-viewer ) is an event viewer for Logback. It would be very appropriate for it to do this. Likewise with Apache Chainsaw for Log4j. Doing the L10N further up the chain limits the flexibility these tools can provide. Sometimes that is desirable, but my recommendation is to always start from as far back as possible and move up the stack only as far as you have to. Ralph > > On 19 Aug 2009, at 17:16, Ralph Goers wrote: > >> >> 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 I18N. I'm not in favor of having >> features implemented that I can't use. But my opinion doesn't >> really carry any more weight than yours. >> >>> >>> I'm also unsure how, in your approach, a framework would provide >>> i8ln'ized log messages which would be used? >> >> 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 planning on creating a framework to manage >> internationalized messages using Commons Configuration and XML files. >> >> In that scenario the application either calls getMessage() and then >> passes the resulting String to the log call or the application >> passes the message key as the message on the log call, which is the >> approach I would suggest. In the second scenario it is up to the >> Appender to resolve the key by calling getMessage(). Ideally, the >> Appender should be able to tell whether it is getting a key or the >> actual message text. This can be done simply by convention - i.e. a >> log message like "key=Message1" or by passing a parameter. There is >> no real need to enhance SLF4J to be able to do this. >> >> The piece that SLF4J is missing is the ability to detect the target >> Locale of the message. But even this can be handled without change >> to SLF4J. Just adding the Locale to the MDC would allow the >> Appender to do the right thing. Of course, you'd have to use a >> logging implementation that supports the MDC. >> >> In short, instead of asking for a change to SLF4J it would make >> more sense to me for you to ask for an enhancement to Logback so >> that any Appender can have the opportunity to internationalize the >> message. Currently you'd have to do that in a Layout, but I don't >> believe all Appenders support them. >> >> Ralph >> >> _______________________________________________ >> dev mailing list >> dev at slf4j.org >> http://www.slf4j.org/mailman/listinfo/dev > > _______________________________________________ > dev mailing list > dev at slf4j.org > http://www.slf4j.org/mailman/listinfo/dev From ceki at qos.ch Wed Aug 19 22:58:31 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Wed, 19 Aug 2009 22:58:31 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <014D9CDA-A9A4-4B50-A5DA-E8609EA17C9E@apache.org> <0A56E606-E28B-4850-988B-3DFD0E2A91A0@redhat.com> Message-ID: <4A8C6777.7050306@qos.ch> 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 > planning on creating a framework to manage internationalized messages > using Commons Configuration and XML files. In a way, MessageFormatter [1] performs a similar function to a ResourceBundle. It is also noteworthy that currently MessageFormatter.format() is invoked within slf4j bindings. Previously, users had asked that the MessageFormatter implementation be pluggable. Unfortunately, this is not possible because if library A depends on MessageFormatter_A and library B depends on MessageFormatter_B, and if MessageFormatter_A and MessageFormatter_B use incompatible message formatting conventions, for example "hello {}" and "hello {0}", then choosing MessageFormatter_A as the implementation will screw up messages generated by library B. The same problem would occur with resource bundles or its spring equivalents. > In that scenario the application either calls getMessage() and then > passes the resulting String to the log call or the application passes > the message key as the message on the log call, which is the approach I > would suggest. In the second scenario it is up to the Appender to > resolve the key by calling getMessage(). Ideally, the Appender should be > able to tell whether it is getting a key or the actual message text. > This can be done simply by convention - i.e. a log message like > "key=Message1" or by passing a parameter. There is no real need to > enhance SLF4J to be able to do this. Assuming we had I18NLogger_1 wrapping/decorating o.slf4j.Logger, a printing method, say i18nInfo() could be implemented as: public class I18NLogger_1 extends LoggerWrapper implements Logger I18NLogger(Logger logger) { super(logger, I18NLogger_1.class.getName()); } void i18nInfo(String message, Object... params) { if(logger.isInfoEnabled()) { // aMessageSourceImpl is some implementation of // org.springframework.context.MessageSource or similar // interface String m = aMessageSourceImpl.getMessage(message, params, locale); logger.info(m); } } } In the above code, only aMessageSourceImpl and locale are not clearly defined. Another possible implementation for I18NLogger is as follows: public class I18NLogger_2 extends LoggerWrapper implements Logger I18NLogger_2(Logger logger) { super(logger, I18NLogger_2.class.getName()); } void i18nInfo(String message, Object... params) { if(logger.isInfoEnabled()) { // I18N is a marker for all internationalized messages logger.info(I18N, message, params); } } } In this second implementation, internationalization is done within the appropriate appender or possibly a new logback component (e.g. ILoggingEventTransformer) which would know how to internationalize messages. It would do so only for messages marked with I18N. The advantage of this second approach is that Joran (logback's internal configuration framework) can be leveraged to configure things pretty much the end-user wants. See for example SiftingAppender [2] which is heavily based on Joran. > The piece that SLF4J is missing is the ability to detect the target > Locale of the message. But even this can be handled without change to > SLF4J. Just adding the Locale to the MDC would allow the Appender to do > the right thing. Of course, you'd have to use a logging implementation > that supports the MDC. FYI, all slf4j bindings, including slf4j-jdk14 and even slf4j-nop ship with functional MDC support. It's just that the underlying logging framework does not make use of the provided MDC data. > In short, instead of asking for a change to SLF4J it would make more > sense to me for you to ask for an enhancement to Logback so that any > Appender can have the opportunity to internationalize the message. > Currently you'd have to do that in a Layout, but I don't believe all > Appenders support them. I don't know. Logback is tempting because of all the customization it allows. I could even imagine adding a new component, say ILoggingEventTransformer, which could transform logging events with internationalization being one particular type of transformation. If ILoggingEventTransformer came before appenders, it could transform the event for all appenders. Nevertheless, the main advantage of logback is all the additional customization made possible. For Web Beans, I am under the impression that all logging back ends need to be supported, hence I18NLogger_1. What were the requirements again? :-) > Ralph [1] http://slf4j.org/xref/org/slf4j/helpers/MessageFormatter.html [2] http://logback.qos.ch/manual/appenders.html#SiftingAppender -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From ceki at qos.ch Wed Aug 19 23:15:30 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Wed, 19 Aug 2009 23:15:30 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <014D9CDA-A9A4-4B50-A5DA-E8609EA17C9E@apache.org> <0A56E606-E28B-4850-988B-3DFD0E2A91A0@redhat.com>

Message-ID: <4A8C6B72.7080102@qos.ch> 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 in every thread will not suite everyone. >> IMO there are still a few questions to answer: >> >> * Takeshi original design allowed you to use Enums as keys for >> messages. I'm personally not sure about this, I'm not really sure what >> benefits it offers over Strings as keys > Enums are usually associated with an integer "value" and a String > description. The only value is that you might be able to get some > optimization by using the integer value of the enum in some cases. I > don't know that it is worth the effort to support it. Unless enums have some other advantage that we did not think of. Takeshi can you describe the advantages of enums that you see? >> * How does a framework provide translated messages [1] to i8ln layer? >> Can we also use the MDC here to push them in, and have the appender >> read them? > I'm not sure I understand the question. The framework will provide a > method like: > public String getMessage(String key, Object[] params); > However the messages are stored is hidden behind the implementation of > that interface. Something has to call getMessage(). Potential places are > a) the application before calling SLF4J b) SLF4J before calling a > logging implementation, c) In the logging implementation - such as in > the Appender. Bingo. a), b) or c) is the question. There is also a) and b) combined. See my previous message. > Again, that depends. For example, Lillith > (http://freshmeat.net/projects/lilith-viewer) is an event viewer for > Logback. It would be very appropriate for it to do this. Likewise with > Apache Chainsaw for Log4j. Doing the L10N further up the chain limits > the flexibility these tools can provide. Sometimes that is desirable, > but my recommendation is to always start from as far back as possible > and move up the stack only as far as you have to. If SLF4J or logback provided a reasonable solution, it would help developers in solving the logging i18n issue by the mere fact of offering and thus blessing a solution. It could only do harm if the offered solution was particularly stupid or bad. Moreover, the solution provided in slf4j or logback (or in both in part) could lay the foundation of a better solution imagined by one of our users. > Ralph -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From rgoers at apache.org Wed Aug 19 23:21:14 2009 From: rgoers at apache.org (Ralph Goers) Date: Wed, 19 Aug 2009 14:21:14 -0700 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <4A8C6777.7050306@qos.ch> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <014D9CDA-A9A4-4B50-A5DA-E8609EA17C9E@apache.org> <0A56E606-E28B-4850-988B-3DFD0E2A91A0@redhat.com> <4A8C6777.7050306@qos.ch> Message-ID: <7750BF6E-D1CD-4126-A47D-C4707373B930@apache.org> 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, or easily provide your own. As I said, >> I'm also planning on creating a framework to manage >> internationalized messages using Commons Configuration and XML files. > > In a way, MessageFormatter [1] performs a similar function to a > ResourceBundle. It is also noteworthy that currently > MessageFormatter.format() is invoked within slf4j bindings. > Previously, users had asked that the MessageFormatter implementation > be pluggable. Unfortunately, this is not possible because if library > A depends on MessageFormatter_A and library B depends on > MessageFormatter_B, and if MessageFormatter_A and MessageFormatter_B > use incompatible message formatting conventions, for example "hello > {}" and "hello {0}", then choosing MessageFormatter_A as the > implementation will screw up messages generated by library B. The > same problem would occur with resource bundles or its spring > equivalents. While an I18N framework might do some sort of message formatting itself it wouldn't replace MessageFormatter.format(). In otherwords, lets say I have a couple of message definitions like Bank of America Welcome to ${name}, {} In this case one would hope that the framework would return "Welcome to Bank of America, {}". Presumably SLF4J's usual mechanism would replace the runtime variable. OTOH, if the formatting is deferred to the Appender then obviously the runtime variables would have to be replaced there. Many of the current I18N frameworks use the normal Java formatter for that. > >> In that scenario the application either calls getMessage() and then >> passes the resulting String to the log call or the application >> passes the message key as the message on the log call, which is the >> approach I would suggest. In the second scenario it is up to the >> Appender to resolve the key by calling getMessage(). Ideally, the >> Appender should be able to tell whether it is getting a key or the >> actual message text. This can be done simply by convention - i.e. a >> log message like "key=Message1" or by passing a parameter. There is >> no real need to enhance SLF4J to be able to do this. > > Assuming we had I18NLogger_1 wrapping/decorating o.slf4j.Logger, a > printing method, say i18nInfo() could be implemented as: > > public class I18NLogger_1 extends LoggerWrapper implements Logger > > I18NLogger(Logger logger) { > super(logger, I18NLogger_1.class.getName()); > } > > void i18nInfo(String message, Object... params) { > if(logger.isInfoEnabled()) { > // aMessageSourceImpl is some implementation of > // org.springframework.context.MessageSource or similar > // interface > String m = aMessageSourceImpl.getMessage(message, params, > locale); > logger.info(m); > } > } > } > > In the above code, only aMessageSourceImpl and locale are not > clearly defined. > > Another possible implementation for I18NLogger is as follows: > > public class I18NLogger_2 extends LoggerWrapper implements Logger > > I18NLogger_2(Logger logger) { > super(logger, I18NLogger_2.class.getName()); > } > > void i18nInfo(String message, Object... params) { > if(logger.isInfoEnabled()) { > // I18N is a marker for all internationalized messages > logger.info(I18N, message, params); > } > } > } > > In this second implementation, internationalization is done within > the appropriate appender or possibly a new logback component (e.g. > ILoggingEventTransformer) which would know how to > internationalize messages. It would do so only for messages marked > with I18N. Wow. How stupid of me. I completely forgot about Markers. That is an obvious and very good way of indicating whether the message is a key or text. > > The advantage of this second approach is that Joran (logback's > internal configuration framework) can be leveraged to configure > things pretty much the end-user wants. See for example > SiftingAppender [2] which is heavily based on Joran. > >> The piece that SLF4J is missing is the ability to detect the target >> Locale of the message. But even this can be handled without change >> to SLF4J. Just adding the Locale to the MDC would allow the >> Appender to do the right thing. Of course, you'd have to use a >> logging implementation that supports the MDC. > > FYI, all slf4j bindings, including slf4j-jdk14 and even slf4j-nop > ship with functional MDC support. It's just that the underlying > logging framework does not make use of the provided MDC data. Sure. But how would you write a Handler for JUL that could do it? > >> In short, instead of asking for a change to SLF4J it would make >> more sense to me for you to ask for an enhancement to Logback so >> that any Appender can have the opportunity to internationalize the >> message. Currently you'd have to do that in a Layout, but I don't >> believe all Appenders support them. > > I don't know. Logback is tempting because of all the customization > it allows. I could even imagine adding a new component, say > ILoggingEventTransformer, which could transform logging events with > internationalization being one particular type of transformation. If > ILoggingEventTransformer came before appenders, it could transform > the event for all appenders. Nevertheless, the main advantage of > logback is all the additional customization made possible. Yes. Doing it that way would be beneficial to some Logback users. Hopefully, it would still allow the message to be left unresolved in the case where the customer wants to write the message key and parameters to a database, not the localized message. > > For Web Beans, I am under the impression that all logging back ends > need to be supported, hence I18NLogger_1. > > What were the requirements again? :-) Lol. Ralph From rgoers at apache.org Wed Aug 19 23:31:54 2009 From: rgoers at apache.org (Ralph Goers) Date: Wed, 19 Aug 2009 14:31:54 -0700 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <4A8C6B72.7080102@qos.ch> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <014D9CDA-A9A4-4B50-A5DA-E8609EA17C9E@apache.org> <0A56E606-E28B-4850-988B-3DFD0E2A91A0@redhat.com>

<4A8C6B72.7080102@qos.ch> Message-ID: <44F44E34-DD87-4104-82CD-F639A73D9B76@apache.org> 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 >> that is probably the simplest. > > Pushing the locale in every thread will not suite everyone. Probably not. In those cases the method you described before using the LoggerContext would probably work. But it depends on the use case. In a lot of systems the operations staff will want all the log messages in a single language of the locale where the software is running and the locale of the end user will be irrelevant. 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). The least critical scenario, in my opinion, is where the log entry will be viewed by the end user. IMO this isn't the best use of a logging system. OTOH, in my case we would still put the locale of the end user in the MDC simply because other GUI components will want that information. > >>> IMO there are still a few questions to answer: >>> >>> * Takeshi original design allowed you to use Enums as keys for >>> messages. I'm personally not sure about this, I'm not really sure >>> what benefits it offers over Strings as keys >> Enums are usually associated with an integer "value" and a String >> description. The only value is that you might be able to get some >> optimization by using the integer value of the enum in some cases. >> I don't know that it is worth the effort to support it. > > Unless enums have some other advantage that we did not think of. > Takeshi can you describe the advantages of enums that you see? > >>> * How does a framework provide translated messages [1] to i8ln >>> layer? Can we also use the MDC here to push them in, and have the >>> appender read them? >> I'm not sure I understand the question. The framework will provide >> a method like: >> public String getMessage(String key, Object[] params); >> However the messages are stored is hidden behind the implementation >> of that interface. Something has to call getMessage(). Potential >> places are a) the application before calling SLF4J b) SLF4J before >> calling a logging implementation, c) In the logging implementation >> - such as in the Appender. > > Bingo. a), b) or c) is the question. There is also a) and b) > combined. See my previous message. > >> Again, that depends. For example, Lillith (http://freshmeat.net/projects/lilith-viewer >> ) is an event viewer for Logback. It would be very appropriate for >> it to do this. Likewise with Apache Chainsaw for Log4j. Doing the >> L10N further up the chain limits the flexibility these tools can >> provide. Sometimes that is desirable, but my recommendation is to >> always start from as far back as possible and move up the stack >> only as far as you have to. > > If SLF4J or logback provided a reasonable solution, it would help > developers in solving the logging i18n issue by the mere fact of > offering and thus blessing a solution. It could only do harm if the > offered solution was particularly stupid or bad. Moreover, the > solution provided in slf4j or logback (or in both in part) could lay > the foundation of a better solution imagined by one of our users. +1. That is why we would want to consider several use cases. I don't think there is a one size fits all solution. Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Wed Aug 19 23:41:14 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Wed, 19 Aug 2009 23:41:14 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <44F44E34-DD87-4104-82CD-F639A73D9B76@apache.org> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <014D9CDA-A9A4-4B50-A5DA-E8609EA17C9E@apache.org> <0A56E606-E28B-4850-988B-3DFD0E2A91A0@redhat.com>

@@ -492,7 +492,7 @@

Fixed bug 53 as reported by Heinrich Nirschl. The public method trace(String) in the Log4jLoggerAdapter - class incorrecly called the underlying log4j logger with level DEBUG + class incorrectly called the underlying log4j logger with level DEBUG instead of TRACE.

@@ -662,8 +662,8 @@ 29.

Fixed a syncroisation problem in factories of almost all SLF4J - bindings. This bug was reported independenly by Howard M. Lewis Ship +

+ * Please note that translating a java.util.logging event into SLF4J incurs the + * cost of constructing {@link LogRecord} instance regardless of whether the + * SLF4J logger is disabled for the given level. Consequently, j.u.l. to + * SLF4J translation can seriously impact on the cost of disabled logging + * statements (60 fold increase) and a measurable impact on enabled log + * statements (20% overall increase). + *

+ * + *

+ * If application performance is a concern, then use of SLF4JBridgeHandler is + * appropriate only if few j.u.l. logging statements are in play. + * * @author Christian Stein * @author Joern Huxhorn * @author Ceki Gülcü diff --git a/jul-to-slf4j/src/test/java/org/slf4j/bridge/SLF4JBridgeHandlerPerfTest.java b/jul-to-slf4j/src/test/java/org/slf4j/bridge/SLF4JBridgeHandlerPerfTest.java index 0933696..ae7d25c 100644 --- a/jul-to-slf4j/src/test/java/org/slf4j/bridge/SLF4JBridgeHandlerPerfTest.java +++ b/jul-to-slf4j/src/test/java/org/slf4j/bridge/SLF4JBridgeHandlerPerfTest.java @@ -38,6 +38,10 @@ public class SLF4JBridgeHandlerPerfTest extends TestCase { static String LOGGER_NAME = "yay"; static int RUN_LENGTH = 100*1000; + + // set to false to test enabled logging performance + boolean disabledLogger = true; + FileAppender fileAppender; org.apache.log4j.Logger log4jRoot; java.util.logging.Logger julRootLogger = LogManager.getLogManager() @@ -95,15 +99,17 @@ public class SLF4JBridgeHandlerPerfTest extends TestCase { public void testPerf() { SLF4JBridgeHandler.install(); - //log4jRoot.setLevel(org.apache.log4j.Level.ERROR); - + + if(disabledLogger) { + log4jRoot.setLevel(org.apache.log4j.Level.ERROR); + } julLoggerLoop(); double julAvg=julLoggerLoop(); - System.out.println("Average cost per call (JUL->SLF4J->log4j):"+julAvg +" nanos"); + System.out.println("Average cost per call (JUL->SLF4J->log4j): "+julAvg +" nanos"); slf4jLoggerLoop(); double slf4jAvg=slf4jLoggerLoop(); - System.out.println("Average cost per call (SLF4J->log4j):"+slf4jAvg +" nanos"); + System.out.println("Average cost per call (SLF4J->log4j): "+slf4jAvg +" nanos"); System.out.println("Ratio "+(julAvg/slf4jAvg)); } } diff --git a/slf4j-site/src/site/pages/legacy.html b/slf4j-site/src/site/pages/legacy.html index 327ab01..e729d82 100644 --- a/slf4j-site/src/site/pages/legacy.html +++ b/slf4j-site/src/site/pages/legacy.html @@ -193,14 +193,31 @@

The jul-to-slf4j module includes a jul handler, namely SLF4JBridgeHandler, that routes all incoming jul records to the - SLF4j API. See also SLF4JBridgeHandler - javadocs. Contrary to other bridging modules such as - jcl-over-slf4j and log4j-over-slf4j, which re-implement JCL and - respectively log4j, the jul-to-slf4j modules does not re-implement - the java.util.logging package because packages under the java.* - namespace cannot be replaced. + javadocs for usage instructions.

+ +

Contrary to other bridging modules such as jcl-over-slf4j and + log4j-over-slf4j, which re-implement JCL and respectively log4j, + the jul-to-slf4j modules does not re-implement the + java.util.logging package because packages under the java.* + namespace cannot be replaced. Instead, translates LogRecord into + their SLF4J equivalents. Please note that translating + java.util.logging events into SLF4J incurs the cost of + constructing LogRecord + instance regardless of whether the SLF4J logger is disabled for + the given level or nor. Consequently, j.u.l. to SLF4J translation + can seriously impact on the cost of disabled logging statements + (60 fold increase) and a measurable impact on enabled log + statements (20% overall increase). +

+ +

If application performance is a concern, then use of + SLF4JBridgeHandler is appropriate only if few j.u.l. logging + statements are in play.

jul-to-slf4j.jar and slf4j-jdk14.jar cannot be present simultaneously @@ -213,7 +230,7 @@ route jul records to SLF4J. Thus, if both jar are present simultaneously (and SLF4JBridgeHandler is installed), slf4j calls will be delegated to jul and jul records will be routed to SLF4J, - resulting in an endless recursion. + resulting in an endless loop.
----------------------------------------------------------------------- Summary of changes: .gitignore | 6 +++- .../java/org/slf4j/bridge/SLF4JBridgeHandler.java | 13 ++++++++ .../slf4j/bridge/SLF4JBridgeHandlerPerfTest.java | 14 ++++++-- slf4j-site/src/site/pages/legacy.html | 31 +++++++++++++++---- 4 files changed, 52 insertions(+), 12 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java From ceki at qos.ch Mon Aug 24 15:15:07 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Mon, 24 Aug 2009 15:15:07 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <696A920C-B79E-4F21-BA13-784D34E8D023@gmail.com> Message-ID: <4A92925B.1050007@qos.ch> Takeshi's submission is not a finished product so let's go easy on him. While I have still not bought the idea of levels in enums or resource bundles, I think the idea of using enums for resource bundle keys is an important step forward. Having levels in the enum or resource bundles (I actually did not see that in the code) is conceptually interesting and possibly quite correct but it duplicates the data found in logging statements (=logger invocations in java code). Moreover, we could dynamically change the level of a logging statement based on rules placed in a configuration file. Here is an example of one such rule: if event has I18 marker if event.key == XYZ_10120 then event.level = ERROR; if event.key == XYZ_11234 then event.level = WARN; if event.key == XYZ_08173 then event.level = DEBUG; endif We would need to find a way to state the above in XML but that should not be a problem. (We would also need to add a mechanism for dynamically modifying a logging event after its creation.) FYI, I have created a small project for experimenting with the enum as resource bundles keys idea. You can see the result at http://git.qos.ch/ or on github http://github.com/ceki/i18n/tree/master Ralph Goers wrote: > I found a few minutes to review the code this evening. There are several > things I don't care for in this implementation: > 1. While doable, plugging in new resolver implementations is kind of a > pain. You have to create an I18NLogManager, create the custom resolvers > and presumably new annotation resolvers, add them to the > CompositeResolvers then add those to the manager. Finally a new > I18nLoggerFactory has to be created taking the manager and setINSTANCE > called. > 2. The resolvers provide no mechanism for reloading the bundles if they > are modified. Many environments want 24x7 up time and do not want to > restart servers just to change message text. > 3. The implementation only supports a single Locale - the default. > 4. I dislike immensely having the log level in one property file and the > message text in another. This is very error prone. If you want log > levels then get rid of the property files and switch to using XML where > the log level and message can be bound together. Of course, this runs > the risk that the level might be different from one language to another. > Another option - which makes far more sense to me - is to not even have > a LogLevelResolver, just require the log level be defined in the enum > and just use that. > 5. Messages are always resolved in the writeLog method. This precludes > the option of the message keys being written to a database so the > message can be retrieved based on the user's locale or passing the > message to different machines where it can be logged using a Locale > appropriate for that environment. > 6. If you really, really want to use ResourceBundle's then at least make > Java 6 the minimum version and provide support for > ResourceBundle.Control. However, since ResourceBundles don't provide > support for reloading I'd avoid using them at all. > 7. It seems very strange to have the LogLevel enum have log methods and > that writeLog is actually calling them. > 8. The callerData is going to be useless since the LogLevel enum is just > using the standard SLF4J apis. Instead, the Logger needs to extend > org.slf4j.ext.LoggerWrapper and actually log from that class. > 9. The format of the LogMessages enum is: > > public enum LogMessages { > > @Error("error message {}") // The log level is bound to Error. > TEST0001, > > @Message("waring message {}") // The log level is not specified. > TEST0002 > > } > > a. why would you want to allow a log level to not be specified? (See > item 4 above). It is now possible to not specify the level in the > properties file and not specify it as an annotation. If that happens > then the level will be info since that is what is hardcoded in > I18NLoggerFactory. What is more annoying is that I can call logger.warn > and generate an info level message. > b. Other than showing that you know how to use annotations I don't see > what the benefit is over doing something like: > > public enum LogMessages { > private final LogLevel level; > private final String message; > > public LogMessages(LogLevel lvl, String msg) { > level = lvl; > message = msg; > } > > public LogLevel getLogLevel() { return level }; > public String getMessage() { return message }; > > TEST0001(LogLevel.ERROR, "error message {}"); > TEST0002(LogLevel.WARN, "warning message {}"}; > > } > > I only spent about an hour looking at this so this may not be the > complete set of issues I might find. > > In short, this implementation is not very general purpose as it only > supports a single use case. > > Ralph > > > > On Aug 22, 2009, at 10:32 PM, Takeshi Kondo wrote: > >> >> >> I've developed initial thought of SLF4j's i18n extension. >> It was committed to my branch >> (http://github.com/takeshi/slf4j/tree/master). >> >> I've implemented 4 features as follows. >> >> 1. Logger interface using enum. >> @see org.slf4j.i18n.I18NLogger >> >> 2. Extension point to bind log id's enum to log message and level. >> @see org.slf4j.i18n.spi.LogLevelResolver >> @see org.slf4j.i18n.spi.LogMessageFormatResolver >> >> 3. Resolving log message and log level from Annotation associated from >> log id's enum. >> @see org.slf4j.i18n.impl.AnnotationLogLevelResolver >> @see org.slf4j.i18n.impl.AnnotationMessageFormatResolver >> >> 4. Resolving log message and log level from ResourceBundle associated >> with log id's enum. >> @see org.slf4j.i18n.impl.ResourceBundleLogLevelResolver >> @see org.slf4j.i18n.impl.ResourceBundleMessageFormatResolver >> >> >> For example: >> ---- >> Log Message Definition >> ---- >> public enum LogMessages { >> >> @Error("error message {}") // log level is bound to Error. >> TEST0001, >> >> @Message("waring message {}") // log level is not specified. >> TEST0002 >> >> } >> >> ---- >> Logging >> ---- >> >> public static void main(String[] args) { >> I18NLogger logger = I18NLoggerFactory.getLogger(LogMain.class); >> >> // write to error log , because LogMessages.TEST0001 is bound to >> Error level. >> logger.log(LogMessages.TEST0001, "xxxx"); >> logger.log(LogMessages.TEST0001, new NullPointerException()); >> >> // write log as error level. >> logger.error(LogMessages.TEST0002, "xxxx"); >> // write log as warn level. >> logger.warn(LogMessages.TEST0002, new NullPointerException()); >> } >> >> >> Takeshi Kondo >> >> _ >> dev mailing list >> dev at slf4j.org >> http://www.slf4j.org/mailman/listinfo/dev > > _ > dev mailing list > dev at slf4j.org > http://www.slf4j.org/mailman/listinfo/dev > -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From takeshi.kondo at gmail.com Mon Aug 24 19:02:52 2009 From: takeshi.kondo at gmail.com (Takeshi Kondo) Date: Tue, 25 Aug 2009 02:02:52 +0900 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> Message-ID: <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> Hello Ceki, I acknowledge that my first commit source code is not a finished product. It is draft. My job is together with WebBeans. My submission is one of resolutions that I have troubles using Seam. I want to finish off it as soon as possible. Please tell me reason that you can't understand it. I will all execute what I can do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Mon Aug 24 19:23:12 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Mon, 24 Aug 2009 19:23:12 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> Message-ID: <4A92CC80.4050204@qos.ch> Hi Takeshi, Thank you for your response. I have looked at your code again and now understand how levels can be set in resource bundles. Having said that, I am not convinced that associating levels to keys in resource bundles is a good idea because there are other possibly better ways of obtaining the same effect. This does not mean the idea is bad, it's just that it is not overwhelmingly convincing. Contrast this with your initial idea about linking message codes (aka messages keys or message codes) in enums with those found in resource bundles. Convinced that it has potential, I started a new project called cai18n to explore exactly this venue. See http://cai18n.qos.ch/ for details. You can get the code from http://github.com/ceki/cai18n/tree/master There is a lot to do in cai18n and everyone is welcome to participate. Takeshi Kondo wrote: > Hello Ceki, > > I acknowledge that my first commit source code is not a finished product. > It is draft. > > My job is together with WebBeans. My submission is one of resolutions > that I have troubles using Seam. > I want to finish off it as soon as possible. > > Please tell me reason that you can't understand it. > I will all execute what I can do. > -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From takeshi.kondo at gmail.com Mon Aug 24 20:05:52 2009 From: takeshi.kondo at gmail.com (Takeshi Kondo) Date: Tue, 25 Aug 2009 03:05:52 +0900 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> Message-ID: Hello Ceki Thanks for your response. Could you tell me reason you am not convinced? I don't understand that you have other possibly better ways of obtaining the change log level. From ceki at qos.ch Mon Aug 24 20:27:45 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Mon, 24 Aug 2009 20:27:45 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> Message-ID: <4A92DBA1.8050800@qos.ch> Takeshi Kondo wrote: > Hello Ceki > > Thanks for your response. > > Could you tell me reason you am not convinced? By not convinced, I mean that I am not persuaded by your approach but I am also not dismissing it. > I don't understand that you have other possibly better ways of > obtaining the change log level. You can use filters to create rules of action. Such filters can scan for message codes and when a particular message code is detected, the filter can modify the level associated with a logging statement. So, when you write logger.warn("The earth is warming up"); the filter can reduce the logging level to DEBUG instead of WARN on the fly. Filters can be defined in a configuration file which can be loaded and reloaded at will. So, filters are another way of changing the logging level at runtime. I hope this sheds some light on the matter. -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From takeshi.kondo at gmail.com Mon Aug 24 21:36:51 2009 From: takeshi.kondo at gmail.com (Takeshi Kondo) Date: Tue, 25 Aug 2009 04:36:51 +0900 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> Message-ID: <40954403-DA76-43CD-8111-62A054F30963@gmail.com> Hi Ceki I know filters. I'm heavy log4j user. In other times I discussed on Makers, I want to change log level to info from debug to analyze system crash. Your approach is event filtering and can't move up the log level. And if it is no need of log event, it is better to filter log event as soon as possible. The first filtering point is the point evaluating log level. I don't understand you don't introduce changing log event. Are there are another way of changing the logging level? Takeshi Kondo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Mon Aug 24 21:56:38 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Mon, 24 Aug 2009 21:56:38 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <40954403-DA76-43CD-8111-62A054F30963@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> <40954403-DA76-43CD-8111-62A054F30963@gmail.com> Message-ID: <4A92F076.9030205@qos.ch> Takeshi Kondo wrote: > Hi Ceki > > I know filters. I'm heavy log4j user. There are logging frameworks other than log4j. :-) > In other times I discussed on Makers, > I want to change log level to info from debug to analyze system crash. > Your approach is event filtering and can't move up the log level. The fact that it can't be done in log4j does not mean that it can't be done. > And if it is no need of log event, it is better to filter log event as > soon as possible. That really depends. As far as performance is concerned, the importance part is to perform internationalization only after the change of log level. > The first filtering point is the point evaluating log level. We could have different filtering points. > I don't understand you don't introduce changing log event. Because different alternatives need to be considered. Again, I am not dismissing you proposal. > Are there are another way of changing the logging level? See above and my previous message. > Takeshi Kondo -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From takeshi.kondo at gmail.com Mon Aug 24 22:15:43 2009 From: takeshi.kondo at gmail.com (Takeshi Kondo) Date: Tue, 25 Aug 2009 05:15:43 +0900 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <40954403-DA76-43CD-8111-62A054F30963@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> <40954403-DA76-43CD-8111-62A054F30963@gmail.com> Message-ID: <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> Hi Ceki > The fact that it can't be done in log4j does not mean that it can't > be done. Is it mean that it can be done in logback? If it is, I'll change logger to logback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceki at qos.ch Mon Aug 24 22:25:09 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Mon, 24 Aug 2009 22:25:09 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> <40954403-DA76-43CD-8111-62A054F30963@gmail.com> <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> Message-ID: <4A92F725.5010204@qos.ch> Takeshi Kondo wrote: > Hi Ceki > > >> The fact that it can't be done in log4j does not mean that it can't be >> done. > > Is it mean that it can be done in logback? > > If it is, I'll change logger to logback. To be honest, at present time it can't be done in logback either. However, logback already has support for TurboFilters [1] which can already do arbitrary filtering. We'd need to enhance turbo filters so that they influence the contents of the logging event. My point is that the hook is already there, it needs to be enhanced. -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From rgoers at apache.org Mon Aug 24 22:33:23 2009 From: rgoers at apache.org (Ralph Goers) Date: Mon, 24 Aug 2009 13:33:23 -0700 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <4A92F725.5010204@qos.ch> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> <40954403-DA76-43CD-8111-62A054F30963@gmail.com> <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> <4A92F725.5010204@qos.ch> Message-ID: <2B7CF7AA-EBA9-4E32-BA30-0573EDDCE2F2@apache.org> On Aug 24, 2009, at 1:25 PM, Ceki Gulcu wrote: > > > Takeshi Kondo wrote: >> Hi Ceki >>> The fact that it can't be done in log4j does not mean that it >>> can't be done. >> Is it mean that it can be done in logback? >> If it is, I'll change logger to logback. > > To be honest, at present time it can't be done in logback either. > However, logback already has support for TurboFilters [1] which can > already do arbitrary filtering. We'd need to enhance turbo filters > so that they influence the contents of the logging event. My point > is that the hook is already there, it needs to be enhanced. > What would need to be enhanced? Turbo Filters have access to the event and as far as I recall the event is not immutable. However, this becomes highly dependent on filters being run in the correct order. Ralph From takeshi.kondo at gmail.com Mon Aug 24 23:02:37 2009 From: takeshi.kondo at gmail.com (Takeshi Kondo) Date: Tue, 25 Aug 2009 06:02:37 +0900 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> <40954403-DA76-43CD-8111-62A054F30963@gmail.com> <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> Message-ID: > > The fact that it can't be done in log4j does not mean that it can't > be done. > Is it mean that it can be done in logback? > > If it is, I'll change logger to logback. > To be honest, at present time it can't be done in logback either. > However, logback already has support for TurboFilters [1] which can > already do arbitrary filtering. We'd need to enhance turbo filters > so that they influence the contents of the logging event. My point > is that the hook is already there, it needs to be enhanced Thanks. I'm not wise about logging. I hope in your new project. I want you to resolve my concern in your new project. You will familiarize my idea than me. I've come up with it before two years. But I can't. It is interesting for me to discuss about logging with giant of logging. Thanks. Tkaeshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From git-noreply at pixie.qos.ch Mon Aug 24 23:51:55 2009 From: git-noreply at pixie.qos.ch (added by portage for gitosis-gentoo) Date: Mon, 24 Aug 2009 23:51:55 +0200 (CEST) Subject: [slf4j-dev] [GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. 1e3aadf8d8442882429ef5df53e0af455157d2ca Message-ID: <20090824215155.AF4B62F8DFA@pixie.qos.ch> 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 1e3aadf8d8442882429ef5df53e0af455157d2ca (commit) from a3c95b1a1d4bfc06442919e5a0108333738f5bbe (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=1e3aadf8d8442882429ef5df53e0af455157d2ca http://github.com/ceki/slf4j/commit/1e3aadf8d8442882429ef5df53e0af455157d2ca commit 1e3aadf8d8442882429ef5df53e0af455157d2ca Author: Ceki Gulcu Date: Mon Aug 24 23:46:55 2009 +0200 - Clarified the title in license.html. Previously the title said "SLF4J License" and some people thought that there was an SLF4J license instead of the actual MIT license - modified pom.xml to include licensing info Solves http://bugzilla.slf4j.org/show_bug.cgi?id=143 diff --git a/pom.xml b/pom.xml index 85c2b24..2a81ab7 100644 --- a/pom.xml +++ b/pom.xml @@ -18,6 +18,14 @@ 2005 + + + MIT License + http://www.opensource.org/licenses/mit-license.php + repo + + + diff --git a/slf4j-site/src/site/pages/license.html b/slf4j-site/src/site/pages/license.html index bde22a3..d482300 100644 --- a/slf4j-site/src/site/pages/license.html +++ b/slf4j-site/src/site/pages/license.html @@ -17,10 +17,10 @@
-
SLF4J License
+
Licensing terms for SLF4J

SLF4J source code and binaries are distributed under the - following license. + MIT license.

----------------------------------------------------------------------- Summary of changes: pom.xml | 8 ++++++++ slf4j-site/src/site/pages/license.html | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java From bugzilla-daemon at pixie.qos.ch Mon Aug 24 23:52:56 2009 From: bugzilla-daemon at pixie.qos.ch (bugzilla-daemon at pixie.qos.ch) Date: Mon, 24 Aug 2009 23:52:56 +0200 (CEST) Subject: [slf4j-dev] [Bug 143] Include licensing information in pom.xml In-Reply-To: Message-ID: <20090824215256.742642F8E0D@pixie.qos.ch> http://bugzilla.slf4j.org/show_bug.cgi?id=143 Ceki Gulcu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Ceki Gulcu 2009-08-24 23:52:55 --- Fixed commit 1e3aadf8d8442... See also http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=1e3aadf8d84428824 -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From ceki at qos.ch Tue Aug 25 10:32:29 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Tue, 25 Aug 2009 10:32:29 +0200 Subject: [slf4j-dev] slf4j i8ln In-Reply-To: <2B7CF7AA-EBA9-4E32-BA30-0573EDDCE2F2@apache.org> References: <9BBBFA08-1465-42AC-82C1-28A65BDE4C8E@redhat.com> <4A8C41E9.6030908@qos.ch> <4D836248-FEC3-4278-BDCF-D8EBE1F212B5@gmail.com> <6AF0A254-D29E-436C-9C6A-3579A32E0217@gmail.com> <42E1FC4F-DC3C-4355-84F7-8065AC14B893@gmail.com> <40954403-DA76-43CD-8111-62A054F30963@gmail.com> <09B6907C-A19B-47AD-B21B-0820FBCCEBCC@gmail.com> <4A92F725.5010204@qos.ch> <2B7CF7AA-EBA9-4E32-BA30-0573EDDCE2F2@apache.org> Message-ID: <4A93A19D.6000207@qos.ch> Ralph Goers wrote: > > On Aug 24, 2009, at 1:25 PM, Ceki Gulcu wrote: > >> >> >> Takeshi Kondo wrote: >>> Hi Ceki >>>> The fact that it can't be done in log4j does not mean that it can't >>>> be done. >>> Is it mean that it can be done in logback? >>> If it is, I'll change logger to logback. >> >> To be honest, at present time it can't be done in logback either. >> However, logback already has support for TurboFilters [1] which can >> already do arbitrary filtering. We'd need to enhance turbo filters so >> that they influence the contents of the logging event. My point is >> that the hook is already there, it needs to be enhanced. >> > > > What would need to be enhanced? Turbo Filters have access to the event > and as far as I recall the event is not immutable. However, this becomes > highly dependent on filters being run in the correct order. At the time a turbo filter is called there is no event yet. The event is created after all the turbo filters are called (assuming none denied the request). As for immutability, most fields in a LoggingEvent are immutable. Yes, the down side of having many filters is that they depend on their order of execution. The same principle applies in networking which explains why network filters are so damn fragile. > Ralph -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From ceki at qos.ch Fri Aug 28 15:04:37 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Fri, 28 Aug 2009 15:04:37 +0200 Subject: [slf4j-dev] Announcing CAI18N version 0.2 Message-ID: <4A97D5E5.4050707@qos.ch> 28th of August 2009 - Release of CAI18N version 0.2 I am happy to announce the immediate availability of CAI18N version 0.2. Compiler Assisted Internationalization, abbreviated as CAI18N, is a java library for writing internationalized messages. CAI18N is spawn of SLF4J. The two-page manual should give you an idea of what CAI18N is all about. http://cai18n.qos.ch/manual.html You comments on the cai18n-user or cai18n-dev lists are most welcome, -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch From rgoers at apache.org Fri Aug 28 21:25:00 2009 From: rgoers at apache.org (Ralph Goers) Date: Fri, 28 Aug 2009 12:25:00 -0700 Subject: [slf4j-dev] Announcing CAI18N version 0.2 In-Reply-To: <4A97D5E5.4050707@qos.ch> References: <4A97D5E5.4050707@qos.ch> Message-ID: The JDK version in the compiler plugin needs to be set to 1.6. I'm getting a compile error in MessageIdVerifier. The default JVM on my machine is 1.5. I guess you don't have a mailing list yet for the project. Ralph On Aug 28, 2009, at 6:04 AM, Ceki Gulcu wrote: > 28th of August 2009 - Release of CAI18N version 0.2 > > I am happy to announce the immediate availability of CAI18N version > 0.2. Compiler Assisted Internationalization, abbreviated as CAI18N, is > a java library for writing internationalized messages. CAI18N is spawn > of SLF4J. > > The two-page manual should give you an idea of what CAI18N is all > about. > > http://cai18n.qos.ch/manual.html > > You comments on the cai18n-user or cai18n-dev lists are most welcome, > > -- > Ceki G?lc? > Logback: The reliable, generic, fast and flexible logging framework > for Java. > http://logback.qos.ch > _______________________________________________ > dev mailing list > dev at slf4j.org > http://www.slf4j.org/mailman/listinfo/dev From ceki at qos.ch Mon Aug 31 21:03:11 2009 From: ceki at qos.ch (Ceki Gulcu) Date: Mon, 31 Aug 2009 21:03:11 +0200 Subject: [slf4j-dev] Announcing CAI18N version 0.2 In-Reply-To: References: <4A97D5E5.4050707@qos.ch> Message-ID: <4A9C1E6F.6000300@qos.ch> Hi Ralph, Thanks for the info. It's not the version of the compiler output but the reference to a method introduced in JDK 1.6. The problem was fixed in the latest release. By the way, the project name has been changed to CAL10N, pronounced calin instead of cai18n which was hard to pronounce, although "Kalaitinnen" was suggested by Bertrand Delacretaz. Just to repeat, the new project is now called CAL10N ( http://cal10n.qos.ch/ ) and it does have announce, user and dev mailing lists. Cheers, Ralph Goers wrote: > The JDK version in the compiler plugin needs to be set to 1.6. I'm > getting a compile error in MessageIdVerifier. The default JVM on my > machine is 1.5. I guess you don't have a mailing list yet for the project. > > Ralph > > On Aug 28, 2009, at 6:04 AM, Ceki Gulcu wrote: > >> 28th of August 2009 - Release of CAI18N version 0.2 >> >> I am happy to announce the immediate availability of CAI18N version >> 0.2. Compiler Assisted Internationalization, abbreviated as CAI18N, is >> a java library for writing internationalized messages. CAI18N is spawn >> of SLF4J. >> >> The two-page manual should give you an idea of what CAI18N is all >> about. >> >> http://cai18n.qos.ch/manual.html >> >> You comments on the cai18n-user or cai18n-dev lists are most welcome, -- Ceki G?lc? Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch