I'd be nice if we could just handle both. I'm game if you want to chat about it, the first one I just wrote to get a basic setup, the whole syslog world suffers from not being that greatly standardized :)
/je On Nov 23, 2011, at 7:09 AM, geemang wrote: > 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.
