Hi Ceki, On Jan 8, 2008 7:04 PM, Ceki Gulcu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >> [email protected] > >> http://www.slf4j.org/mailman/listinfo/user > > _______________________________________________ > > user mailing list > > [email protected] > > 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 > [email protected] > http://www.slf4j.org/mailman/listinfo/user _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
