- slf4j-dev - mailman3.qos.ch

[GIT] SLF4J: Simple Logging Facade for Java branch master updated. v_1.6.4-16-g19579f1
by git-noreply＠pixie.qos.ch 22 May '12

22 May '12

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 19579f1ba914e95f6aa1b7415cc73792f8e75134 (commit) from f5b19567277a62ed7595b1bc72ea98ca90a7f6dc (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=19579f1ba914e95f6aa1b7415c… http://github.com/ceki/slf4j/commit/19579f1ba914e95f6aa1b7415cc73792f8e75134 commit 19579f1ba914e95f6aa1b7415cc73792f8e75134 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue May 22 22:54:50 2012 +0200 capitalize Migrator as it's a name diff --git a/slf4j-site/src/site/pages/docs.html b/slf4j-site/src/site/pages/docs.html index c077b47..2fa7abd 100644 --- a/slf4j-site/src/site/pages/docs.html +++ b/slf4j-site/src/site/pages/docs.html @@ -27,7 +27,7 @@ <li><a href="faq.html">FAQ</a></li> <li><a href="codes.html">SLF4J error messages</a></li> <li><a href="legacy.html">Bridging legacy APIs</a></li> - <li><a href="migrator.html">SLF4J migrator</a></li> + <li><a href="migrator.html">SLF4J Migrator</a></li> <li><a href="extensions.html">SLF4J extensions</a></li> <li><a href="localization.html">Localization/Internalization support</a></li> ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/docs.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[GIT] SLF4J: Simple Logging Facade for Java branch master updated. v_1.6.4-15-gf5b1956
by git-noreply＠pixie.qos.ch 22 May '12

22 May '12

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 f5b19567277a62ed7595b1bc72ea98ca90a7f6dc (commit) from e0985457677dcc7e2db3d14d37a512e4cb483b47 (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=f5b19567277a62ed7595b1bc72… http://github.com/ceki/slf4j/commit/f5b19567277a62ed7595b1bc72ea98ca90a7f6dc commit f5b19567277a62ed7595b1bc72ea98ca90a7f6dc Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue May 22 22:48:38 2012 +0200 applied corrections provided by Stuart Davey diff --git a/slf4j-site/src/site/pages/manual.html b/slf4j-site/src/site/pages/manual.html index 4b70707..df7aba4 100644 --- a/slf4j-site/src/site/pages/manual.html +++ b/slf4j-site/src/site/pages/manual.html @@ -184,9 +184,9 @@ SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further detail SLF4J does not rely on any special class loader machinery. In - fact, the each SLF4J binding is hardwired at compile - time to use one and only one specific logging framework. - For example, the slf4j-log4j12-${project.version}.jar binding is + fact, each SLF4J binding is hardwired at compile time + to use one and only one specific logging framework. For + example, the slf4j-log4j12-${project.version}.jar binding is bound at compile time to use log4j. In your code, in addition to slf4j-api-${project.version}.jar, you simply drop one and only one binding of your choice onto the diff --git a/slf4j-site/src/site/pages/migrator.html b/slf4j-site/src/site/pages/migrator.html index e983d00..3d31b11 100644 --- a/slf4j-site/src/site/pages/migrator.html +++ b/slf4j-site/src/site/pages/migrator.html @@ -39,11 +39,11 @@ <img src="images/slf4j-migrator.gif" alt="slf4j-migrator.gif"/> - Use the application should be self-explanatory. Please note that + Use of the application should be self-explanatory. Please note that this migration tool does in-place replacement of Java files, meaning that there will be no back-up copies of modified files. It is your responsibility to backup your files before using SLF4J - migrator. + Migrator. ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/manual.html | 6 +++--- slf4j-site/src/site/pages/migrator.html | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[Bug 257] Recommended Logger Name
by bugzilla-daemon＠qos.ch 10 May '12

10 May '12

http://bugzilla.slf4j.org/show_bug.cgi?id=257 Ralph Goers <rgoers(a)apache.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rgoers(a)apache.org --- Comment #6 from Ralph Goers <rgoers(a)apache.org> 2012-05-10 08:02:51 CEST --- Here is another perspective. Logger names are primarily used to choose the configuration that will apply to the specific events being logged. While class names are one good way of doing that there is absolutely nothing wrong with using some other scheme as long as it meets your requirements on filtering, appender selection and ultimately publishing the events. That said, as was noted logger names are hierarchical. Names like Billing, Billing.Automatic and Billing.Recurrent only make sense if that hierarchy meets your requirements. Providing a patch with examples is probably the best way for you to get this issue resolved. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 257] Recommended Logger Name
by bugzilla-daemon＠qos.ch 09 May '12

09 May '12

http://bugzilla.slf4j.org/show_bug.cgi?id=257 --- Comment #5 from Irv Rabin <ipr1118(a)gmail.com> 2012-05-09 23:08:03 CEST --- Joachim, thanks for your response. Your voice has been heard. :) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 257] Recommended Logger Name
by bugzilla-daemon＠qos.ch 09 May '12

09 May '12

http://bugzilla.slf4j.org/show_bug.cgi?id=257 --- Comment #4 from Joachim Durchholz <jo(a)durchholz.org> 2012-05-09 22:19:28 CEST --- While an aircraft carrier is quite different from a motorboat, you still don't use aluminium for the wiring. Argument by analogy doesn't fly, you always need to justify why your analogy holds and why the other doesn't - IOW you need to argue substance anyway and the analogy doesn't help a bit. Why using logger names is a bad idea: - You say you need to identify the product in the log message. Then you say you need to identify the business entity. You're trying to stuff quite a lot of very different things into the same name here. Plus, there's always a lot of code that doesn't quite fit the classification of "product" or "business entity". - Logger names are hierarchical for a reason: they eliminate the need to reconfigure logging for different modules, you can factor out configuration from submodules into supermodules. You lose that if you switch to a flat "product" namespace. - Identifying the business entity often isn't enough, you also need the ID (customer ID etc.). You can't put dynamic data into the logger name, so that use case isn't covered by your approach. - Any third-party software that you use will have hardcoded classnames in its loggers. You'll get a hodgepodge of class names and product names in your logs. Why not put product/whatever names into the log message text? You can always create your own logging framework. A thin layer above Logger that has warn(String moduleName, String message, Object... params) that does warn(moduleName + ": " + message, params). (There are ways to optimize that.) BTW I *have* scoured log messages. Knowing the class name is helpful. I'm also seeing people blog about moving from non-classname logger names back to classname-based ones, but not the other way round. Have mercy on your developers. There are better ways to achieve what you want. 'nuff said. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 257] Recommended Logger Name
by bugzilla-daemon＠qos.ch 09 May '12

09 May '12

http://bugzilla.slf4j.org/show_bug.cgi?id=257 Ceki Gulcu <listid(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |listid(a)qos.ch --- Comment #3 from Ceki Gulcu <listid(a)qos.ch> 2012-05-09 20:58:50 CEST --- Patches for the docs are welcome. You might also want to look at markers to organize log statements. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 257] Recommended Logger Name
by bugzilla-daemon＠qos.ch 09 May '12

09 May '12

http://bugzilla.slf4j.org/show_bug.cgi?id=257 --- Comment #2 from Irv Rabin <ipr1118(a)gmail.com> 2012-05-09 20:47:43 CEST --- Thanks Joachim, I expected a response like that. :) Well, logging is not only "to collect information to help developers fix the problem". That is debugging. Only logging messages with level DEBUG fit into your definition. Well, perhaps TRACE to a certain degree. Logging is to collect data about a running process so the latter can be analyzed later. For example, a big commercial billing application may want to have a log where the whole billing process can be traced and reconstructed. The application may have thousand of classes. Messages relevant to one billing cycle that logically belong to the same logger could be produced by any of the classes comprising the application. The logger could be defined for a whole subsystem (such as Billing). Then, as the application can be divided into subcomponents, the logging could be distributed into subloggers (Billing.Notification, Billing.Payment, etc), so the dots would still show hierarchy and configuration with inheritance of settings could be honored. But whenever the system is composed of tens of thousands of classes, using class names as logger name is simply insane. Like a motorboat driver has a very vague idea how to drive an aircraft carrier ship, in the same way recommendations that are sound for small Proof-Of-Concept projects, are inapplicable to big commercial applications. That's why I believe that recommendation of using class names as logger names should be limited to small pilot projects, where the developer is the primary user of his own code. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 257] Recommended Logger Name
by bugzilla-daemon＠qos.ch 09 May '12

09 May '12

http://bugzilla.slf4j.org/show_bug.cgi?id=257 Joachim Durchholz <jo(a)durchholz.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jo(a)durchholz.org --- Comment #1 from Joachim Durchholz <jo(a)durchholz.org> 2012-05-09 19:49:59 CEST --- I know I'm late with this, but here goes: Irv, your developers are right and you got it backwards. Logging is for collecting internal information that helps developers fix problems. Class names are just right for that purpose. Also, the logger name is used to identify logging configuration, e.g. what severity of logging levels to use for what parts of the logger namespace. You'll always have dots in the logger names (or you'll have to configure every single logger in the system manually). Third, you can't change the logger names of third-party software you're using. You should include the business entity in the log message. (That's something I do as a matter of course.) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Add a logging.properties to jul-to-slf4j?
by Robert Elliot 08 May '12

08 May '12

Hi all, Whenever I create an app where I want to redirect java.util.logging to SLF4J I have to remember to do two things - add jul-to-slf4j to the class path and add a logging.properties file with the following format: handlers = org.slf4j.bridge.SLF4JBridgeHandler to the class path. It suddenly occurred to me that it might be simpler just to have that logging.properties file in jul-to-slf4j. Then it would be job done in one go. Presumably if you;re including jul-to-slf4j on the class path then you don't want to configure any other logging… Any thoughts? Rob

2 3

[GIT] SLF4J: Simple Logging Facade for Java branch master updated. v_1.6.4-14-ge098545
by git-noreply＠pixie.qos.ch 08 May '12

08 May '12

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 e0985457677dcc7e2db3d14d37a512e4cb483b47 (commit) from d8b43cb95f870840c8068efc4ccdb3487aebd41e (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=e0985457677dcc7e2db3d14d37… http://github.com/ceki/slf4j/commit/e0985457677dcc7e2db3d14d37a512e4cb483b47 commit e0985457677dcc7e2db3d14d37a512e4cb483b47 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue May 8 19:01:06 2012 +0200 indentation changes diff --git a/jcl-over-slf4j/pom.xml b/jcl-over-slf4j/pom.xml index 5ac9863..c223656 100644 --- a/jcl-over-slf4j/pom.xml +++ b/jcl-over-slf4j/pom.xml @@ -1,19 +1,20 @@ -<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> +<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> - <parent> - <groupId>org.slf4j</groupId> - <artifactId>slf4j-parent</artifactId> + <parent> + <groupId>org.slf4j</groupId> + <artifactId>slf4j-parent</artifactId> <version>1.6.5-SNAPSHOT</version> - </parent> - - <modelVersion>4.0.0</modelVersion> + </parent> - <groupId>org.slf4j</groupId> - <artifactId>jcl-over-slf4j</artifactId> - <packaging>jar</packaging> - <name>JCL 1.1.1 implemented over SLF4J</name> + <modelVersion>4.0.0</modelVersion> + + <groupId>org.slf4j</groupId> + <artifactId>jcl-over-slf4j</artifactId> + <packaging>jar</packaging> + <name>JCL 1.1.1 implemented over SLF4J</name> <description>JCL 1.1.1 implemented over SLF4J</description> - <url>http://www.slf4j.org</url> + <url>http://www.slf4j.org</url> <dependencies> @@ -36,11 +37,11 @@ <artifactId>slf4j-jdk14</artifactId> <scope>test</scope> </dependency> - + </dependencies> <build> - <plugins> + <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> @@ -53,7 +54,7 @@ </manifestEntries> <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile> </archive> - </configuration> + </configuration> </plugin> </plugins> </build> ----------------------------------------------------------------------- Summary of changes: jcl-over-slf4j/pom.xml | 31 ++++++++++++++++--------------- 1 files changed, 16 insertions(+), 15 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0