[rabbitmq-discuss] Overriding rabbit_auth_mechanism_plain

[Simon MacMullen]

On 13/03/13 12:37, Ben Hood wrote:
> Hey,
>
> 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
> happenstance.

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
> well.

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.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware