New feature GROK parser

[Jan Bernhardt <jb...@talend.com>]

Hi Camel Developer,

I just created a new Jira ticket for a camel grok parser:
https://issues.apache.org/jira/browse/CAMEL-10540

The question that I would like to discuss here is how to implement this feature best.

Should the parser become a normal component like this grok://<grok filter>?<grok settings>
or should it be implemented as another language like jsonpath?

Kind regards
Jan

AW: New feature GROK parser

[Jan Bernhardt <jb...@talend.com>]

Hi,

thank you for your feedback. 

The grok parser would not be intended for decision making, so language is properly not a good choice. 
Input would be a String (or Text-Stream) and output would be a Map. 

So I think dataformat could be the right way to go. But the parser would only support unmarshalling. There is no concept of marshalling a grok filter.
Would that be acceptable?

Regards
Jan

> -----Ursprüngliche Nachricht-----
> Von: Siano, Stephan [mailto:stephan.siano@sap.com]
> Gesendet: Montag, 28. November 2016 15:59
> An: dev@camel.apache.org
> Betreff: RE: New feature GROK parser
> 
> Hi,
> 
> I think that depends on what the component is supposed to do.
> 
> If the semantics is that you extract values that are supposed to be used as an
> expression or a predicate to be used in patterns like message router or a
> message filter a language might be appropriate.
> 
> In contrast to that a component is supposed to send the message
> somewhere, to receive a message from somewhere, or to modify an existing
> message (like file, CXF, or XSLT endpoints).
> 
> In addition there are also data formats that allow messages to be marshalled
> to and unmarshalled from a specific binary or text format (like JSON or
> BASE64).
> 
> Therefore the question is what you want to achieve: If you want to construct
> a new message body from an old one applying some rules, a component is
> likely the way to go (or a data format, but that would imply some fixed
> format on one or the other side of the transformation). If you want to make
> decisions (e.g. about routing or filtering) or want use the result of your rules
> as some kind of expression (e.g. you want to keep the original payload but
> set a header to some value extracted from it by your rules) a language is
> more appropriate.
> 
> Best regards
> Stephan
> 
> -----Original Message-----
> From: Jan Bernhardt [mailto:jbernhardt@talend.com]
> Sent: Montag, 28. November 2016 15:15
> To: dev@camel.apache.org
> Subject: New feature GROK parser
> 
> Hi Camel Developer,
> 
> I just created a new Jira ticket for a camel grok parser:
> https://issues.apache.org/jira/browse/CAMEL-10540
> 
> The question that I would like to discuss here is how to implement this
> feature best.
> 
> Should the parser become a normal component like this grok://<grok
> filter>?<grok settings> or should it be implemented as another language like
> jsonpath?
> 
> Kind regards
> Jan
> 

RE: New feature GROK parser

["Siano, Stephan" <st...@sap.com>]

Hi,

I think that depends on what the component is supposed to do.

If the semantics is that you extract values that are supposed to be used as an expression or a predicate to be used in patterns like message router or a message filter a language might be appropriate.

In contrast to that a component is supposed to send the message somewhere, to receive a message from somewhere, or to modify an existing message (like file, CXF, or XSLT endpoints).

In addition there are also data formats that allow messages to be marshalled to and unmarshalled from a specific binary or text format (like JSON or BASE64).

Therefore the question is what you want to achieve: If you want to construct a new message body from an old one applying some rules, a component is likely the way to go (or a data format, but that would imply some fixed format on one or the other side of the transformation). If you want to make decisions (e.g. about routing or filtering) or want use the result of your rules as some kind of expression (e.g. you want to keep the original payload but set a header to some value extracted from it by your rules) a language is more appropriate. 

Best regards
Stephan

-----Original Message-----
From: Jan Bernhardt [mailto:jbernhardt@talend.com] 
Sent: Montag, 28. November 2016 15:15
To: dev@camel.apache.org
Subject: New feature GROK parser

Hi Camel Developer,

I just created a new Jira ticket for a camel grok parser:
https://issues.apache.org/jira/browse/CAMEL-10540

The question that I would like to discuss here is how to implement this feature best.

Should the parser become a normal component like this grok://<grok filter>?<grok settings> or should it be implemented as another language like jsonpath?

Kind regards
Jan