logback-test.xml file in used library

[janschulte]

Exists a logback-test.xml file in one used library, it overrides the common logging properties.

[nuest]

Interesting - do you have some documentation on that? I also switched a project to logback recently and have troubles configuring the log outputs for testing...

[matthesrieke]

In fact, logback.groovy is the one with highehst priority. Documentation on the configuration bootstrapping is available here.

[ridoo]

logback.groovy however, requires additional groovy deps on the classpath. If you don't like to include them you may consider excluding all logback-test.xml files from your build. This should normally be the case when you place it under src/test/resources.

Anyway, in certain eclipse setups (e.g. running your webapp with open submodules from eclipse) the src/test/resources folder will be part of the classpath and therefore pick the first logback-test.xml it finds.

Otherwise we could remove all logback-test.xml files from modules to let the default config take over log configuration

[matthesrieke]

Self-maintained modules should not be the main issue here. logback-test.xml
in 3rd-part libraries are also taken into consideration, as the full
available classpath is seeked. If some library placed a logback-test.xml
into the prodcution .jar, it will be used.

2013/7/3 Henning Bredel notifications@github.com

logback.groovy however, requires additional groovy deps on the classpath.
If you don't like to include them you may consider excluding all
logback-test.xml files from your build. This should normally be the case
when you place it under src/test/resources.

Anyway, in certain eclipse setups (e.g. running your webapp with open
submodules from eclipse) the src/test/resources folder will be part of the
classpath and therefore pick the first logback-test.xml it finds.

Otherwise we could remove all logback-test.xml files from modules to let
the default config take over log configuration

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-20400829
.

Matthes Rieke
52° North Initiative for Geospatial Open Source Software GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
E-Mail: m.rieke@52north.org
Fon: +49-(0)-251–396371-51
Fax: +49-(0)-251–396371-11

http://52north.org/
Follow us on Twitter: @FiveTwoN

General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk
Local Court Muenster HRB 10849

[ridoo]

@matthesrieke so what is your suggestion here? Be sure to always have a logback.groovy in place to keep 3rd party logback-test.xml files being used? I personally find adding groovy dependencies may be a bit much footprint for just parsing an xml file ...

[matthesrieke]

I do not have a clean solution. Maybe post a request on the logback mailing list?

[ridoo]

Here's a nice discussion tackling this:

http://jira.qos.ch/browse/LOGBACK-618

So, this issue is eclipse specific. However, you can specify the config file to be used via -D parameter:

logback.configurationFile=/path/to/config.xml

I added a note in the 52n logging good practice section

[ridoo]

Another solution might be to eclude any logback-test.xml from eclipse's classpath (might be a bit harsh but it is an eclipse only config where you might be ok with logback's default NoConfigLogger) :

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-eclipse-plugin</artifactId>
                <version>2.9</version>
                <executions>
                    <execution>
                        <phase>!test</phase>
                        <configuration>
                            <sourceExcludes>
                                <sourceExclude>**/logback-test.xml</sourceExclude>
                            </sourceExcludes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

[matthesrieke]

correct me if I am wrong, but wouldn't this also happen in a servlet container when there are multiple libs providing a logback-test.xml in their jars? Of course, it would be bad practice, but still might occur. I guess the SensorWebClient will then take that file as the configuration.

[ridoo]

Am 05.07.2013 14:49, schrieb Matthes Rieke:

correct me if I am wrong, but wouldn't this also happen in a servlet
container when there are multiple libs providing a logback-test.xml in
their jars? Of course, it would be bad practice, but still might occur.
I guess the SensorWebClient will then take that file as the configuration.

You are right. This case can occur if logback-test.xml files are
packaged which should not be the case, when placed in the right
location, e.g. src/test/resources

However, as far as I understand it this may also be the case if a
logback.groovy file is packaged in a jar ...

Best

Henning

Henning Bredel
52°North Initiative for Geospatial Open Source Software GmbH
Martin-Luther-King-Weg 24
48155 Münster
Fon: +49-(0)-251–396371-34
Fax: +49-(0)-251–396371-11
email: h.bredel@52North.org
52North-site: http://www.52north.org
General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk
Local Court Muenster HRB 10849

[matthesrieke]

Yap, I just checked the sources of logback. There is probably no absolutely clean way to work around this issue.

One could define a different configuration file property (via System.setProperty("logback.configurationFile", "/my-logback.xml");) in the very first static { } call of the webapp. But this would affect the whole JVM, respectively all webapps in the container. Though, it should work, as there is always the fallback for logback.groovy -> logback-test.xml -> logback.xml.

[matthesrieke]

see https://github.com/qos-ch/logback/blob/master/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java#L118

[ridoo]

I do not like hacking logback. Just using normal logback.xml entries and exclude logback-test.xml in an eclipse setup should be just fine. I see it as an issue of the 3rd party lib when it includes any logback configuration