For the first time in my life I find myself in a position where I&#39;m writing a Java API that will be open sourced. Hopefully to be included in many other projects.

For logging I (and indeed the people I work with) have always used JUL (`java.util.logging`) and never had any issues with it. However now I need to understand in more detail what I should do for my API development. I&#39;ve done some research on this and with the information I&#39;ve got I just get more confused. Hence this post.

Since I come from JUL I&#39;m biased on that. My knowledge of the rest is not that big.

From the research I&#39;ve done I&#39;ve come up with these reasons why people do not like JUL:

1. *&quot;I started developing in Java long before Sun released JUL and it was just easier for me to continue with logging-framework-X rather than to learn something new&quot;*. Hmm. I&#39;m not kidding, this is actually what people say. With this argument we could all be doing COBOL. (however I can certainly relate to this being a lazy dude myself)

2. *&quot;I don&#39;t like the names of the logging levels in JUL&quot;*. Ok, seriously, this is just not enough of a reason to introduce a new dependency.

3. *&quot;I don&#39;t like the standard format of the output from JUL&quot;*. Hmm. This is just configuration. You do not even have to do anything code-wise. (true, back in old days you may have had to create your own Formatter class to get it right).

4. *&quot;I use other libraries that also use logging-framework-X so I thought it easier just to use that one&quot;*. This is a circular argument, isn&#39;t ? Why does &#39;everybody&#39; use logging-framework-X and not JUL?

5. *&quot;Everybody else is using logging-framework-X&quot;*. This to me is just a special case of the above. Majority is not always right.


So the real big question is **why not JUL?**. What is it I have missed ? The raison d&#39;&#234;tre for logging facades (SLF4J, JCL) is that multiple logging implementations have existed historically and the reason for that really goes back to the era before JUL as I see it. If JUL was perfect then logging facades wouldn&#39;t exist, or what? To make matters more confusing JUL is to some extent a facade itself, allowing Handlers, Formatters and even the LogManager to be swapped. 

Rather than embracing multiple ways of doing the same thing (logging), shouldn&#39;t we question why they were necessary in the first place? (and see if those reasons still exist)

Ok, my research so far has led to a couple of things that I can see may be **real issues** with JUL:

1. **Performance**. Some say that performance in SLF4J is superior to the rest. This seems to me to be a case of premature optimization. If you need to log hundreds of megabytes per second then I&#39;m not sure you are on the right path anyway. JUL has also evolved and the tests you did on Java 1.4 may no longer be true. You can read about it [here][1] and this fix has made it into Java 7. Many also talk about the overhead of string concatenation in logging methods. However template based logging avoids this cost and it exist also in JUL. Personally I never really write template based logging. Too lazy for that. For example if I do this with JUL:

        log.finest(&quot;Lookup request from username=&quot; + username 
           + &quot;, valueX=&quot; + valueX
           + &quot;, valueY=&quot; + valueY));

    my IDE will warn me and ask permission that it should change it to:

        log.log(Level.FINEST, &quot;Lookup request from username={0}, valueX={1}, valueY={2}&quot;, 
           new Object[]{username, valueX, valueY});

    .. which I will of course accept. Permission granted ! Thank you for your help.

    So I don&#39;t actually write such statements myself, that is done by the IDE.

    In conclusion on the issue of performance I haven&#39;t found anything that would suggest that JUL&#39;s performance is not ok compared to the competition.


2. **Configuration from classpath**. Out-of-the-box JUL cannot load a configuration file from the classpath. It is a [few lines of code][2] to make it do so. I can see why this may be annoying but the solution is short and simple.


3. **Availability of output handlers**. JUL comes with 5 output handlers out-of-the-box: console, file stream, socket and memory. These can be extended or new ones can be written. This may for example be writing to UNIX/Linux Syslog and Windows Event Log. I have personally never had this requirement nor have I seen it used but I can certainly relate to why it may be a useful feature. Logback comes with an appender for Syslog for example. Still I would argue that
    1. 99.5% of the needs for output destinations are covered by what is in JUL out-of-the-box.
    2. Special needs could be catered for by custom handlers on top of JUL rather than on top of something else. There&#39;s nothing to me that suggests that it takes more time to write a Syslog output handler for JUL than it does for another logging framework.


I&#39;m really concerned that there&#39;s something I&#39;ve overlooked. The use of logging facades  and logging implementations other than JUL is so widespread that I have to come to the conclusion that it&#39;s me who just doesn&#39;t understand. That wouldn&#39;t be the first time, I&#39;m afraid. :-)

So what should I do with my API?  I want it to become successful.  I can of course just &quot;go with the flow&quot; and implement SLF4J (which seems the most popular these days) but for my own sake I still need to understand exactly what is wrong with the JUL of today that warrants all the fuzz?  Will I sabotage myself by choosing JUL for my library ?


## Testing performance 
*(section added by nolan600 on 07-JUL-2012)*

There&#39;s a reference below from Ceki about SLF4J&#39;s parametrization being 10 times or more faster than JUL&#39;s. So I&#39;ve started doing some simple tests. At first glance the claim is certainly correct. Here are the preliminary results (but read on!):

* Execution time SLF4J, backend Logback: 1515
* Execution time SLF4J, backend JUL: 12938
* Execution time JUL: 16911

The numbers above are msecs so less is better. So 10 times performance difference is by first actually pretty close. My initial reaction: That is a lot !

Here is the core of the test. As can be seen an integer and a string is construted in a loop which is then used in the log statement:

        for (int i = 0; i &lt; noOfExecutions; i++) {
            for (char x=32; x&lt;88; x++) {
                String someString = Character.toString(x);
                // here we log 
            }
        }


(I wanted the log statement to have both a primitive data type (in this case an int) and a more complex data type (in this case a String). Not sure it matters but there you have it.)


The log statement for SLF4J:

    logger.info(&quot;Logging {} and {} &quot;, i, someString);

The log statement for JUL:

    logger.log(Level.INFO, &quot;Logging {0} and {1}&quot;, new Object[]{i, someString});
 

The JVM was &#39;warmed up&#39; with the same test executed once before the actual measurement was done. Java 1.7.03 was used on Windows 7. Latest versions of SLF4J (v1.6.6) and Logback (v1.0.6) was used. Stdout and stderr was redirected to null device.

However, careful now, it turns out JUL is spending most of its time in `getSourceClassName()` because JUL by default prints the source class name in the output, while Logback doesn&#39;t. So we are comparing apples and oranges. I have to do the test again and configure the logging implementations in a similar manner so that they actually output the same stuff. I do however suspect that SLF4J+Logback will still come out on top but far from the initial numbers as given above. Stay tuned.

Btw: The test was first time I&#39;ve actually worked with SLF4J or Logback. A pleasant experience. JUL is certainly a lot less welcoming when you are starting out.

## Testing performance (part 2)

*(section added by nolan600 on 08-JUL-2012)*

As it turns out it doesn&#39;t really matter for performance how you configure your pattern in JUL, i.e. whether or not it includes the source name or not. I tried with a very simple pattern:

    java.util.logging.SimpleFormatter.format=&quot;%4$s: %5$s [%1$tc]%n&quot;

and that did not change the above timings at all. My profiler revealed that the logger still spent a lot of time in calls to `getSourceClassName()` even if this was not part of my pattern. The pattern doesn&#39;t matter.

I&#39;m therefore concluding on the issue of performance that at least for the tested template based log statement there seems to be roughly a factor of 10 in real performance difference between JUL (slow) and SLF4J+Logback (quick). Just like Ceki said.

I can also see another thing namely that SLF4J&#39;s `getLogger()` call is a lot more expensive than JUL&#39;s ditto. (95 ms vs 0.3 ms if my profiler is accurate). This makes sense. SLF4J has to do some time on the binding of the underlying logging implementation. This doesn&#39;t scare me. These calls should be somewhat rare in the lifetime of an application. The fastness should be in the actual log calls.


# Final conclusion

*(section added by nolan600 on 08-JUL-2012)*

Thank you for all your answers. Contrary to what I initially thought I&#39;ve ended up deciding to use SLF4J for my API. This is based on a number of things and your input:

1. It gives flexibility to choose log implementation at deployment time.

2. Issues with lack of flexibility of JUL&#39;s configuration when run inside an application server.

3. SLF4J is certainly a lot faster as detailed above in particular if you couple it with Logback. Even if this was just a rough test I have reason to believe that a lot more effort has gone into optimization on SLF4J+Logback than on JUL.

4. Documentation. The documentation for SLF4J is simply a lot more comprehensive and precise.

5. Pattern flexibility. As I did the tests I set out to have JUL mimic the default pattern from Logback. This pattern includes the name of the thread. It turns out JUL cannot do this out of the box. Ok, I haven&#39;t missed it until now, but I don&#39;t think it is a thing that should be missing from a log framework. Period! 

6. Most (or many) Java projects today use Maven so adding a dependency is not that big a thing especially if that dependency is rather stable, i.e. doesn&#39;t constantly change its API. This seems to be true for SLF4J. Also the SLF4J jar and friends are small in size.

So the strange thing that happened was that I actually got quite upset with JUL after having worked a bit with SLF4J. I still regret that it has to be this way with JUL. JUL is far from perfect but kind of does the job. Just not quite well enough. The same can be said about `Properties` as an example but we do not think about abstracting that so people can plug in their own configuration library and what have you. I think the reason is that `Properties` comes in just above the bar while the opposite is true for JUL of today ... and in the past it came in at zero because it didn&#39;t exist.


  [1]: http://jeremymanson.blogspot.dk/2009/04/faster-logging-with-faster-logger.html
  [2]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4958543

Why not use java.util.logging?

I&#39;m using [logback][1] in my current project.

It offers six levels of logging: TRACE	DEBUG	INFO	WARN	ERROR	OFF

I&#39;m looking for a rule of thumb to determine the log level for common activities.
For instance, if a thread is locked, should the log message be set to the debug level or the info level.
Or if a socket is being used, should its specific id be logged at the debug level or the trace level.

I will appreciate answers with more examples for each logging level. 

[1]:http://logback.qos.ch/

Logging levels - Logback - rule-of-thumb to assign log levels

In our software we extensively use [**MDC**][1] to track things like session IDs and user names for web requests. This works fine while running in the original thread.

However, there&#39;s a lot of things that need to be processed in the background. For that we use the `java.concurrent.ThreadPoolExecutor` and `java.util.Timer` classes along with some self-rolled *async* execution services. All these services manage their own thread pool.

This is what [Logback&#39;s manual](http://logback.qos.ch/manual/mdc.html#managedThreads) has to say about using MDC in such an environment:

&gt; A copy of the mapped diagnostic context can not always be inherited by worker threads from the initiating thread. This is the case when java.util.concurrent.Executors is used for thread management. For instance, newCachedThreadPool method creates a ThreadPoolExecutor and like other thread pooling code, it has intricate thread creation logic.
&gt; 
&gt; In such cases, it is recommended that MDC.getCopyOfContextMap() is invoked on the original (master) thread before submitting a task to the executor. When the task runs, as its first action, it should invoke MDC.setContextMapValues() to associate the stored copy of the original MDC values with the new Executor managed thread.

This would be fine, but it is a very easy to forget adding those calls, and there is no easy way to recognize the problem until it is too late. The only sign with Log4j is that you get missing MDC info in the logs, and with Logback you get stale MDC info (since the thread in the tread pool inherits its MDC from the first task that was ran on it). Both are serious problems in a production system.

I don&#39;t see our situation special in any way, yet I could not find much about this problem on the web. Apparently, this is not something that many people bump up against, so there must be a way to avoid it. What are we doing wrong here?


  [1]: http://logback.qos.ch/manual/mdc.html

How to use MDC with thread pools?

This seems like a carelessness error, but I can&#39;t seem to find the cause. Logging with logback/slf4j (most recent version slf4j-api-1.6.1, logback core/classic 0.9.24). Simplest log configuration for testing is:

&lt;!-- language: lang-xml --&gt;

    &lt;configuration&gt;
     &lt;appender name=&quot;stdout&quot; class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
      &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
       &lt;!-- DONT USE THIS FORMATTER FOR LIVE LOGGING THE %L LINE NUMBER OUTPUTTER IS SLOW --&gt;
       &lt;pattern&gt;%le %-1r [%c{1}:%L] %m%n&lt;/pattern&gt;
      &lt;/layout&gt;
     &lt;/appender&gt;
     &lt;root level=&quot;DEBUG&quot;&gt;
      &lt;appender-ref ref=&quot;stdout&quot; /&gt;
     &lt;/root&gt;
    &lt;/configuration&gt;

Every log setup starts with logback&#39;s internal status lines:

    11:21:27,825 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
    11:21:27,826 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:.../logback-test.xml]
    11:21:28,116 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
    11:21:28,124 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
    11:21:28,129 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [stdout]
    11:21:28,180 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [layout] on top of the object stack.
    11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - This appender no longer admits a layout as a sub-component, set an encoder instead.
    11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
    11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
    11:21:28,207 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
    11:21:28,207 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [stdout] to Logger[ROOT]

which is, according to the docs, the format logback uses for default. It then finishes reading the config (which is set up to output a different format) and continues with the properly formatted output.  There&#39;s a config parameter `&lt;configuration debug=&quot;false&quot;&gt;` which does not affect this. 

Anyone know how to shut this off? 

How to prevent logback from outputting its own status at the start of every log when using a layout

How can I configure [Logback][1] to log different levels for a logger to different destinations?

For example, given the following Logback configuration, will Logback record `INFO` messages to `STDOUT` and `ERROR` messages to `STDERR`?

(Note that this example is a variation of example `logback-examples/src/main/java/chapters/configuration/sample4.xml` shown in [Chapter 3:  Logback Configuration][2]).

