The spec does not say anything about backwards compatibility, but I believe much of the syslog code in the existing component is reusable.
ASSUMPTIONS: we handle TLS / SSL etc with the netty / mina layer. SYSLOG4J is being used right now, but likely optional. Writing and parsing RFC5424 is not that hard, you guys already handle most of it. So, time permitting, we might move on without it. A RFC5424 syslog event starts like this: <110>1 where the '1' after the > denotes that this is a version greater than 3164. So it's possible to detect this when doing unmarshal and parse the message appropriately. On the unmarshal side we're not so lucky, RFC5424 introduces STRUCTURED-DATA with is a defined structure for the message part. We'd need someway to tell the syslog that we'd like to write structured data. If we enhance the existing syslog component, it'd require some someway the user could select the appropriate version. It'd be nice to handle both RFC's with one component. Is there best practice you can suggest here? -- View this message in context: http://camel.465427.n5.nabble.com/syslog-RFC-5424-dataformat-component-tp5015386p5016770.html Sent from the Camel Development mailing list archive at Nabble.com.
