https://issues.apache.org/jira/browse/METRON-2112 has been committed to
master.
On Tue, May 14, 2019 at 2:38 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> Parser chaining uses the original_string populated by the origin routing
> parser unless you explicitly change it.
>
> https://
Parser chaining uses the original_string populated by the origin routing
parser unless you explicitly change it.
https://github.com/apache/metron/blob/master/metron-platform/metron-parsing/metron-parsers-common/ParserChaining.md#example
For example, the logs here -
http://www.monitorware.com/en/lo
The original string would be the string specified as the message body, thus
each message in the chain produced would just be the bytes passed in, from
a specific field in the incoming message.
On May 10, 2019 at 19:55:28, Simon Elliston Ball (
si...@simonellistonball.com) wrote:
My understandin
My understanding is that chaining preserves (correctly to my mind) the original
original string.
In other words: unless the message strategy is raw message, the original string
is just passed through. Original string therefore comes from outside Metron,
and is preserved throughout Metron proces
What about parser chaining? Should the original string be from kafka, or
the last parsed?
On May 10, 2019 at 19:03:39, Simon Elliston Ball (
si...@simonellistonball.com) wrote:
The only scenario I can think of where a parser might treat original string
differently, or even need to know about i
The only scenario I can think of where a parser might treat original string
differently, or even need to know about it would be different encoding locales.
For example, if the string were to be encoded in a locale specific to the
device and choose the encoding based on metadata or parsed content
> I suppose we could always allow this to be overridden, also.
I like an on/off switch for the "original string" functionality. If on,
you get the original string in pristine condition. If off, no original
string is appended for those who care more about storage space.
I can't think of a reaso
I think that's an excellent idea. Can anyone think of a situation where we
wouldn't want to add this the same way for all parsers? I suppose we could
always allow this to be overridden, also.
On Fri, May 10, 2019 at 3:43 PM Nick Allen wrote:
> I think maintaining the integrity of the original da
I think maintaining the integrity of the original data makes a lot of sense
for any parser. And ideally the original string should be what came out of
Kafka with only the minimally necessary processing.
With that in mind, we could solve this one level up. Instead of relying on
each parser to do t
+1
On May 10, 2019 at 13:57:55, Michael Miklavcic (michael.miklav...@gmail.com)
wrote:
When adding the capability for parsing messages in the JsonMapParser using
JSON Path expressions the original behavior for managing original strings
was changed.
https://github.com/apache/metron/blob/master/m
When adding the capability for parsing messages in the JsonMapParser using
JSON Path expressions the original behavior for managing original strings
was changed.
https://github.com/apache/metron/blob/master/metron-platform/metron-parsing/metron-parsers-common/src/main/java/org/apache/metron/parser
11 matches
Mail list logo