&lt;!-- language: xml --&gt;

    &lt;configuration&gt;
      &lt;appender name=&quot;STDOUT&quot;
       class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
       &lt;encoder&gt;
         &lt;pattern&gt;
            %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
          &lt;/pattern&gt;
        &lt;/encoder&gt;
      &lt;/appender&gt;
      &lt;appender name=&quot;STDERR&quot;
       class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
       &lt;encoder&gt;
         &lt;pattern&gt;
            %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
          &lt;/pattern&gt;
        &lt;/encoder&gt;
        &lt;target&gt;System.err&lt;/target&gt;
      &lt;/appender&gt;
      &lt;!-- What is the effective level of &quot;chapters.configuration&quot;? --&gt;
      &lt;logger name=&quot;chapters.configuration&quot; level=&quot;INFO&quot; additivity=&quot;false&quot;&gt;
        &lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
      &lt;/logger&gt;
      &lt;logger name=&quot;chapters.configuration&quot; level=&quot;ERROR&quot; additivity=&quot;false&quot;&gt;
        &lt;appender-ref ref=&quot;STDERR&quot; /&gt;
      &lt;/logger&gt;
    
      &lt;!-- turn OFF all logging (children can override) --&gt;
      &lt;root level=&quot;OFF&quot;&gt;
        &lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
      &lt;/root&gt;
    &lt;/configuration&gt;


  [1]: http://logback.qos.ch
  [2]: http://logback.qos.ch/manual/configuration.html

How can I configure Logback to log different levels for a logger to different destinations?

We are using log4j behind a selfmade wrapper. We plan to use much more features of it now. 

Should we update to logback ?

(I mean the framework not a facade like SLF4J)

log4j vs logback

I am using logback/slf4j to do my logging. I want to parse my log file to analyze some data, so instead of parsing a great big file (mostly consisting of debug statements) I want to have two logger instances which each log to a separate file; one for analytics and one for all purpose logging. Does anyone know if this is possible with Logback, or any other logger for that matter?

Logback to log different messages to two files

I have the following logback.xml file:


    &lt;configuration debug=&quot;true&quot;&gt; 

    &lt;appender name=&quot;STDOUT&quot; class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt; 
    &lt;encoder&gt;
      &lt;pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n&lt;/pattern&gt;
    &lt;/encoder&gt;
    &lt;/appender&gt;

    &lt;root level=&quot;debug&quot;&gt;
      &lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
    &lt;/root&gt;
    &lt;/configuration&gt;

Now, upon the occurrence of a specific event, I want to programmatically change the level of the root logger from _debug_ to _error_. I can&#39;t use variable substitution, it is mandatory that I do this within the code.

How can it be done ? Thanks.

How to change root logging level programmatically for logback

We are using SLF4J+Logback combination at our project for a while now and are quite happy with it, but our logging strategy is fairly simple, using straightforward class based loggers and no fancy stuff like MDC or Markers.

What I want to know is if anybody in the community actually uses these features and how they are used to improve logging/filtering.

I am specially interested in where, why and how would one use&lt;sup&gt;[1]&lt;/sup&gt; Markers for logging. They strike me as a pretty neat feature for adding semantic context into the logging - e.g. while a class may be handling multiple concerns, one may use task/concern specific markers to discriminate log statements.

What may be the best practices, conventions or strategies for creating and using markers in logging.

**Update:** I guess, what I am really after is not so much _why_ to use markers, but rather the _how_ part &amp;mdash; is there some good practices of naming markers (e.g. using plain text with spaces or dash/underscore/punctuation delimited keyword style names), should there be some sort of pool of &quot;standard names&quot;, naming stuff based on the business functions. The questions I can probably figure out for myself, but if I want to use these features systematically and introduce them to a team of developers, it makes sense to have some formalizeable set of guidelines around...

---

&lt;sup&gt;[1]&lt;/sup&gt; - By asking how to _use_ markers I am not really asking how to use API (it is really quite straight forward) - I am rather referring to the more general level of how would one set up logging around using markers consistently

Best practices for using Markers in SLF4J/Logback

The first time I heard about markers was while reading:

  http://slf4j.org/faq.html

I checked available methods for the **Logger** object:

 * http://www.slf4j.org/api/org/slf4j/Logger.html
 * http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html

and found interfaces:

 * http://www.slf4j.org/api/org/slf4j/Marker.html
 * http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Marker.html

The more in-depth info I got from:

 * http://logback.qos.ch/manual/filters.html

but I am still confused... Note that I asked *why*, not *how* to use them, so this is not a duplicate of:

 * https://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback

**UPDATE** Seems that when you use markers you are also required to write custom Java code instead doing configuration in *XML* or *.property* files...

**UPDATE 2** From http://logback.qos.ch/manual/appenders.html#OnMarkerEvaluator

    Marker notifyAdmin = MarkerFactory.getMarker(&quot;NOTIFY_ADMIN&quot;);
    logger.error(notifyAdmin,
      &quot;This is a serious an error requiring the admin&#39;s attention&quot;,
       new Exception(&quot;Just testing&quot;));

What are markers in Java Logging frameworks and what is a reason to use them?

 - Regarding *Eclipse IDE* (**Indigo**, **Juno** and **Kepler** (32 and 64 bit versions))
 - *Platforms*: **Windows**, **Ubuntu**, **Mac**
 - *m2e version*: **1.1.0.20120530-0009**, **1.2.0.20120903-1050**, **1.3.0.20130129-0926**,                
**1.4.0.20130601-0317**	

----------

**General info**
------------------------------

The above error came after updating the m2e to version 1.1. ***By removing m2e 1.1 and rolling back to m2e 1.0 everything worked fine.*** I tried to repeat the problem in Windows and Ubuntu and it gave me the exact same error. Numerous configurations of the slf4j-api and logback were tested but none seem to work. 

The error appears in any maven project **even without declaring slf4j dependency**. 

 - New Maven Project--&gt; maven-archetype-quickstart 

       **and** 

 - New Maven Project--&gt; Simple project without archetype selection 

   result to

   &lt;!-- language: java --&gt;

    SLF4J: Failed to load class &quot;org.slf4j.impl.StaticLoggerBinder&quot;.

----------

**Testing enviroments and configurations**
------------------------------
Tested with Eclipse Indigo and Eclipse Juno (32 and 64 bit both) on Mac, 32 bit on Ubuntu and 64 and 32 bit on Windows. Tested fresh installs of **Juno Classic**, **Juno Modelling tools**, **Kepler Standard**, **Kepler Modelling Tools** and produced the same error. 

The error appears with **clean**, **install**, **test**, **deploy**, **generate-sources**, **validate** , **compile** , **package**, **integration-test**, **verify** and combinations of the goal clean with the rest goals. It appears also with parameters **-e** and **-X**. There was an attempt to delete the m2e repository and download it from scratch but again without success. It should me mentioned that it was tested in 3 different machines and virtual box all the above systems but it produced the same error. 

Tried all different **logback** configurations (from 1.0.4 to 1.0.13) that resolve the **slf4j-api** and **logback-core** dependencies, but all produce the same error:

&lt;!-- language: xml --&gt;

    &lt;dependency&gt;
       &lt;groupId&gt;ch.qos.logback&lt;/groupId&gt;
       &lt;artifactId&gt;logback-classic&lt;/artifactId&gt;
       &lt;version&gt;&lt;/version&gt;
    &lt;/dependency&gt;

Tried all different (from 1.6.1 to 1.7.5 ) **slf4j-simple** configurations.

&lt;!-- language: xml --&gt;

    &lt;dependency&gt;
       &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
       &lt;artifactId&gt;slf4j-simple&lt;/artifactId&gt;
       &lt;version&gt;&lt;/version&gt;
       &lt;scope&gt;compile&lt;/scope&gt;
    &lt;/dependency&gt;

Tried all different (from 1.6.1 to 1.7.5 ) **log4j-over-slf4j** configurations.

