[rabbitmq-discuss] Overriding rabbit_auth_mechanism_plain
simon at rabbitmq.com
Wed Mar 13 13:01:04 GMT 2013
On 13/03/13 12:37, Ben Hood wrote:
> I've been overriding the vanilla rabbit_auth_mechanism_plain with a
> plugin that implements SASL/PLAIN.
> It seems that if I shadow the registry of
> the rabbit_auth_mechanism_plain with my custom mechanism with the same
> key, because the plugin loader boots my stuff after the core stuff, my
> definition overrides the previous definition.
> Though this behaviour is cool, I was wondering how stable it would
> remain over time, and whether this particular boot sequence was just
That feels a bit like happenstance - both if you are not declaring the
dependencies and just happening to get your registration step invoked
afterwards, and also relying on registering the same thing twice leading
to the second invocation winning.
> So what I've done is to define a boot step that first unregisters the
> vanilla rabbit_auth_mechanism_plain. If I add this step as a dependency
> for a second step that registers my custom mechanism this seems to work
That feels safer. The key point is that we only guarantee that ordering
will happen according to the dependencies you declare; any other
ordering is coincidence.
> But I'm wondering if I'm going about this in the wrong way.
Hmm, I don't think we really imagined people would be overriding what
existing mechanisms did, we mainly thought people might write new ones.
But I don't think what you're doing is too evil.
> Also, I've added a third boot step to kick off some custom
> initialization for my plugin - so I was also wondering whether this is
> idiomatic or not.
Well, I don't see why you shouldn't combine registration and
initialisation in one boot step. But that's really a style thing.
More information about the rabbitmq-discuss