[logback-dev] RFC 5424 and Structured Data support.

[Ceki Gulcu]

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