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