Skip to main content

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

Yep I created a zip with all the dependencies and I can confirm it works fine.
Do you know which dependency brings the slf4j? I want to exclude it from the maven
plugin declaration.



2014/1/17 Joakim Erdfelt <joakim@xxxxxxxxxxx>
Ah, you have jetty-all ! - known bug -> https://bugs.eclipse.org/bugs/show_bug.cgi?id=423421

Don't use that with maven, it is more correct to use the appropriate modular artifacts.
Such as jetty-webapp, and jetty-annotations (those will pull in a majority of jetty on their own)

Know that jetty-start is really just a bootstrap for the standalone distribution, having it as a dependency in maven makes little to no sense.

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


On Fri, Jan 17, 2014 at 8:54 AM, Petar Tahchiev <paranoiabla@xxxxxxxxx> wrote:
OK,

I finally have some progress, although not a good one. Tried the maven-duplicate-finder-plugin but didn't find any duplicates of slf4j :(.
I started debugging it and to be able to debug the jetty classes I included these as provided dependnencies:

        <!-- embedded Jetty dependencies -->
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-start</artifactId>
            <version>${jetty.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.jetty.aggregate</groupId>
            <artifactId>jetty-all</artifactId>
            <version>${jetty.version}</version>
            <scope>provided</scope>
        </dependency>


Here's the actual trace:
1) Spring calls servletContext.log();
2) The servletContext class is actually org.eclipse.jetty.webapp.WebappContext so we end up in here: ContextHandler:2040 which has this method:

        @Override
        public void log(String msg)
        {
            _logger.info(msg);
        }

3) At this point the _logger is {org.eclipse.jetty.util.log.Slf4jLog}org.slf4j.impl.SimpleLogger(/)
4) I hit F5 to step in that method and I step into this:

    public void info(String msg, Object... args)
    {
        _logger.info(msg, args);
    }

which is in org.eclipse.jetty.util.log.Slf4jLog. At this point the _logger is of type org.slf4j.impl.SimpleLogger. I try to step into this with F5 but Intellij does
not allow me to because it doesn't find this class on the classpath!!!!
Now I'm using the Log4J2 library which has this class (org.slf4j.impl.SimpleLogger) inside the log4j-slf4j-impl.jar I guess Jetty is correctly guessing that SimpleLogger is in the classpath so it tries to use the slf4j, but slf4j is not there - logj42 is. As a result I get two loggings:
----------------------------------------------------------------
[INFO] Log4jServletContainerInitializer starting up Log4j in Servlet 3.0+ environment.
[INFO] Initializing Spring root WebApplicationContext
2014-01-17 16:50:38,486 [main] INFO : Root WebApplicationContext: initialization started
2014-01-17 16:50:38,491 [main] INFO : Refreshing Root WebApplicationContext: startup date [Fri Jan 17 16:50:38 CET 2014]
; root of context hierarchy
----------------------------------------------------------------
As you can see the first lines are from slf4j (via jetty's servletContext.log) and the next ones are from log4j2.

Does anyone have a clue how to fix it?




2014/1/13 Joakim Erdfelt <joakim@xxxxxxxxxxx>

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


On Mon, Jan 13, 2014 at 2:19 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:
Petar,

The maven jetty plugin does not contain any slf4j dependencies. You
can confirm that by running "mvn jetty:run -X", which will show you
lots of output including the classpath of the plugins.

I don't believe maven or plexus is leaking it either, as if it were
so, then just by including the slf4j-api as a dependency of the
project, you would see jetty log hooking up to the SimpleLogger and
that doesn't happen.

I suspect that one of the dependencies has the SimpleLogger impl
inside it - have you done "jar tvf xxx.jar | grep SimpleLogger" on
each dependency to check?

Jan

On 14 January 2014 06:32, Petar Tahchiev <paranoiabla@xxxxxxxxx> wrote:
> Hi Joakim,
>
> everything you said is 100% true, unfortunately but I think you don't
> understand what I'm trying to do.
>
> YOU: "For your setup you have a mystery artifact org.apache.logging.log4j:
> log4j-slf4j-impl:${log4j.version}  no idea what that one does."
>
> This artifact is part of the log4j2 project:
> http://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html
>
> It provides (just as you guessed) a binding to slf4j so that all slf4j logs
> will be routed to log4j2 and then to the disk.
> Also
>
> YOU: "... that means you have slf4j-simple.jar in your classpath.  Remove
> that artifact from your classpath."
>
> is exactly what I'm trying to do:
>
> ME: "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 tried mvn dependency:tree but this artifact is nowhere in the dependency
> tree. Unfortunately the mvn dependency:tree resolved only the dependencies
> in the pom, so my guess is that maybe the jetty-maven-plugin or maven itself
> or plexus is dragging that artifact.
>
> And finally
> YOU: "Also note, there's no such thing as "log4j2's simplelogger""
>
> Unfortunately there is. If you open the jar if log4j-slf4j-impl you will see
> there the class org.slf4j.impl.SLF4JLogger which implements the Logger from
> slf4j-api.
>
> Could someone point into a direction how to create jetty logger for log4j2?
>
> Thanks a lot.
>
>
>
> 2014/1/13 Joakim Erdfelt <joakim@xxxxxxxxxxx>
>>
>> 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>
>> webtide.com - intalio.com/jetty
>> Expert advice, services and support from from the Jetty & CometD experts
>> eclipse.org/jetty - cometd.org
>>
>>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>



--
Jan Bartel <janb@xxxxxxxxxxx>
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
_______________________________________________
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



_______________________________________________
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

Back to the top