[slf4j-user] basic MDC support for java.util.logging

Wed Jan 9 10:04:05 CET 2008

Hi Ceki,

On Jan 8, 2008 7:04 PM, Ceki Gulcu <listid at qos.ch> wrote:
>
> Hi Maarteen,
>
> Just had a look at your contribution.
>
> I have a question in relation with Log4jXmlFormatter. It formats its output
> exactly as the XMLLayout in log4j does. This implies that output logging events
> appears as log4j logging events. Do you have any thoughts on that?

The Log4jXmlFormatter was more a proof-of-concept to show how the MDC
could be used with java.util.logging.

>
> Moreover, who is going to use this output?

The advantage of using the same layout as XMLLayout in log4j is that
people can use existing tools to load their log-files (eg chainsaw and
vigilog).

>
> Incidentally, including the Log4jXmlFormatter in SLF4J implicitly anoints
> log4j's XML layout as an "official" exchange format.
>
> Would it be worthwhile to develop a logging-system neutral XMLLayout which can
> be adapted to JUL, log4j and logback?

I have no strong opinion on this. I understand your concern on making
the log4j XML format an "official" exchange format.
And I do like the idea of an logging-system neutral XMLLayout, of
course the existing XML format has the advantage of being supported by
existing tools.

> Wouldn't this mean a scope-creep as far as
> SLF4J is concerned. SLF4J is about the Logger interface and not about what
> happens behind loggers but SLF4J is also about bridging logging systems.

good point. I have no answer for this :-)
I thought about starting a 'general' logging project that could host
Formatter's for java.util.logging and Layout's for log4j, and logback,
...
But I am not sure about it, since there are so many logging frameworks
already, it might only create more confusion.

>
> Don't get me wrong, I am not saying that XMLLayout in SLF4J would necessarily be
> bad. However, there is certainly a change in scope. It's not a step that should
> not be taken lightly.

I understand. It's not something that has to be decided right way IMO.
But we could already include the attached BasicMDCAdapter in SLF4J
(without the formatter).

That way people using slf4j-jdk14.jar can also benefit from the MDC
with java.util.logging.
And we can refer them to the Log4jXmlFormatter attached to the
bug-report, or they can implement their own formatter.

WDYT ?

Thanks
Maarten

>
>
> Maarten Bosteels wrote:
> > Hello Ceki et al.
> >
> > Have you had time to look at  http://bugzilla.slf4j.org/show_bug.cgi?id=63 ?
> > AFAICS the patch is complete.
> >
> > The included Log4jXmlFormatter has one important limit: the MDC
> > properties will only be correct when format() is called from the same
> > thread that generated the LogRecord. (as indicated by the javadoc).
> >
> > We are getting close to MINA-2.0-M1 and it would be great if we could
> > simply drop our IoSessionLogger
> > in favor of the much more poweful MDC mechanism.
> >
> > Thanks,
> > Maarten
> >
> > On Oct 19, 2007 2:15 PM, Ceki Gulcu <listid at qos.ch> wrote:
> >> Hi Maarteen,
> >>
> >> Comments inline.
> >>
> >> Maarten Bosteels wrote:
> >>  > Hello Ceki,
> >>  >
> >>  > I started coding a BasicMDCAdapter that could be used by java.util.logging
> >>  > Had a look at the log4j MDC implementation and also at LogbackMDCAdapter code.
> >>  >
> >>  > Currently my implementation is roughly the same as the LogbackMDCAdapter
> >>  > without the generics (since SLF4J should run on 1.4 right ?)
> >>
> >> Yes, SLF4J must run under JDK 1.4 or later.
> >>
> >>  > I didn't quite understand this remark in the code:
> >>  > * Each time a value is added, a new instance of the map is created. This is
> >>  > * to be certain that the serialization process will operate on the updated map
> >>  > * and not send a reference to the old map, thus not allowing the remote
> >>  > logback
> >>  > * component to see the latest changes.
> >>
> >> That's an implementation detail in logback. You can safely ignore it
> >> for JUL.
> >>
> >>  > Can you describe a scenario where serialization would fail if one just add a
> >> value to the map ?
> >>  > Is it a threading issue ?
> >>
> >> No, it's not a threading issue. As mentioned previously, you can ignore the
> >> aforementioned comments in logback code.
> >>
> >> [snip]
> >>
> >>  > It would be cool if logback would also have an Log4jXmlLayout. I think the
> >> xml layout has several advantages over serialization:
> >>  > * it's more compact (much to me surprise) certainly when combined with a
> >> GZipOutputStream
> >>  > * human readable
> >>  > * easier to implement in other languages (eg. log4cxx)
> >>  > * no need to depend on log4j's LoggingEvent
> >>  > * protected against changes to the serialized form of log4j's LoggingEvent
> >>  > for example, Chainsaw currently only displays the MDC when the sender is
> >> using log4j 1.3
> >>  >
> >>  > It would be trivial to write, I am willing to implement it, if there's a
> >> chance you will add it to logback.
> >>
> >> In light of what you describe, I think using XML as an exchange format is quite
> >> reasonable. More importantly, it remains aligned with SLF4J's goal of
> >> abstracting/bridging logging systems.
> >>
> >> You mention performance related results comparing XML formatting and Java
> >> serialization. I'd be interested in the figures.
> >>
> >> ps: I'll be away for two weeks and without internet access.
> >>
> >>  > regards,
> >>
> >>  > Maarten
> >>  >
> >>
> >> --
> >> Ceki Gülcü
> >> Logback: The reliable, generic, fast and flexible logging framework for Java.
> >> http://logback.qos.ch
> >> _______________________________________________
> >> user mailing list
> >> user at slf4j.org
> >> http://www.slf4j.org/mailman/listinfo/user
> > _______________________________________________
> > user mailing list
> > user at slf4j.org
> > http://www.slf4j.org/mailman/listinfo/user
>
> --
>
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for Java.
> http://logback.qos.ch
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://www.slf4j.org/mailman/listinfo/user