Bug 966

That certainly makes sense. Thanks for the hint, will do as you suggested.

Have you written your own logging backend adapter for JacORB ? Have you tested using another logging backend?

My application uses Logback: http://logback.qos.ch/

I have not thoroughly tested Jacorb with Logback, but I have experienced no problems. However, all the documentation on SLF4J and Maven suggest this is a very standard thing to do. On my system I modified my local maven Pom with this change, Maven gives me a warning now (that the pom is invalid) but not a big error anymore about StaticLoggerBinder being bound twice.

Do you see JacORB logging (at the different levels) ? I suspect that without extending LogggingInitializer you are probably not seeing implname subsitution correctly?

It's my understanding that you need not implement LoggingInitializer to get functional logging with a different logging backend.  Implname substitution is a feature that JacORB offers with the default backend, but unless users have a need for it, it need not be implemented.

The underlying assumption is that if you switch to your own logging backend, you're on your own.  But we do need to make sure that JacORB utilizes SLF4J properly so that backends can be easily swapped without requiring any JacORB-specific configuration.

Nick, your comments intrigued me and I went and researched this a bit more. Page 28 of the JacORB Programmer's Guide specifically talks about this case, i.e. "When using another logging system besides JDK logging, JacORB does not attempt to configure log verbosity or log file names by itself, as described in the previous section. This means that features such as choosing log file names based on implementation names are not available for other logging systems. <snip> The class needs to extend the class org.jacorb.config.LoggingInitializer and the name of the class needs to be specified in the property jacorb.log.initializer."

Eventually I went and looked at the source of org.jacorb.config.JdkLoggingInitializer, and it has this:

    /**
     * True if the currently used SLF4J backend is the
     * JDK logging implementation.  This is true if and only if
     * the SLF4J-to-JDK adapter can be found on the classpath.
     */
    private static final boolean ISJDKLOGGING;

So, the short answer seems to be, jacorb handles it gracefully if I use a different logging backend, but I lose features unless I extend LoggingInitializer. I am okay with this, mostly because it's more important to me to have a unified logging system than it is for me to have implname substitution. And if I ever decide I want that feature, I can implement LoggingInitializer myself... and possibly submit a pull request.

However, for now, in my opinion it's best if the pom not require it, so the user can decide what behavior they want.

I have experimented with this a bit using the maven demo. The problem is slf4j-jdk14 is not just a compile but also a default runtime dependency. If this is not included the demo outputs e.g.

     [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
     [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
     [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

To avoid your problem and utilise a different logger implementation I think you should exclude slf4j-jdk14 when adding the jacorb dependency e.g.
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-jdk14</artifactId>
                </exclusion>
            </exclusions>
This would allow you to add your slf4j dependency and still allow JacORB default behaviour and the maven demo to work correctly.

Well, once it's no longer listed as a required dependency, you would also put the slf4j-jdk14 in the maven demo pom.xml as a regular dependency.

Anyway, thanks for pointing me in the direction of exclusions. I will use that feature for now.

I am resolving this as invalid as I am not changing the dependency in the pom. However in https://github.com/JacORB/JacORB/pull/76 I have improved the documentation.