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:jbernha...@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
