- slf4j-dev - mailman3.qos.ch

[Bug 223] New: Race-conditions initializing LoggerFactory
by bugzilla-daemon＠pixie.qos.ch 19 Jun '11

19 Jun '11

http://bugzilla.slf4j.org/show_bug.cgi?id=223 Summary: Race-conditions initializing LoggerFactory Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: critical Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: cowwoc(a)bbs.darktech.org 1. Given: public class MyTest { private final Logger log = LoggerFactory.getLogger(MyTest.class); @Test public void firstMethod() {...} @Test public void secondMethod() {...} //etc } 2. Run the unit test through Surefire 2.8.1 or newer (I am using 2.8.2-SNAPSHOT) with <parallel>methods</parallel> and JUnit 4.8.2 3. slf4j will issue the following warning: SLF4J: The following loggers will not work because they were created SLF4J: during the default configuration phase of the underlying logging system. SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger 4. MyTest is instantiated multiple times simultaneously, each time invoking LoggerFactory.getLogger(). 5. The first call begins invoking performInitialization(). The subsequent calls return TEMP_FACTORY. As a result, the unit tests run with a misconfigured logger. Expected behavior: The first thread should run performInitialization() while subsequent threads block waiting for initialization to complete. I believe you can do this (and still allow re-entrant behavior) by using a "synchronized (LoggerFactory.class)" block. Workaround: Insert the following method once per class file: @BeforeClass public static void initSlf4j() { // Configure slf4j in a thread-safe manner, otherwise we get: // // SLF4J: The following loggers will not work because they were created // SLF4J: during the default configuration phase of the underlying logging system. // SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger LoggerFactory.getILoggerFactory(); } Though I don't think this workaround will work for <parallel>class</parallel> or <parallel>both</parallel>. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.1-34-gd9e7175
by git-noreply＠pixie.qos.ch 16 Jun '11

