Replies: 4 comments
-
|
A couple of thoughts. We have added support for registering some global attributes, I'll dig that out later, which lets you avoid the problem of repeated registration. That might solve your problem. We need to document this I think Alternatively, this looks like our existing issues about proper support for a fluent approach, that also respects the attributes on the individual handlers, and we could pick up that work. |
Beta Was this translation helpful? Give feedback.
-
|
Okay. Thanks @iancooper , we will give that a go. I spiked out my thoughts just after I raised this issue |
Beta Was this translation helpful? Give feedback.
-
|
@spektrix-dev Sorry, I never saw this and just picked up in review. It's worth using our Gitter channel when this happens. Let me take a look asap |
Beta Was this translation helpful? Give feedback.
-
|
We'll try to pick up this conversation post v9 |
Beta Was this translation helpful? Give feedback.
-
We are using Brighter in our microservice to handle messages from RabbitMQ. We had created a method to register handlers with the IServicesCollection.
We have been a bit naughty and actually registered a decorator as the concrete which delegates to the actual handler. This allows for our logging, metrics and exception concerns to be added to each handler without having to decorate the HandleAsync method with one or more handler attributes.
This has worked fine, until we wanted to decorate the HandleAsync method with other handler attributes. Because the service provider serves back a decorated handler, it doesn't have the attributes belonging to its own handler and thus they are not added to the pipeline.
We would like to have the best of both worlds, which at present doesn't appear to be possible.
If there were the concept of a PipelineBuilderFactory, we could extend the behaviour of the current PipelineBuilder as described above.
Beta Was this translation helpful? Give feedback.
All reactions