[
https://issues.apache.org/jira/browse/CAMEL-21749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17928033#comment-17928033
]
Mikael Koskinen commented on CAMEL-21749:
-----------------------------------------
Some of the often used headers are:
{color:#a31515}{color:#a31515}Nats-Service-Error
{color}{color}
{color:#a31515}Nats-Service-Error-Code
{color:#172b4d}NATS has{color} {color:#172b4d}this Services framework nowadays
build-in and the services use headers to communicate the response statuses
(exceptions etc):
[https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-32.md#error-handling].
Also tracing uses headers:
https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-41.md#ad-hoc-activation
{color}{color}
{color:#a31515}{color:#172b4d}And the other aspect is the custom application
specific headers. {color}{color}
{color:#a31515}{color:#172b4d}Regarding NATS component overall, currently it is
missing the JetStream support. JetStream contains most of the NATS'
functionality, including streams, pull/push consumers, KV and object storage so
they are not available. At some point it would be great to have JS-support
included too, but I wonder if it is better to do this in a separate
JetStream-component.{color}{color}
> Camel NATS & Expanded header usage
> ----------------------------------
>
> Key: CAMEL-21749
> URL: https://issues.apache.org/jira/browse/CAMEL-21749
> Project: Camel
> Issue Type: New Feature
> Components: camel-nats
> Affects Versions: 4.10.0
> Reporter: Mikael Koskinen
> Priority: Major
>
> Currently NATS Producer and Consumer both only use some of the headers
> included in the NATS msg:
> {code:java}
> exchange.getIn().setHeader(NatsConstants.NATS_REPLY_TO,
> msg.getReplyTo());
> exchange.getIn().setHeader(NatsConstants.NATS_SID,
> msg.getSID());
> exchange.getIn().setHeader(NatsConstants.NATS_SUBJECT,
> msg.getSubject());
> exchange.getIn().setHeader(NatsConstants.NATS_QUEUE_NAME,
> msg.getSubscription().getQueueName());
>
> exchange.getIn().setHeader(NatsConstants.NATS_MESSAGE_TIMESTAMP,
> System.currentTimeMillis());{code}
> This is problematic in couple of ways: NATS nowadays has quite many headers
> which are missing from the list. And also as NATS itself doesn't limit what
> headers are used, the headers often contain app specific metadata which would
> be helpful to have in Camel Integrations.
> Does the NATS component have to limit the headers that it reads? Could it
> read them all? Or could we use something like headerFilterStrategy in this?
> I'm happy to help with implementing the code but would appreciate if someone
> can provide guidance on design.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
