Ralph Goers wrote: > On Dec 4, 2009, at 2:12 PM, Ceki Gülcü wrote: > >> Hi Ralph, >> >> I've looked at the changed you made in relation to RFC 5424. It's >> quite a significant architectural change. The RFC 5424 route is in the >> opposite direction of logback where one creates a new module for each >> new event type.
> I'm confused. What is this "module" that one creates? I assume you > mean an event type is a Marker? If not, what embodies it? I was referring to modules like logback-classic for ILoggingEvent, logback-access for AccessEvent, AuditEvent for logback-audit. >> This offers the benefit of type safety but has >> significant overhead from a packaging pov, whereas the 5424 route has >> little packaging overhead but omits type safety. >> Type safety of what? Everything is a String. With the latest changes >> Joern suggested that is enforced. I have not seen Joern's changes. By using modules you can access each field directly with getters instead of get(eventFieldId). Many you write components this makes a palpabable difference. >> The RFC 5424 approach is not to be discarded. However, I don't think >> it's a route we should take at this *immediate* juncture. I propose to >> put it aside for the time being and come back to it, possibly with a >> vengeance, some time later. > Obviously I have no control over what gets adopted into SLF4J/Logback > but I find this rather disappointing as it means I will either have to > hack something messy on top of Logback or finally get off my butt and > work on Log4j 2.0 which will require far more time than I want to > spend. Structured data support (RFC 5424) is an absolute requirement > for my project. If structured data support is that important, them I encourage you continue to develop your fork. SLF4J is changing very slowly so keeping in sync should not be too difficult. Logback is a different matter, but if your modifications are localized, then rebasing with the logback trunk should be possible as well. Just an idea... > Ralph _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