&lt;!-- language: xml --&gt;

    &lt;dependency&gt;
       &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
       &lt;artifactId&gt;log4j-over-slf4j&lt;/artifactId&gt;
       &lt;version&gt;&lt;/version&gt;
       &lt;scope&gt;compile&lt;/scope&gt;
    &lt;/dependency&gt;

Tried all different (from 1.6.1 to 1.7.5 ) **slf4j-jdk14** configurations.

&lt;!-- language: xml --&gt;

    &lt;dependency&gt;
       &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
       &lt;artifactId&gt;slf4j-jdk14&lt;/artifactId&gt;
       &lt;version&gt;&lt;/version&gt;
       &lt;scope&gt;compile&lt;/scope&gt;
    &lt;/dependency&gt;

Tried all different (from 1.6.1 to 1.7.5 ) **slf4j-log4j12** configurations.


&lt;!-- language: xml --&gt;

    &lt;dependency&gt;
         &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
         &lt;artifactId&gt;slf4j-log4j12&lt;/artifactId&gt;
         &lt;version&gt;&lt;/version&gt;
         &lt;scope&gt;compile&lt;/scope&gt;
    &lt;/dependency&gt;


Tried **slf4j-nop 1.7.5** configuration.


&lt;!-- language: xml --&gt;

    &lt;dependency&gt;
      &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
      &lt;artifactId&gt;slf4j-nop&lt;/artifactId&gt;
      &lt;version&gt;1.7.5&lt;/version&gt;
      &lt;scope&gt;compile&lt;/scope&gt;
    &lt;/dependency&gt;


***Last but not least the logs are saved and printed despite the error.***


----------


**Ways to reproduce the error**
------------------------------

 - Download Eclipse Juno, Indigo or Kepler 32 or 64 bit (All installations will
   cause the same error). 
     - Install m2e - Maven Integration for Eclipse
         - Juno - http://download.eclipse.org/releases/juno
         - Kepler - http://download.eclipse.org/releases/kepler
         - Indigo - http://download.eclipse.org/technology/m2e/releases/ (***currently unavailable***)

        **OR**
 
     - Update your m2e version to **1.1.0.20120530-0009**, or **1.2.0.20120903-1050**, or **1.3.0.20130129-0926**, or **1.4.0.20130601-0317** )
&lt;hr&gt;
     - Select File-&gt;New-&gt;Other-&gt;Maven Project-&gt;Click Next-&gt;Select      
   maven-archetype-quickstart from the catalog-&gt;Finish
     
        **OR**

     - Select File-&gt;New-&gt;Other-&gt;Maven Project-&gt;Click Next-&gt;Select Create a simple project (skip archetype selection)-&gt; Complete Artifact info-&gt; Finish
 - Right Click on the project-&gt;Runs As-&gt;clean install (or any other goal mentioned above)

The first line on the console will be 

&lt;!-- language: java --&gt;

    SLF4J: Failed to load class &quot;org.slf4j.impl.StaticLoggerBinder&quot;.
    SLF4J: Defaulting to no-operation (NOP) logger implementation
    SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.



***P.S. Existing projects will produce the same error after updating the m2e version to 1.1.0.20120530-0009***, **1.2.0.20120903-1050**, **1.3.0.20130129-0926**, **1.4.0.20130601-0317**

&lt;hr&gt;
**Updates**
------------------------------

**EDIT**

**m2e support site:** 

 - The above question was posted as a bug in m2e support site and the answer from Igor Fedorenko was that


       &gt; There are no immediate plans to suppress this message.

       For viewing the above bug please refer to [m2e official support site][1]

&lt;hr&gt;
**EDIT 2**

 - The above error indication is **present** also to **m2e** version ***1.2.0.20120903-1050***

&lt;hr&gt;
**EDIT 3**

 - The above error indication is **present** also to **m2e** version ***1.3.0.20130129-0926***


&lt;hr&gt;
**EDIT 4**

 - The above error indication is **present** also to **m2e** version ***1.4.0.20130601-0317***

&lt;hr&gt;
**EDIT 5**

             
                                  ***Reported FIXED***



 - The above error is reported as fixed for **m2e** version ***1.5.0/Luna M3***(*Target Milestone*). The version is not yet available for download. 
 - ***Luna M3*** is [scheduled for Nov. 15th][2]. 
 - Latest dev build are available [here][3]    
 - More information about the m2e milestones you can find at the [m2e main repository][4]. 


  [1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=387064
  [2]: http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Schedule
  [3]: http://nexus.tesla.io:8081/nexus/content/sites/m2e.extras/m2e/1.5.0/N/LATEST/
  [4]: http://git.eclipse.org/c/m2e/m2e-core.git/

SLF4J: Failed to load class &quot;org.slf4j.impl.StaticLoggerBinder&quot;. error

I&#39;ve seen several discussions on the net about how great it would be to have an XML schema or DTD for logback.xml file to have at least the very basic validation and auto-completion in IDEs like IDEA or Eclipse, but I never saw any solution.

Did you?

XML schema or DTD for logback.xml?

Why one would use one of the following packages instead of the other?

  - Java Logging
  - Commons Logging
  - Log4j
  - SLF4j
  - Logback


What&#39;s Up with Logging in Java?

I&#39;m building a small Java app and hoping to use logback for logging.

My app has a dependency on an older project that does its logging via 

    org.apache.commons | com.springsource.org.apache.commons.logging | 1.1.1

...so my plan was to use 

    org.slf4j | jcl-over-slf4j | 1.5.6

...to redirect the JCL logging to 

    org.slf4j | slf4j-api | 1.6.0

...and ultimately to 

    ch.qos.logback | logback-classic | 0.9.22
    ch.qos.logback | logback-core | 0.9.22

so my app can log through logback via its slf4j API while the old library code can log into the same location via the redirection.

Alas, this results in 

    java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
	at   org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:141)

I&#39;ve tried higher and lower verision numbers on some of these jars and also digging through API documentation and such... but I&#39;m unable to find and solve the problem. 

Help, please?

Although logback is considered the &quot;strategic&quot; logging framework, I have some leeway in which logging mechanism I ultimately use. I&#39;d hope to use either logback or log4j, though, and I definitely want to merge the old project&#39;s logging into whatever the &quot;new&quot; logging framework ends up being, via a common configuration.

Logging framework incompatibility

Is it possible to somehow intercept the logging (SLF4J + logback) and get an `InputStream` (or something else that is readable) via a JUnit test case...?

How to intercept SLF4J (with logback) logging via a JUnit test?

I&#39;ve gone through all the [documentation][1] of [logback][2] and I can&#39;t find anywhere the documentation to configure the encoder&#39;s pattern when logging, such as:

&lt;!-- language: xml --&gt;

    &lt;encoder&gt;
      &lt;pattern&gt;%d{HH:mm:ss.SSS} %-4relative %-5level %logger{35} - %msg%n&lt;/pattern&gt;
    &lt;/encoder&gt;

I would like a table (like the one that log4j has) explaining the different options to configure the pattern. 

Where is the documentation of the pattern? Maybe they are defined in another project?


  [1]: http://logback.qos.ch/documentation.html
  [2]: http://logback.qos.ch/

Where is logback encoder pattern documentation

One of my maven module ignores my logging levels when running tests.

