You can also try to use the MDC (Message Diagnostic Context). This at least is supported by log4j backends too.

http://www.slf4j.org/api/org/slf4j/MDC.html
http://logback.qos.ch/manual/mdc.html

It allows to set any property you want on your log message. The log4j formatter can then output these in a special column. I think MDC is a great tool for business tracing as you can also set attributes from the business logic like e.g. the current customer id that is related to this processing.

Christian

Am 11.05.2012 14:54, schrieb William Shatner:
Hi,

Yes I understand that..but they will not get outputted so i dont get any extra tracing benefit unless they use logback.

Thanks again,
W

On Fri, May 11, 2012 at 1:50 PM, ceki <[email protected] <mailto:[email protected]>> wrote:


    Markers are part of the SLF4J API. Thus, whereas logback can filter on
    markers, with other logging frameworks such as log4j and j.u.l, your
    markers will simply be ignored. Markers do not tie you or your users
    to logback.

    By the way, SLF4J already comes with a level called TRACE.

    On 11.05.2012 14:42, William Shatner wrote:

        HI Guys,

        Thanks for the replies. What I'm trying to do is implement a
        tracing
        module for my application with x levels of tracing that users
        can set
        (e.g basic, return types, parameters and so on...). We already
        use slf4j
        for logging purposes and we intend using slf4j to output our
        tracing too.

        Due to various issues with our application tracing levels (our
        custome
        defined tracing levels - not logging levels) and monitoring local
        attributes to change this tracing level... and tie-ing this to
        slff4j
        log levels and then setting up loggers to handle this on
        application
        server the idea was to add more levels to slf4j so that the log
        level/trace level; could be handled/set by the application server
        setting e.g set to FINER and so on will get x level of tracing
        on this
        Logger handler.. perhaps logger.infoPlus was a bad example.

        The reason we are using slf4j is it allows applications using our
        "application" (it's really just a library that other
        applications use)
        use whatever logging implementation they want.

        If I use Markers i think this ties everybody to logback- and
        is still
        not really what I'm looking for

        Anyway, i don't think using standard levels available on Jboss
        such as
        Fine,Finer etc changes things too much from logger.errorPlus
        ....and
        your answers are still relevant...

        Thanks for the replies, any other ideas are welcome.

        Thanks,
        Will

        On Fri, May 11, 2012 at 12:35 PM, ceki <[email protected]
        <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>> wrote:

           On 11.05.2012 12:47, Robert Elliot wrote:

        > Short answer: no.
        >
        > Longer answer:
        >
        > The point of SLF4J is it's a common facade or interface, you
        then

        > choose an implementation (logback, slf4j-log4j, slf4j-jdk14
        etc.).
        > Obviously the existing implementations only know about &
        support the
        > levels defined on the existing interface.

           Yep, as indicates (or fails to indicate) SLF4J is just an
        abstraction
           layer for logging frameworks.


        > Obviously you could write your own interface that extends
        the slf4j
        > Logger interface and adds those methods, but what would you
        do with
        > the calls to them? To get support for new levels you would
        need to
        > write your own implementation which implements your new
        interface
           with
        > its new methods.  You'd then have a coupling between your custom
        > implementation and your custom extension of the SLF4J
        interface, and

        > in all probability a tight coupling from your custom
           implementation to
        > an existing logging subsystem that supports defining new levels.

           The above could be seen as a critique of abstraction layers
        or at
           least it highlights the difficulty of getting abstractions
        layers
           right.


        > I believe Markers are intended to support some of the use
        cases that
        > might otherwise be achieved by custom log levels.

           Correct. Markers give you a another dimension for filtering
           events. Instead of the infoPlus level, you would use the PLUS
           marker. SLF4J support the following syntax:

           Marker PLUS = MarkerFactory.getMarker("PLUS"__);
        logger.info <http://logger.info> <http://logger.info>(PLUS,
        "some message");

           HTH,
           --
           Ceki
        http://twitter.com/#!/ceki <http://twitter.com/#%21/ceki>
        <http://twitter.com/#%21/ceki>


               ----- Original Message -----

                   From: "William Shatner"<shatner.william@__gmail.com
        <http://gmail.com>
        <mailto:[email protected]
        <mailto:[email protected]>>>
                   To: [email protected] <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>
                   Sent: Friday, 11 May, 2012 11:27:33 AM
                   Subject: [slf4j-user] Extend slf4j Tracing Levels
                   Hi,

                   Is it possible to extend slf4j tracing levels to
        have more fine
                   grained levels beyond the standard error,info etc.

                   e.g

        logger.info <http://logger.info> <http://logger.info>
                   logger.infoPlus
                   ...
                   logger.error
                   logger.error1
                   logger.error2

                   ..


                   Thanks,
                   Will



-- Ceki
    http://twitter.com/#!/ceki <http://twitter.com/#%21/ceki>
    _______________________________________________
    slf4j-user mailing list
    [email protected] <mailto:[email protected]>
    http://mailman.qos.ch/mailman/listinfo/slf4j-user




_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Reply via email to