16 Jun '11

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 d9e7175fb77832e2366a5755995bb14399f015fa (commit) via d380a0953e126827e9efbbb501a7352b17bb21f2 (commit) from ebf05781718598adebd1e8fc058f459891002682 (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=d9e7175fb77832e2366a575599… http://github.com/ceki/slf4j/commit/d9e7175fb77832e2366a5755995bb14399f015fa commit d9e7175fb77832e2366a5755995bb14399f015fa Merge: d380a09 ebf0578 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jun 16 11:22:26 2011 +0200 Merge branch 'master' of git.qos.ch:slf4j http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=d380a0953e126827e9efbbb501… http://github.com/ceki/slf4j/commit/d380a0953e126827e9efbbb501a7352b17bb21f2 commit d380a0953e126827e9efbbb501a7352b17bb21f2 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Jun 16 11:22:09 2011 +0200 precision regarding logback diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 155f4df..ecd5d48 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -194,12 +194,13 @@ <dd> In short, libraries and other embedded components should - consider SLF4J for their logging needs because libraries - cannot afford to impose their choice of logging system on the - end-user. On the other hand, it does not necessarily make - sense for stand-alone applications to use SLF4J. Stand-alone - applications can invoke the logging system of their choice - directly. + consider SLF4J for their logging needs because libraries cannot + afford to impose their choice of logging framework on the + end-user. On the other hand, it does not necessarily make sense + for stand-alone applications to use SLF4J. Stand-alone + applications can invoke the logging framework of their choice + directly. In the case of logback, the question is moot because + logback exposes its logger API via SLF4J. SLF4J is only a facade, meaning that it does not provide a ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/faq.html | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0

[Bug 222] New: java.lang.NoSuchFieldError: TRACE : its throwing error while loading the application
by bugzilla-daemon＠pixie.qos.ch 16 Jun '11

16 Jun '11

http://bugzilla.slf4j.org/show_bug.cgi?id=222 Summary: java.lang.NoSuchFieldError: TRACE : its throwing error while loading the application Product: SLF4J Version: 1.4.x Platform: Sun OS/Version: Solaris Status: NEW Severity: blocker Priority: P1 Component: Implementations AssignedTo: slf4j-dev(a)qos.ch ReportedBy: pnkrr(a)yahoo.com I am getting the following error. We have the following versions. Log4j-1.2.15.jar slf4j-log4j12-1.4.2.jar slf4j-api-1.4.2.jar **************************************************************** 2011-06-15 09:48:07,637 ERROR [WebContainer : 0] com.filenet.bp8.apps.server.servlet.Bp8ActionDispatcherServlet (handleError:55) - java.lang.NoSuchFieldError: TRACE at org.slf4j.impl.Log4jLoggerAdapter.log(Log4jLoggerAdapter.java:492) at org.apache.commons.logging.impl.SLF4JLocationAwareLog.trace(SLF4JLocationAwareLog.java:78) at org.springframework.core.CollectionFactory.createConcurrentMapIfPossible(CollectionFactory.java:195) at org.springframework.core.SimpleAliasRegistry.<init>(SimpleAliasRegistry.java:41) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.<init>(DefaultSingletonBeanRegistry.java:73) at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.<init>(FactoryBeanRegistrySupport.java:41) at org.springframework.beans.factory.support.AbstractBeanFactory.<init>(AbstractBeanFactory.java:146) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.<init>(AbstractAutowireCapableBeanFactory.java:144) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.<init>(AbstractAutowireCapableBeanFactory.java:155) at org.springframework.beans.factory.support.DefaultListableBeanFactory.<init>(DefaultListableBeanFactory.java:121) at org.springframework.context.support.AbstractRefreshableApplicationContext.createBeanFactory(AbstractRefreshableApplicationContext.java:176) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:121) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352) at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139) at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93) at com.ge.service.impl.ApprovalDelegationServiceImpl.init(ApprovalDelegationServiceImpl.java:47) at com.ge.service.impl.ApprovalDelegationServiceImpl.getDelegationService(ApprovalDelegationServiceImpl.java:52) at com.ge.service.impl.ApprovalDelegationServiceImpl.getAccessibleInboxes(ApprovalDelegationServiceImpl.java:85) at com.ge.api.impl.CustomQueueImpl.replaceMacro(CustomQueueImpl.java:26) at com.filenet.bp8.api.impl.Bp8QueueImpl.getQueueDepthSql(Bp8QueueImpl.java:214) at com.filenet.bp8.api.impl.Bp8ProcessDataStoreImpl.getWorkObjectCounts(Bp8ProcessDataStoreImpl.java:1895) at com.filenet.bp8.api.impl.Bp8CaseManagerImpl.getInbasketCaseCounts(Bp8CaseManagerImpl.java:4465) at com.filenet.bp8.apps.server.servlet.Bp8ActionDispatcherServlet.doAction(Bp8ActionDispatcherServlet.java:143) at com.filenet.bp8.apps.server.servlet.Bp8ActionDispatcherServlet.doPost(Bp8ActionDispatcherServlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1146) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1087) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145) at com.filenet.ae.toolkit.server.servlet.filter.PostprocessorFilter.doFilter(PostprocessorFilter.java:38) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130) at com.filenet.ae.toolkit.server.servlet.filter.ContainerBasedFilter.doFilter(ContainerBasedFilter.java:218) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130) at com.filenet.ae.toolkit.server.servlet.filter.PreprocessorFilter.doFilter(PreprocessorFilter.java:91) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130) at com.filenet.bp8.apps.server.filter.EncodingFilter.doFilter(EncodingFilter.java:31) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130) at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:848) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:691) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:588) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:525) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:764) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:133) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:556) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:606) at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:979) at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1064) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1497) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 7

new slf4j implementation
by Christian Trutz 10 Jun '11

10 Jun '11

Hello together, fyi: a new slf4j implementation: https://github.com/smilebase/org.slf4j.impl.mongo is born! It writes logging messages into a mongoDB ... Christian

1 0

[Bug 221] New: MessageFormatter.format() not returning String
by bugzilla-daemon＠pixie.qos.ch 01 Jun '11

01 Jun '11

http://bugzilla.slf4j.org/show_bug.cgi?id=221 Summary: MessageFormatter.format() not returning String Product: SLF4J Version: 1.6.x Platform: PC OS/Version: Windows NT Status: NEW Severity: major Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: lorant.pinter(a)gmail.com The MessageFormatter.format() method, according to its Javadoc, is supposed to return a String, but it doesn't. Instead it returns a FormattingTuple for some time. I have this piece of code: private void trace(String message, Object... args) { if (log.isTraceEnabled(MARKER)) { StringBuilder line = new StringBuilder(); line.append(Transaction.this); final int holdCount = lock.getHoldCount(); line.append("(lvl ").append(holdCount).append(")"); for (int i = 0; i < holdCount; i++) { line.append('\t'); } line.append(" - "); // **** Important bit here ***** line.append(MessageFormatter.format(message, args)); log.trace(MARKER, line.toString()); } } It used to work while MessageFormat.format() still returned a String before 1.6.0. Now it's printing something like this: TRACE 56|242|c2 Transaction[0](lvl 2) org.slf4j.helpers.FormattingTuple@74dc6ad7 Now, that's not very helpful. Please change the Javadoc to reflect that the returned value is not a string. Please consider adding a .toString() method to FormattingTuple as well. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 138] Class path contains multiple SLF4J bindings
by bugzilla-daemon＠pixie.qos.ch 26 May '11

26 May '11

http://bugzilla.slf4j.org/show_bug.cgi?id=138 josh(a)kivasystems.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josh(a)kivasystems.com --- Comment #21 from josh(a)kivasystems.com 2011-05-26 06:15:18 CEST --- We have exactly this problem, however we are not using Weblogic, we have a custom framework. In our case the problem appears to be because each of our project jar files list the same slf4j binder in their own manifest class path. Although the actual -classpath parameter we pass to the JVM lists the binder only once, each of our jars list the binder in their manifest. SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/path-to-app/lib/slf4j-log4j12-1.5.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/path-to-app/lib/slf4j-log4j12-1.5.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/path-to-app/lib/slf4j-log4j12-1.5.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. We are using Maven as our build system and it is creating the manifest automatically. I'm sure we could tweak the dependencies in our build system to work through this, but using a Set does seem like the semantically correct thing to do in this situation anyway. -- 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

[slf4j.scala] Massive use of by-name parameters dangerous?
by Ceki Gülcü 04 May '11

04 May '11

FYI, I recently sent this to the scala-user list: http://groups.google.com/group/scala-user/browse_thread/thread/04b0ad794d42… Cheers, -- Ceki

1 0

[GIT] SLF4J: Simple Logging Facade for Java branch, master, updated. v_1.6.1-32-gebf0578
by git-noreply＠pixie.qos.ch 28 Apr '11

28 Apr '11

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 ebf05781718598adebd1e8fc058f459891002682 (commit) from bdc80857eea22530e29222fd773e847c44e7ce3e (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=ebf05781718598adebd1e8fc05… http://github.com/ceki/slf4j/commit/ebf05781718598adebd1e8fc058f459891002682 commit ebf05781718598adebd1e8fc058f459891002682 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Apr 28 19:26:18 2011 +0200 version mismatch related editions diff --git a/slf4j-site/src/site/pages/codes.html b/slf4j-site/src/site/pages/codes.html index 3dd90a0..dbbefcf 100644 --- a/slf4j-site/src/site/pages/codes.html +++ b/slf4j-site/src/site/pages/codes.html @@ -88,7 +88,7 @@ <h3> <a name="StaticLoggerBinder" href="#StaticLoggerBinder"> - Failed to load class + Failedto load class <code>org.slf4j.impl.StaticLoggerBinder</code> </a> </h3> @@ -169,38 +169,33 @@ <h3><a name="version_mismatch" href="#version_mismatch">slf4j-api version does not match that of the binding</a></h3> - An slf4j binding designates an artifact such as + An SLF4J binding designates an artifact such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework, say, java.util.logging or log4j. - Mixing mixing different versions of slf4j-api and slf4j - bindings can cause problems. For example, if you are using + Mixing mixing different versions of slf4j-api.jar and + SLF4J binding can cause problems. For example, if you are using slf4j-api-${project.version}.jar, then you should also use slf4j-simple-${project.version}.jar, using slf4j-simple-1.5.5.jar - will not work. - - - Note that from the client's perspective all versions of - slf4j-api are compatible. Customer code compiled with a given - version of slf4j-api.jar will run perfectly fine with any - other version of slf4j-api.jar. You only need to verify - that the version of your binding matches that of the slf4j-api. - - - In general, you should make sure that the - slf4j-api version matches that of the slf4j binding. However, you - do not have to worry about the version of slf4j-api - customer code was compiled against. See also the <a - href="faq.html#compatibility">relevant FAQ entry</a>. + will not work. + + It should be noted that from the client's perspective all + versions of slf4j-api are compatible. Client code compiled with + slf4j-api-N.jar will run perfectly fine with + slf4j-api-M.jar for any N and M. You only need to ensure + that the version of your binding matches that of the + slf4j-api.jar. You do not have to worry about the version of + slf4j-api.jar used by a given dependendency in your project. You + can always use any version of slf4j-api.jar, and as long + as the version of slf4j-api.jar and its binding match, + you should be fine. At initialization time, if SLF4J suspects that there may be a - version mismatch problem, it will emit a warning about the - suspected mismatch. For the exact details of the version mismatch - detection mechanism, please refer to the <a - href="faq.html#version_checks">relevant entry</a> in the FAQ. + api vs. binding version mismatch problem, it will emit a warning + about the suspected mismatch. diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 155f4df..37f3b2b 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -359,27 +359,25 @@ <dd> From the clients perspective, the SLF4J API is backward - compatible between all versions. This means than you can upgrade + compatible for all versions. This means than you can upgrade from SLF4J version 1.0 to any later version without problems. Code compiled with slf4j-api-versionN.jar will work with slf4j-api-versionM.jar for any versionN and any versionM However, while the SLF4J API is very stable from the client's - perspective, SLF4J bindings such as slf4j-simple or - slf4j-log4j12 may require a specific version of slf4j-api. Mixing different versions of slf4j artifacts can - be problematic and is strongly discouraged. For - instance, if you are using slf4j-api-1.5.6.jar, then you should - also use slf4j-simple-1.5.6.jar, using slf4j-simple-1.4.2.jar - will not work. + perspective, SLF4J bindings, e.g. slf4j-simple.jar or + slf4j-log4j12.jar, may require a specific version of slf4j-api. + Mixing different versions of slf4j artifacts can be problematic + and is strongly discouraged. For instance, if you are using + slf4j-api-1.5.6.jar, then you should also use + slf4j-simple-1.5.6.jar, using slf4j-simple-1.4.2.jar will not + work. At initialization time, if SLF4J suspects that there may be a version mismatch problem, it emits a warning about the said - mismatch. For the exact details of the version mismatch - detection mechanism, please refer to the <a - href="#version_checks">relevant entry</a> in this FAQ. + mismatch. <hr /> diff --git a/slf4j-site/src/site/pages/index.html b/slf4j-site/src/site/pages/index.html index 99bc8de..7f9571d 100644 --- a/slf4j-site/src/site/pages/index.html +++ b/slf4j-site/src/site/pages/index.html @@ -29,20 +29,26 @@ The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug - in the desired logging framework at deployment time. - + in the desired logging framework at deployment + time. Before you start using SLF4J, we highly recommend that you read the two-page <a href="manual.html">SLF4J user manual</a>. + Note that SLF4J-enabling your library implies the addition of + only a single mandatory dependency, namely slf4j-api.jar. + If no binding is found on the class path, then SLF4J will default to + a no-operation implementation. + + In case you wish to migrate your Java source files to SLF4J, consider our <a href="migrator.html">migrator tool</a> which can migrate your project into SLF4J in minutes. In case an externally-maintained component you depend on uses a logging API other than SLF4J, such as commons logging, log4j or - j.u.l, have a look at SLF4J's binary-support for <a + java.util.logging, have a look at SLF4J's binary-support for <a href="legacy.html">legacy APIs</a>. diff --git a/slf4j-site/src/site/pages/manual.html b/slf4j-site/src/site/pages/manual.html index cb1f9c8..7c48707 100644 --- a/slf4j-site/src/site/pages/manual.html +++ b/slf4j-site/src/site/pages/manual.html @@ -25,16 +25,21 @@ simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end-user to plug in the desired logging framework at deployment time. + Note that SLF4J-enabling your library/application implies the + addition of only a single mandatory dependency, namely + slf4j-api-${project.version}.jar. If no binding is found + on the class path, then SLF4J will default to a no-operation + implementation. <h3> <a name="hello_world" href="#hello_world">Hello World</a> </h3> - In accordance with programming tradition, here is an example + As customary in programming tradition, here is an example illustrating the simplest way to output "Hello world" using SLF4J. It begins by getting a logger with the name "HelloWorld". This - logger is in turn used to log the message "Hello World". + logger is in turn used to log the message "Hello World". <pre class="prettyprint source">import org.slf4j.Logger; @@ -49,16 +54,31 @@ public class HelloWorld { To run this example, you first need to <a href="download.html">download the slf4j distribution</a>, and - then to unpack it. Once that is done, add these two jar files to - your class path: + then to unpack it. Once that is done, add the file + slf4j-api-${project.version}.jar to your class path. + Compiling and running HelloWorld will result in the + following output being printed on the console. + +<pre>SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". +SLF4J: Defaulting to no-operation (NOP) logger implementation +SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.</pre> + + This warning is printed because no slf4j binding could be + found on your class path. + + The warning will disappear as soon as you add a binding to + your class path. Assuming you add + slf4j-simple-${project.version}.jar so that your class + path contains: + <ul> <li>slf4j-api-${project.version}.jar</li> <li>slf4j-simple-${project.version}.jar</li> </ul> - Compiling and running HelloWorld will result in the - following output being printed on the console. + Compiling and running HelloWorld will now result in + the following output on the console. <pre class="output">0 [main] INFO HelloWorld - Hello World</pre> @@ -225,7 +245,7 @@ public class HelloWorld { out-of-the-box, and without requiring the end-user to download a binding from SLF4J's web-site. Only when the end-user decides to enable logging will she need to install the SLF4J binding - corresponding to the logging framework chosen by the end-user. + corresponding to the logging framework chosen by her. <h3><a name="consolidate" href="#consolidate">Consolidate ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/codes.html | 39 ++++++++++++++------------------ slf4j-site/src/site/pages/faq.html | 20 +++++++--------- slf4j-site/src/site/pages/index.html | 12 +++++++-- slf4j-site/src/site/pages/manual.html | 34 ++++++++++++++++++++++------ 4 files changed, 62 insertions(+), 43 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.1-31-gbdc8085
by git-noreply＠pixie.qos.ch 27 Apr '11

27 Apr '11

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 bdc80857eea22530e29222fd773e847c44e7ce3e (commit) from ec16a083882a4cb9292dc23c9ba2a0f0e3f38964 (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=bdc80857eea22530e29222fd77… http://github.com/ceki/slf4j/commit/bdc80857eea22530e29222fd773e847c44e7ce3e commit bdc80857eea22530e29222fd773e847c44e7ce3e Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Apr 27 22:06:51 2011 +0200 removing the job link diff --git a/slf4j-site/src/site/pages/templates/header.js b/slf4j-site/src/site/pages/templates/header.js index ccc7043..35f75bc 100644 --- a/slf4j-site/src/site/pages/templates/header.js +++ b/slf4j-site/src/site/pages/templates/header.js @@ -4,9 +4,9 @@ document.write('<td><a href="http://www.slf4j.org/">'); document.write('<img src="' + prefix + 'images/logos/slf4j-logo.jpg" alt="" border="0"/>'); document.write('</a></td>') -document.write('<td align="right"><a id="job" href="http://logback.qos.ch/job.html">'); -document.write('<img src="' + prefix + 'images/myjob.png" alt="" border="0"/>'); -document.write('</a></td>') +//document.write('<td align="right"><a id="job" href="http://logback.qos.ch/job.html">'); +//document.write('<img src="' + prefix + 'images/myjob.png" alt="" border="0"/>'); +//document.write('</a></td>') document.write('</tr></table>'); document.write('<div id="breadcrumbs"></div>'); \ No newline at end of file ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/templates/header.js | 6 +++--- 1 files changed, 3 insertions(+), 3 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.1-30-gec16a08
by git-noreply＠pixie.qos.ch 19 Apr '11

19 Apr '11

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 ec16a083882a4cb9292dc23c9ba2a0f0e3f38964 (commit) via 762444cae9cc6a7746daba87234bf1a15f93c294 (commit) from fe7ac5d560f8ff4577e0627505e347de793b03e8 (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=ec16a083882a4cb9292dc23c9b… http://github.com/ceki/slf4j/commit/ec16a083882a4cb9292dc23c9ba2a0f0e3f38964 commit ec16a083882a4cb9292dc23c9ba2a0f0e3f38964 Merge: 762444c fe7ac5d Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Apr 19 14:35:44 2011 +0200 Merge branch 'master' of git.qos.ch:/slf4j http://git.qos.ch/gitweb/?p=slf4j.git;a=commit;h=762444cae9cc6a7746daba8723… http://github.com/ceki/slf4j/commit/762444cae9cc6a7746daba87234bf1a15f93c294 commit 762444cae9cc6a7746daba87234bf1a15f93c294 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Mon Apr 18 18:39:06 2011 +0200 ongoing edits diff --git a/slf4j-site/src/site/pages/faq.html b/slf4j-site/src/site/pages/faq.html index 79c026c..575f267 100644 --- a/slf4j-site/src/site/pages/faq.html +++ b/slf4j-site/src/site/pages/faq.html @@ -358,9 +358,12 @@ </dt> <dd> - With rare theoretical exceptions, SLF4J versions are backward - compatible. This means than you can upgrade from SLF4J version - 1.0 to any later version without problems. + From the clients perspective, the SLF4J API is backward + compatible between all versions. This means than you can upgrade + from SLF4J version 1.0 to any later version without + problems. Code compiled with slf4j-api-versionN.jar + will work with slf4j-api-versionM.jar for any versionN + and any versionM However, while the SLF4J API is very stable from the client's perspective, SLF4J bindings such as slf4j-simple or ----------------------------------------------------------------------- Summary of changes: slf4j-site/src/site/pages/faq.html | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) hooks/post-receive -- SLF4J: Simple Logging Facade for Java

1 0