In `src/test/resources` I have `application.properties`:

    app.name=bbsng-import-backend
    app.description=Import Backend Module for Application
    spring.profiles.active=test

    # LOGGING
    logging.level.root=error
    logging.level.org.springframework.core =fatal
    logging.level.org.springframework.beans=fatal
    logging.level.org.springframework.context=fatal
    logging.level.org.springframework.transaction=error
    logging.level.org.springframework.test=error
    logging.level.org.springframework.web=error
    logging.level.org.hibernate=ERROR

I also tried `application-test.properties`.

My Application logs a lot, especially when loading context. I tried `logback.xml`, `logback-test.xml` and `logback-spring.xml` but nothing helps.

My pom:

&lt;!-- language: lang-xml --&gt;

	&lt;parent&gt;
		&lt;groupId&gt;at.company.bbsng&lt;/groupId&gt;
		&lt;artifactId&gt;bbsng-import&lt;/artifactId&gt;
		&lt;version&gt;0.1.0-SNAPSHOT&lt;/version&gt;
	&lt;/parent&gt;

	&lt;artifactId&gt;bbsng-import-backend&lt;/artifactId&gt;
	&lt;name&gt;bbsng-import-backend&lt;/name&gt;

	&lt;properties&gt;
		&lt;start-class&gt;at.company.bbsng.dataimport.ApplicationImportBackend&lt;/start-class&gt;
	&lt;/properties&gt;


	&lt;dependencies&gt;

		&lt;!-- APPLICATION ... --&gt;
		&lt;dependency&gt;
			&lt;groupId&gt;at.company.bbsng&lt;/groupId&gt;
			&lt;artifactId&gt;bbsng-app-domain&lt;/artifactId&gt;
			&lt;scope&gt;test&lt;/scope&gt;
		&lt;/dependency&gt;

		&lt;!-- SPRING ... --&gt;
		&lt;dependency&gt;
			&lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
			&lt;artifactId&gt;spring-boot-starter-batch&lt;/artifactId&gt;
		&lt;/dependency&gt;
		&lt;dependency&gt;
			&lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
			&lt;artifactId&gt;spring-boot-starter-test&lt;/artifactId&gt;
			&lt;scope&gt;test&lt;/scope&gt;
		&lt;/dependency&gt;
		&lt;dependency&gt;
			&lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
			&lt;artifactId&gt;spring-boot-starter-data-jpa&lt;/artifactId&gt;
			&lt;scope&gt;test&lt;/scope&gt;
		&lt;/dependency&gt;

		&lt;!-- JAVAX ... --&gt;
		   ...

        &lt;!-- COMMONS ... --&gt;
           ...

		&lt;!-- LOMBOK ... --&gt;
           ...

		&lt;!-- DB --&gt;
           ...

	&lt;/dependencies&gt;

	&lt;build&gt;
		&lt;plugins&gt;
			&lt;plugin&gt;
				&lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
				&lt;artifactId&gt;spring-boot-maven-plugin&lt;/artifactId&gt;
				&lt;version&gt;${org.springframework.boot-version}&lt;/version&gt;
				&lt;executions&gt;
					&lt;execution&gt;
						&lt;goals&gt;
							&lt;goal&gt;repackage&lt;/goal&gt;
						&lt;/goals&gt;
					&lt;/execution&gt;
				&lt;/executions&gt;
			&lt;/plugin&gt;
		&lt;/plugins&gt;
	&lt;/build&gt;


One simple Test class:

&lt;!-- language: lang-java --&gt;

    @ContextConfiguration(classes = { ApplicationImportBackend.class })
    @RunWith(SpringJUnit4ClassRunner.class)
    @ActiveProfiles({ &quot;test&quot; })
    public class BatchJobConfigurationTests {

        @Autowired
        private JobLauncher jobLauncher;

        @Test
        public void testSimpleProperties() throws Exception {
            assertNotNull(jobLauncher);
        }

    }


Application logs is in DEBUG Mode.

And yes, the `application.properties` will be loaded. I already tried to break the application by wrong config.

Thank you for any hints.

Spring Boot Unit Test ignores logging.level

Is there a way to disable the lovely but very visible ASCII Spring boot logo :

      .   ____          _            __ _ _
     /\\ / ___&#39;_ __ _ _(_)_ __  __ _ \ \ \ \
    ( ( )\___ | &#39;_ | &#39;_| | &#39;_ \/ _` | \ \ \ \
     \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
      &#39;  |____| .__|_| |_|_| |_\__, | / / / /
     =========|_|==============|___/=/_/_/_/
     :: Spring Boot ::        (v1.1.8.RELEASE)

...dumped in STDOUT every time your run a spring boot app?

I switched all logging to ERROR in my logback.xml, but that did nothing:

	&lt;root level=&quot;ERROR&quot;&gt;
		&lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
	&lt;/root&gt;

**edit: It&#39;s not called a &quot;Logo&quot; in the documentation. The search-friendly-term is a &quot;banner&quot;.**


how to disable spring boot logo in stdout?

I have a logback appender defined in the logback.xml, it&#39;s a DB appender, but I&#39;m curious if there is any way to configure the appender in java using my own connection pool defined as a bean. 

I find similar things, but never the actual answer. 

Programmatically configure LogBack appender

I have this logback.xml file:

    &lt;configuration debug=&quot;true&quot; scan=&quot;true&quot; scanPeriod=&quot;60 seconds&quot;&gt;
    
      &lt;appender name=&quot;STDOUT&quot; class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
        &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
          &lt;Pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n&lt;/Pattern&gt;
        &lt;/layout&gt;
      &lt;/appender&gt;
      
      &lt;appender name=&quot;FILE&quot; class=&quot;ch.qos.logback.core.rolling.RollingFileAppender&quot;&gt;
        &lt;File&gt;${MY_HOME}/logs/mylog.log&lt;/File&gt;
        
        &lt;rollingPolicy class=&quot;ch.qos.logback.core.rolling.TimeBasedRollingPolicy&quot;&gt;
          &lt;FileNamePattern&gt;logs/my.%d{yyyy-MM-dd}.log&lt;/FileNamePattern&gt;
          &lt;MaxHistory&gt;30&lt;/MaxHistory&gt;
        &lt;/rollingPolicy&gt;
        
        &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
          &lt;Pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level - %msg%n&lt;/Pattern&gt;
        &lt;/layout&gt;
        
      &lt;/appender&gt; 
      
      &lt;root level=&quot;TRACE&quot;&gt;
        &lt;appender-ref ref=&quot;FILE&quot;/&gt;
      &lt;/root&gt;
        
    &lt;/configuration&gt;


And `${MY_HOME}` is a defined system variable (`echo $MY_HOME` on linux shows the correct path).

The thing is that logback doesnt seem to read it properly, it stores the logs under `MY_HOME_IS_UNDEFINED/logs/my.log`

What am I doing wrong? Thanks a lot!

EDIT: I made a mistake and put OSC_HOME where I really meant MY_HOME. Sorry about that

Read environment variables from logback configuration file

Should new projects use logback instead of log4j as a logging framework ?

Or with other words :&#39;Is logback better than log4j (leaving the SLF4J-&#39;feature&#39; of logback beside)?&#39;


Are there technical reasons to prefer using logback instead of log4j?

I&#39;m currently observing that a 3rd party library (namely restfb) is using java.util.logging and I&#39;m seeing those logs end up in STDOUT even though I don&#39;t have an SLF4J console appender configured in my logback.xml. I also have the [jul-to-slf4j][1] bridge in my classpath. Does the jul-to-slf4j bridge only log to the appenders configured by logback when the bridge is installed or does it also log to stdout?


  [1]: http://www.slf4j.org/images/legacy.png

JUL to SLF4J Bridge

I&#180;m trying to split my logback.xml by profiles under springboot, this my approach:

**logback-prod.xml**

    
    &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
    &lt;configuration&gt;
    &lt;include resource=&quot;org/springframework/boot/logging/logback/defaults.xml&quot; /&gt;
    &lt;property name=&quot;LOG_FILE&quot; value=&quot;${LOG_FILE:-${LOG_PATH:-${LOG_TEMP:- ${java.io.tmpdir:-/tmp}}/}spring.log}&quot;/&gt;
    &lt;include resource=&quot;org/springframework/boot/logging/logback/file- appender.xml&quot; /&gt;

    &lt;root level=&quot;INFO&quot;&gt;
        &lt;appender-ref ref=&quot;CONSOLE&quot; /&gt;
    &lt;/root&gt;
    &lt;/configuration&gt; 
**logback-dev.xml**

    &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
    &lt;configuration&gt;
    &lt;include resource=&quot;org/springframework/boot/logging/logback/defaults.xml&quot; /&gt;
    &lt;include resource=&quot;org/springframework/boot/logging/logback/console-appender.xml&quot; /&gt;

    &lt;root level=&quot;DEBUG&quot;&gt;
        &lt;appender-ref ref=&quot;CONSOLE&quot; /&gt;
    &lt;/root&gt;
&lt;/configuration&gt;

**logback.xml**

    &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
    &lt;configuration&gt;
    &lt;include resource=&quot;logback-${spring.profiles.active}.xml&quot;/&gt;

    &lt;root level=&quot;INFO&quot;&gt;
        &lt;appender-ref ref=&quot;FILE&quot; /&gt;
        &lt;appender-ref ref=&quot;CONSOLE&quot; /&gt;
    &lt;/root&gt;
&lt;/configuration&gt;

And finally use: 

    -Dspring.profiles.active=dev
     or
    -Dspring.profiles.active=prod

I got in console:

    13:01:44,673 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@2:16 - no  applicable action for [configuration], current ElementPath  is [[configuration][configuration]]
    13:01:44,674 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@3:81 - no applicable action for [include], current ElementPath  is [[configuration][configuration][include]]
    13:01:44,674 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:89 - no applicable action for [include], current ElementPath  is [[configuration][configuration][include]]
    13:01:44,674 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@6:25 - no applicable action for [root], current ElementPath  is [[configuration][configuration][root]]
    13:01:44,674 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@7:39 - no applicable action for [appender-ref], current ElementPath  is [[configuration][configuration][root][appender-ref]]
    13:01:44,675 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO

Configure logback using several profiles

I use Spring Boot and want it to write log output to a file.

According to the docs, this is simply done by setting

    logging.file=filename.log

While the console output works fine, `filename.log` is not created. Also, if I create the file manually, nothing is written to it. What do I miss?

Spring Boot - no log file written (logging.file is not respected)

I want to have two log files in my application (Spring Integration), debug.log and main.log.  I want to run main.log at an INFO level and debug.log at a DEBUG level.  This is doable with filters on the appenders.  I want to log different levels to the appenders based on the source.  In other words

	&lt;logger name=&quot;org.springframework&quot; level=&quot;ERROR&quot;&gt;
		&lt;appender-ref ref=&quot;main&quot; /&gt;
	&lt;/logger&gt;
	&lt;logger name=&quot;org.springframework&quot; level=&quot;DEBUG&quot;&gt;
		&lt;appender-ref ref=&quot;debug&quot; /&gt;
	&lt;/logger&gt;
	&lt;logger name=&quot;com.myapp&quot; level=&quot;INFO&quot;&gt;
		&lt;appender-ref ref=&quot;main&quot; /&gt;
	&lt;/logger&gt;
	&lt;logger name=&quot;com.myapp&quot; level=&quot;DEBUG&quot;&gt;
		&lt;appender-ref ref=&quot;debug&quot; /&gt;
	&lt;/logger&gt;

So to summarise:

  1. Spring logger
     * main -&gt; ERROR
     * debug -&gt; DEBUG
  2. com.myapp logger
     * main -&gt; INFO
     * debug -&gt; DEBUG

Because of this I have to have the loggers running at DEBUG and a threshold filter on an appender isn&#39;t fine grained enough.

**Update** Added clarity to the question

logback: Two appenders, multiple loggers, different levels

I am implementing logging in a spring boot project with logback library. I want to load different logging configuration files according to my spring profiles (property &#39;spring.pofiles.active&#39;). I have 3 files : logback-dev.xml, logback-inte.xml and logback-prod.xml. I am using spring boot version 1.2.2.RELEASE. 

As you can read in &lt;a href=&quot;http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.html&quot;&gt;spring boot documentation&lt;/a&gt;:

&gt; The various logging systems can be activated by including the appropriate libraries on the classpath, and further customized by providing a suitable configuration file in the root of the classpath, or in a location specified by the Spring Environment property &lt;b&gt;logging.config&lt;/b&gt;. (Note however that since logging is initialized before the ApplicationContext is created, it isn’t possible to control logging from @PropertySources in Spring @Configuration files. System properties and the conventional Spring Boot external configuration files work just fine.)

So I tried to set &#39;logging.config&#39; property in my application.properties file: 

    logging.config=classpath:/logback-${spring.profiles.active}.xml

But when i start my application, my logback-{profile}.xml is not loaded... 

I think logging is a common problem that all projects using spring boot have encountered. Am I on the right track with the above approach? I have other solutions that work, but I find them not as elegant (conditional parsing with Janino in logback.xml file or command line property).

spring boot, logback and logging.config property

I&#39;ve been trying to set up a simple logback project to roll my log files by date and by filesize, and so far I have been unable to get my appender to roll over to another file. Instead, it writes to the log specified by the &amp;lt;file/&amp;gt; tag.

Here is my logback.xml configuration file:

&lt;!-- language: xml --&gt;

    &lt;?xml version=&quot;1.0&quot;?&gt;
    &lt;configuration scan=&quot;true&quot; scanPeriod=&quot;10 seconds&quot;&gt;
        &lt;appender name=&quot;stdout&quot; class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
            &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
                &lt;pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n&lt;/pattern&gt;
            &lt;/layout&gt;
        &lt;/appender&gt;

        &lt;appender name=&quot;milliroller&quot; class=&quot;ch.qos.logback.core.rolling.RollingFileAppender&quot;&gt;
            &lt;file&gt;log/output.log&lt;/file&gt;
            &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
                &lt;pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n&lt;/pattern&gt;
            &lt;/layout&gt;
            &lt;rollingPolicy class=&quot;ch.qos.logback.core.rolling.TimeBasedRollingPolicy&quot;&gt;
                &lt;fileNamePattern&gt;log/mylog-%d{yyyy-MM-dd}.%i.txt&lt;/fileNamePattern&gt;
                &lt;timeBasedFileNamingAndTriggeringPolicy class=&quot;ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP&quot;&gt;
                    &lt;maxFileSize&gt;1KB&lt;/maxFileSize&gt;
                &lt;/timeBasedFileNamingAndTriggeringPolicy&gt;
            &lt;/rollingPolicy&gt;
        &lt;/appender&gt;
    
        &lt;root level=&quot;DEBUG&quot;&gt;
            &lt;appender-ref ref=&quot;stdout&quot;/&gt;
            &lt;appender-ref ref=&quot;milliroller&quot;/&gt;
        &lt;/root&gt;
    
        &lt;logger name=&quot;com.tkassembled.logback&quot; level=&quot;DEBUG&quot;/&gt;
    &lt;/configuration&gt;

At first glance, it looks like it should work, right? Is there something I&#39;m doing wrong? My entire, buildable project is available in a zip here: http://www.mediafire.com/file/2bxokkdyz2i/logback.zip 

Rolling logback logs on filesize and time

We use slf4j + logback, and happened to have some third-party libraries which use commons-logging. How do I set it up to use logback?

How do I set up commons-logging to use logback?

We have a spring-boot 1.0.RC1 application, with logback configured for logging and a logback.xml file in src/test/resources.  When we run spring-boot from maven, the logback file seems to be seen and respected.  (That&#39;s our required logging format after the spring-boot logo)

	D:\Users\myName\My Projects\Work\my-co\my-app\src\my-app\my-app-camel&gt;mvn  clean spring-boot:run -Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener -Dlogback.configurationFile=src/test/resources/logback.xml
	
	&lt;snip/&gt;
	
	[INFO] --- spring-boot-maven-plugin:0.5.0.M7:run (default-cli) @ my-app-camel ---
    06:41:56,011 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [src/test/resources/logback.xml] at [file:/D:/Users/myName/My%20Projects/Work/my-co/my-app/src/my-app/my-app-camel/src/test/resources/logback.xml]
    06:41:56,150 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
    06:41:56,170 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeFilter scanning period to 5 seconds
    06:41:56,171 |-INFO in ReconfigureOnChangeFilter{invocationCounter=0} - Will scan for changes in [[D:\Users\myName\My Projects\Work\my-co\my-app\src\my-app\my-app-camel\src\test\resources\logback.xml]] every 5 seconds.
    06:41:56,172 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
    06:41:56,223 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
    06:41:56,233 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
    06:41:56,276 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
    06:41:56,389 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [me.moocar.logbackgelf.GelfAppender]
    06:41:56,398 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [GELF]
    06:41:56,567 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [com.my-co.my-app.] to DEBUG
    06:41:56,568 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [com.my-co.my-app.] to false
    06:41:56,569 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[com.my-co.my-app.]
    06:41:56,571 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.] to DEBUG
    06:41:56,572 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.] to false
    06:41:56,572 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[org.]
    06:41:56,573 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO
    06:41:56,574 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
    06:41:56,574 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
    06:41:56,578 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@4ffdcca5 - Registering current configuration as safe fallback point

      .   ____          _            __ _ _
     /\\ / ___&#39;_ __ _ _(_)_ __  __ _ \ \ \ \
    ( ( )\___ | &#39;_ | &#39;_| | &#39;_ \/ _` | \ \ \ \
     \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
      &#39;  |____| .__|_| |_|_| |_\__, | / / / /
     =========|_|==============|___/=/_/_/_/
     :: Spring Boot ::            (v1.0.0.RC1)

    06:41:57.436 [com.my-co.my-app.Application.main()] INFO  com.my-co.my-app.Application - Starting Application on MY-LAPTOP-HOSTNAME with PID 7812 (started by myName)
    06:41:57.952 [com.my-co.my-app.Application.main()] INFO  o.s.b.f.xml.XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [META-INF/spring/camel-server.xml]

    &lt;etc./&gt;

However, when we remove a rogue logback.xml file which snuck into src/java/resources and re-run with everything else unchanged (making sure we clean to remove the one in target too):

	D:\Users\myName\My Projects\Work\my-co\my-app\src\my-app\my-app-camel&gt;mvn  clean spring-boot:run -Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener -Dlogback.configurationFile=src/test/resources/logback.xml
	
	&lt;snip/&gt;

    [INFO]
	[INFO] &lt;&lt;&lt; spring-boot-maven-plugin:1.0.0.RC1:run (default-cli) @ my-app-camel &lt;&lt;&lt;
	[INFO]
	[INFO] --- spring-boot-maven-plugin:1.0.0.RC1:run (default-cli) @ my-app-camel ---
    06:53:59,598 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [src/test/resources/logback.xml] at [file:/D:/Users/myName/My%20Projects/Work/my-co/my-app/src/my-app/my-app-camel/src/test/resources/logback.xml]
    06:53:59,736 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
    06:53:59,755 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeFilter scanning period to 5 seconds
    06:53:59,756 |-INFO in ReconfigureOnChangeFilter{invocationCounter=0} - Will scan for changes in [[D:\Users\myName\My Projects\Work\my-co\my-app\src\my-app\my-app-camel\src\test\resources\logback.xml]] every 5 seconds.
    06:53:59,757 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
    06:53:59,806 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
    06:53:59,817 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
    06:53:59,858 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
    06:53:59,971 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [me.moocar.logbackgelf.GelfAppender]
    06:53:59,980 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [GELF]
    06:54:00,144 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [com.my-co.my-app.] to DEBUG
    06:54:00,144 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [com.my-co.my-app.] to false
    06:54:00,145 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[com.my-co.my-app.]
    06:54:00,148 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org.] to DEBUG
    06:54:00,148 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org.] to false
    06:54:00,149 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[org.]
    06:54:00,150 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
    06:54:00,150 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
    06:54:00,151 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
    06:54:00,154 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@54c1f582 - Registering current configuration as safe fallback point

      .   ____          _            __ _ _
     /\\ / ___&#39;_ __ _ _(_)_ __  __ _ \ \ \ \
    ( ( )\___ | &#39;_ | &#39;_| | &#39;_ \/ _` | \ \ \ \
     \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
      &#39;  |____| .__|_| |_|_| |_\__, | / / / /
     =========|_|==============|___/=/_/_/_/
     :: Spring Boot ::            (v1.0.0.RC1)

    2014-02-12 06:54:01.023  INFO 5240 --- [lication.main()] com.my-co.my-app.Application          : Starting Application on MY-LAPTOP-HOSTNAME with PID 5240 (started by myName)
    2014-02-12 06:54:01.564  INFO 5240 --- [lication.main()] o.s.b.f.xml.XmlBeanDefinitionReader      : Loading XML bean definitions from class path resource [META-INF/spring/camel-server.xml]
	
	&lt;etc./&gt;

You&#39;ll notice that the logging format after spring-boot starts is different from the first output. However, logback (prior to Spring-Boot starting) reports it&#39;s seen the logback.xml in src/test/resources, just like it did the first time.  

For interest, our logback.xml (which was in both src/java/resources and src/test/resources is as follows:

    &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
    &lt;configuration scan=&quot;true&quot; scanPeriod=&quot;5 seconds&quot;&gt;

		&lt;appender name=&quot;STDOUT&quot; class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
			&lt;encoder&gt;
				&lt;pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{40} - %msg%n&lt;/pattern&gt;
			&lt;/encoder&gt;
		&lt;/appender&gt;
	
		&lt;appender name=&quot;GELF&quot; class=&quot;me.moocar.logbackgelf.GelfAppender&quot;&gt;
			&lt;facility&gt;logback-gelf-test&lt;/facility&gt;
			&lt;graylog2ServerHost&gt;XXX.XXX.XXX.XXX&lt;/graylog2ServerHost&gt;
			&lt;graylog2ServerPort&gt;NNNNN&lt;/graylog2ServerPort&gt;
			&lt;useLoggerName&gt;true&lt;/useLoggerName&gt;
			&lt;useThreadName&gt;true&lt;/useThreadName&gt;
			&lt;useMarker&gt;true&lt;/useMarker&gt;
			&lt;graylog2ServerVersion&gt;0.9.6&lt;/graylog2ServerVersion&gt;
			&lt;chunkThreshold&gt;1000&lt;/chunkThreshold&gt;
			&lt;messagePattern&gt;%m%rEx&lt;/messagePattern&gt;
			&lt;shortMessagePattern&gt;%.-100(%m%rEx)&lt;/shortMessagePattern&gt;
			&lt;additionalField&gt;ipAddress:_ip_address&lt;/additionalField&gt;
			&lt;additionalField&gt;requestId:_request_id&lt;/additionalField&gt;
			&lt;staticAdditionalField&gt;_node_name:www013&lt;/staticAdditionalField&gt;
			&lt;includeFullMDC&gt;true&lt;/includeFullMDC&gt;
		&lt;/appender&gt;

		&lt;logger name=&quot;com.my-co.my-app.&quot; level=&quot;DEBUG&quot; additivity=&quot;false&quot;&gt;
			&lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
		&lt;/logger&gt;

		&lt;logger name=&quot;org.&quot; level=&quot;DEBUG&quot; additivity=&quot;false&quot;&gt;
			&lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
		&lt;/logger&gt;

		&lt;root level=&quot;INFO&quot;&gt;
			&lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
			&lt;!--&lt;appender-ref ref=&quot;GELF&quot; /&gt;--&gt;
		&lt;/root&gt;

	&lt;/configuration&gt;


So in summary, it seems (though I might be wrong) that when a logback.xml is bundled with my spring-boot app it is seen and used (i.e. in src/java/resources), but when we don&#39;t bundle, then despite logback&#39;s best efforts it&#39;s ignored.
	
As for fixing this, we&#39;re stumped.  We&#39;re guessing that there is something somewhere in our spring-boot jar which is somehow taking precedence, or turning off logback, or stepping in and telling logback to ignore what it&#39;s just been told and to use another default.  

Alternatively we&#39;re being dumb, but can&#39;t see it.  All help gratefully received.

-Dlogback.configurationFile=logback.xml ignored when running Spring-Boot

I have a problem with configuration on Logback in a Spring Boot application. I want my `consoleAppender` to look like the default Spring Boot console appender. How to inherit pattern from Spring Boot default console appender?

Below is my `consoleAppender` configuration

    &lt;appender name=&quot;consoleAppender&quot; class=&quot;ch.qos.logback.core.ConsoleAppender&quot;&gt;
        &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
            &lt;Pattern class=&quot;org.&quot;&gt;
                %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n
            &lt;/Pattern&gt;
        &lt;/layout&gt;
    &lt;/appender&gt;
    

Spring Boot logging pattern

How can I configure Logback to suppress all of its output to the console (standard output)?  In particular, I wish to suppress (or redirect) Logback&#39;s own log messages such as the following:

    16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
    16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
    16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
    16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
    16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
    16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
    16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds. 

I need to disable all logging to standard output because our production environment disallows applications from printing any messages to standard output.

Note I&#39;m using Logback 0.9.21, SLF4J 1.6.0, and our application runs in WebLogic 10.3.2. 

Suppress all Logback output to console?

I would like to configure logback to do the following.

 - Log to a file
 - Roll the file when it reaches 50MB
 - Only keep 7 days worth of logs
 - On startup always generate a new file (do a roll)

I have it all working except for the last item, startup roll.  Does anyone know how to achieve that?  Here&#39;s the config...

&lt;!-- language: xml --&gt;

      &lt;appender name=&quot;File&quot; class=&quot;ch.qos.logback.core.rolling.RollingFileAppender&quot;&gt;
    
        &lt;layout class=&quot;ch.qos.logback.classic.PatternLayout&quot;&gt;
          &lt;Pattern&gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg $%file:%line$%n&lt;/Pattern&gt;
        &lt;/layout&gt;
    
        &lt;File&gt;server.log&lt;/File&gt;
    
        &lt;rollingPolicy class=&quot;ch.qos.logback.core.rolling.TimeBasedRollingPolicy&quot;&gt;
          &lt;FileNamePattern&gt;server.%d{yyyy-MM-dd}.log&lt;/FileNamePattern&gt;
          &lt;!-- keep 7 days&#39; worth of history --&gt;
          &lt;MaxHistory&gt;7&lt;/MaxHistory&gt;
    
          &lt;TimeBasedFileNamingAndTriggeringPolicy class=&quot;ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP&quot;&gt;
            &lt;MaxFileSize&gt;50MB&lt;/MaxFileSize&gt;
          &lt;/TimeBasedFileNamingAndTriggeringPolicy&gt;
    
        &lt;/rollingPolicy&gt;
      &lt;/appender&gt;



How to roll the log file on startup in logback

I&#39;m happily using SLF4J with logback and use **2 appenders** for the **ROOT** logger.

    &lt;root level=&quot;DEBUG&quot;&gt;
    	&lt;appender-ref ref=&quot;STDOUT&quot; /&gt;
    	&lt;appender-ref ref=&quot;FILE&quot; /&gt;
    &lt;/root&gt;

**How could we have different log-levels for both appenders? I still need all ROOT-logger messages.**

 - *DEBUG*-level for STDOUT
 - *INFO*-level for FILE

All log&#39;s need to be part of the output (so the ROOT logger is needed).

How to create 2 different ROOT loggers with logback?

I&#39;ve recently switched from log4j to logback and am wondering if there is an easy way to run logback in debug mode, similar to log4j&#39;s `log4j.debug` property. I need to see where it is picking up my `logback.xml` from.

The docs mention using a `StatusPrinter` to print out logback&#39;s internal status, but that would require code changes.

Run Logback in Debug

The configuration file for logback gets found on the classpath, and is therefore Eclipse-project-specific, which is not what I want. I&#39;m using multiple Java utilities, all of them residing in a single project (this sharing the classpath), and I need to use a specific configuration for some of them.

I&#39;ve tried variable substitution and Joram configurator, but nothing worked for me. This was most probably my fault, and I&#39;m going to solve it one day, but for now I&#39;d need a simple solution.


How to use multiple configurations with logback in a single project?

I know I can set the logback.xml path like this:

**Specifying the location of the default configuration file as a system property**

  You may specify the location of the default configuration file with a system property named &quot;logback.configurationFile&quot;. The value of this property can be a URL, a resource on the class path or a path to a file external to the application.
    
    java -Dlogback.configurationFile=/path/to/config.xml chapters.configuration.MyApp1

but how can I do it in code?

All Logback Solutions on Gang of Coders

Total of 36 Logback Solutions