How would you like to proceed?
It'd also be nice to handle the structured data un/marshal with a map or
something. Perhaps a property on the SyslogMessage object?
--
View this message in context:
http://camel.465427.n5.nabble.com/syslog-RFC-5424-dataformat-component-tp5015386p5018448.html
Sen
Yes, it should be fairly easy to do it in one component. The selection
between the two versions can be done either with a uri parameter, or a
different uri scheme (the former sounds like the better option).
Cheers,
Hadrian
On 11/23/2011 09:09 AM, geemang wrote:
The spec does not say anythin
It doesn't look from just reading the RFC as if it would be that hard to
distinguish
Between :
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root'
failed for lonvick on /dev/pts/8
The latte
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 bac
I find this kinda funny. I assume we don't want to go so low as to
publish a html/pdf with this content.
Hadrian
On 11/23/2011 09:19 AM, ningji...@apache.org wrote:
Author: ningjiang
Date: Wed Nov 23 14:19:36 2011
New Revision: 1205412
URL: http://svn.apache.org/viewvc?rev=1205412&view=rev
L
Hi Babak,
Thanks for looking into this issue, I just commit the patch as you
suggested, The generated dummy html has the link to the on line manual.
On Wed Nov 23 19:54:06 2011, bvahdat wrote:
O.K. I reflected my findings [1] regarding the manual issue I mentioned by
this thread today and wou
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 t
O.K. I reflected my findings [1] regarding the manual issue I mentioned by
this thread today and would appreciate any feedback/thoughts...
[1] https://issues.apache.org/jira/browse/CAMEL-3774
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Release-Camel-2-8-3-the-s
O.K. just realized that the issue is already known:
https://issues.apache.org/jira/browse/CAMEL-4284
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Release-Camel-2-8-3-the-second-try-tp5002990p5016078.html
Sent from the Camel Development mailing list archive at Nab
Hi,
The Camel PMC is glad to announce the availability of Apache Camel
2.8.3. This release resolved over 60+ JIRA issues (mostly bugs) reported
by users.
You can download[1] the Camel 2.8.3 now, and please checkout the release
notes here[2].
[1]http://camel.apache.org/download.html
[2]http
Hi,
downloading from a swiss mirror also worked for me, however looking at the
html:
doc/manual/camel-manual-2.8.3.html
the content is:
Download of http://camel.apache.org/book-in-one-page.html
failed
The ending tag is missing and I'm not sure if this body content was
really "on purpose". S
Hi
The 2.8.3 release is synced to the apache mirrors. I could download
the release from a Swedish repo.
I guess we can go ahead with the announcement?
I suppose we can use the wording similar to what we used for the 2.8.2 release?
For example as here:
http://camel.apache.org/2011/10/25/apache-ca
Great! now the referee on the Wiki [1] is also up-to-date as well.
[1] https://cwiki.apache.org/confluence/display/CAMEL/Building (@ the line
"You can also find some helpful notes on usage here." )
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-failure-on-tru
13 matches
Mail list logo
