Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Logging implementations

That logging setup is invalid.

For slf4j, you have 3 categories of dependencies to worry about.

1) the slf4j-api.jar (required always)
2) the logging library you want to use to write logs to disk or screen.
     choose 1 and only 1 (this is not a technical requirement of slf4j, but it makes managing things easier)
     this list includes the following artifacts:
       * slf4j-simple.jar (the provider of org.slf4j.impl.SimpleLogger)
       * slf4j-jcl.jar (slf4j to jakararta commons-logging)
       * slf4j-jdk14.jar (slf4j to java.util.logging)
       * slf4j-log4j12.jar (slf4j to log4j)
       * logback-classic.jar (slf4j to logback)
     lets say you want to use log4j to manage the "to disk" portion.
     that means you'll have the log4j.jar (the actual implementation) and the slf4j-log4j12.jar  (the bridge from slf4j to log4j)
3) the other logging libraries you want to route to slf4j.
     this list includes the following artifacts.
      * jcl-over-slf4j.jar (jakarta commons logging to slf4j)
      * jul-to-slf4j.jar (java.util.logging to slf4j)
      * log4j-over-slf4j.jar (log4j to slf4j)
    be sure you choose all of them except the library you chose in step #2
    so in our case, we avoid using log4j-over-slf4j.jar (as this would cause 2 copies of the log4j classes to be present in the classpath)

For your setup you have a mystery artifact org.apache.logging.log4j:log4j-slf4j-impl:${log4j.version}  no idea what that one does.  I can assume from the description of the artifact that it probably does what step #2 does above, replacing slf4j-log4j12.jar (but i don't know for sure)

As for your debug statement ... [DEBUG] Logging to org.slf4j.impl.SimpleLogger(org.eclipse.jetty.util.log) via org.eclipse.jetty.util.log.Slf4jLog
... that means you have slf4j-simple.jar in your classpath.  Remove that artifact from your classpath.

Also note, there's no such thing as "log4j2's simplelogger".  all slf4j implementations provide a org.slf4j.impl.StaticLoggerBinder that specifies the implementation to use.  If you have more than 1 instance of that specific class in your classpath then you have 2 implementations of slf4j present.

Some examples of slf4j setup in maven with jetty can be found at https://github.com/jetty-project/embedded-jetty-logging-examples


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts


On Mon, Jan 13, 2014 at 1:18 AM, Petar Tahchiev <paranoiabla@xxxxxxxxx> wrote:
Hi Greg,

I'm sure you are right, as I read the same on a lot of places over the internet. I have added the log4j-slf4 bridge

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
            <version>${log4j.version}</version>
        </dependency>

in my project but all I can see is slf4j loggings being logged using the slf4j simple logger:

2014-01-13 09:07:07,750 [main] INFO : Mapped "{[/signin/{providerId}],methods=[GET],params=[error],headers=[],consumes=[
],produces=[],custom=[]}" onto public org.springframework.web.servlet.view.RedirectView org.springframework.social.conne
ct.web.ProviderSignInController.oauth2ErrorCallback(java.lang.String,java.lang.String,java.lang.String,java.lang.String,
org.springframework.web.context.request.NativeWebRequest)
[INFO] ResourceChangeScanner reconfigured with interval=60
[INFO] ResourceChangeScanner created with default interval=60
2014-01-13 09:07:08,563 [main] INFO : Root WebApplicationContext: initialization completed in 28985 ms
2014-01-13 09:07:08.564:INFO:/:Log4jServletContextListener ensuring that Log4j starts up properly.
2014-01-13 09:07:08.590:INFO:/:Log4jServletFilter initialized.

just as the jetty logs say:


---------
[DEBUG] Logging to org.slf4j.impl.SimpleLogger(org.eclipse.jetty.util.log) via org.eclipse.jetty.util.log.Slf4jLog
---------

I believe that someone (jetty, maven, plexus, jetty-maven-plugin) is dragging the slf4j's simple logger in the classpath,
which overrides the log4j2's simplelogger. Unfortunately I can't find out which one.

I will try to create a jetty logger that goes directly to log4j2, cause honestly I don't know what else to do.




2014/1/13 Greg Wilkins <gregw@xxxxxxxxxxx>

Petar,

we don't code against the SimpleLogger API.  Jetty uses it's own Logger API and it will log to stderr if there is no log jars available.    If you only provide the slf4j->log4j2 jar, then jetty logging will detect that as an slf4j log and will use that instead.

If you want to avoid slf4j entirely, you could also write an instance of the Jetty logger that goes direct to log4j2.

cheers




On 12 January 2014 23:55, Petar Tahchiev <paranoiabla@xxxxxxxxx> wrote:
Hi guys,

I'm using the jetty-maven-plugin version 8.1.14.v20131031 and during startup I get this:

---------
[DEBUG] Logging to org.slf4j.impl.SimpleLogger(org.eclipse.jetty.util.log) via org.eclipse.jetty.util.log.Slf4jLog
---------

My application however uses Log4j2 as a logging implementation of slfj4. So instead of having:

log4j -routed to-> log4j2
jcl    -routed to -> log4j2
slf4j -routed to -> log4j2
jul    -routed to -> slf4j -routed to -> log4j2

i correctly get the output of log4j,jcl and log4j2,
but the jul and the slf4j do not get routed to log4j2!!!
As a result I have to configure now both - log4j and slf4j!!!

I don't think it's correct of you to log everything to SimpleLogger - this way you force the user to use the slf4j as their logging implementation. I think you should code against the slf4j-api and then ask the user to select whatever implementation they like.

Any suggestions on how to overcome this are welcome.

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev



_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev




--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev



Back to the top