Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

message interceptors #1141

Closed
Ladicek opened this issue Mar 31, 2021 · 4 comments
Closed

message interceptors #1141

Ladicek opened this issue Mar 31, 2021 · 4 comments
Labels

Comments

@Ladicek
Copy link
Collaborator

Ladicek commented Mar 31, 2021

It would be useful to have a notion of "message interceptors" for cases when you want to apply some cross-cuting logic to all messages on a number of channels (one, more than one, all). I hear from @cescoffier that this was discussed in MP Reactive Messaging, but couldn't find an issue in https://github.com/eclipse/microprofile-reactive-messaging/issues We could perhaps discuss the idea here and build a prototype in SmallRye.

Based on this discussion: https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Use.20RequestScoped-bean.20in.20Kafka-Interceptor

@cescoffier
Copy link
Contributor

That was related to eclipse/microprofile-reactive-messaging#72.

@wicksim
Copy link

wicksim commented Jan 5, 2022

Is there any progress on this one? We are still looking for a solution for our problem discussed in https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Use.20RequestScoped-bean.20in.20Kafka-Interceptor. A solution with a CDI-Decorator does not seem to work, maybe because of the needed @Channel-annotation. Decorator is just not used.

So I'm still searching for a solution to intercept sending/receiving of Kafka-Messages in a way that I can read some values out of a @RequestScoped CDI-bean.

@mrickly
Copy link

mrickly commented Jul 18, 2022

Would be interesting to have this feature. For outgoing messages we have our custom implementation of the Emitter. For incoming messages, we have a CDI interceptor on the @Incoming methods, but since we need access to the metadata, we need a parameter type that contains the metdata (i.e. we cannot support Record<String, Fruit> or Fruit as parameter types).

@ozangunalp
Copy link
Collaborator

Initial implementation by #1856, to improve if in need

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants