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

Non-default installation for Rabbit is not working #5

Closed
rpbrongers opened this issue Dec 12, 2017 · 1 comment
Closed

Non-default installation for Rabbit is not working #5

rpbrongers opened this issue Dec 12, 2017 · 1 comment

Comments

@rpbrongers
Copy link

Hello,

If you have no localhost RabbitMQ running, I figured out to use the following setup:
(to repro: just create a dotnetcore2.0 console app and (only) nuget EzBus.RabbitMQ in it)

Bus.Configure().UseRabbitMQ(config =>
            {
                config.HostName = "myhostname";
                config.UserName = "myuser";
                config.Password = "mypassword";
                config.Port = 5172;
                config.VirutalHost = "/";
            });

However, the config delegate never gets called. Because the DI container resolves IBusConfig already as part of the Bus.Configure() call (which internally calls GetTransport() which finds as class to use the RabbitMQTransport class that contains an IConfig param in the ctor...). A little later that same config is used to create a connection which obviously fails because it uses the hardcoded defaults (localhost, guest user, etc.) that do not apply. All of this happens even before the call to UseRabbitMQ, so in reality you never get a chance to modify the config.

Is this a design bug, or am I doing something wrong? It looks like the DiceRoller Client from the samples also uses a non-standard config 'BROKR', so it can also be 'work in progress'? Normally I try to find some time to look into it myself some more, but it looks like this one needs diving in too deep for now.

Thanks, library looks great otherwise!

Reinhard

@erilin
Copy link
Contributor

erilin commented Dec 12, 2017

Hi Reinhard,

Thanks for your finding, this most definitely is a bug. As you point out the delegate/action for IRabbitMQConfigs run to late and has no effect.

I thought I solved this earlier (used Uri before, there for testing with "BROKR" to verify)

Will look in to this asap.

@erilin erilin closed this as completed in 8d02fc8 Dec 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants