-
Notifications
You must be signed in to change notification settings - Fork 78
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
[Host] Set global default Path #290
Comments
There isn't anything like that. Please provide an example how you'd configure it inside the AddSlimMessageBus(). It could be added, I just wonder if that's a common need across most users. |
Just something like mbb.DefaultPath("default"); and it will let us eliminate calls to .DefaultTopic (in Produce()) and .Topic (in Consume()) Right now there's a lot of repeated code when you run everything through a single path (not sure how much of an edge case that is, seems to be the norm at least for MemoryProvider I'd say) |
For memory bus, there is a nice feature to auto declare the producers/consumers and line them up in the respective topics. That prevents users from having to do declarations (including Outside of the memory provider, and on the default (or inferred topic names) I was thinking about perhaps adding some interface (or lambda) that would be set centrally (or picked up from the DI) and allow the users to declare the path/topic names by convention. That would then allow us to assign topic names by message type name (or other ways). e.g. // called once when the .Produce() / .Consume() are configured
public interface IDefaultPathResolver
{
// Gets the path for a producer
string GetPath(ProducerSettings producer);
// Gets the path for a consumer
string GetPath(ConsumerSettings consumer);
}
// as an option if we wanted to make these paths dynamic at the publish stage
public interface IProducerPathResolver
{
// Gets the path for a producer when the message is dispatched
string GetPath(ProducerSettings producer, object message, IDictionarty<string, object> headers);
} |
Hrmm .. not sure .. maybe this mechanism could serve as a base, with a predefined Resolver that autogenerates the names, maybe with configurable prefix. |
Not sure if I missed it in the docs.
If such a feature doesn't exist, it could be modeled similar to how the settings inheritance works in the hybrid bus. i.,e. set a default, but it can be overridden when configuring individual messages
The text was updated successfully, but these errors were encountered: