Hello!
I've run into a bit of a roadblock due to artemis-amqp-protocol's
MechanismFinder.
I'm working on a library that embeds a broker. As part of this library,
users pass in "authenticators" which are small classes that implement
custom authentication mechanisms. I don't expose any of ActiveMQ's API
anywhere; the library is supposed to be conceptually broker-independent
although ActiveMQ is the only implementation behind it right now. Some
authenticators may require a custom SASL mechanism.
The only way to get a custom SASL mechanism into ActiveMQ's AMQP
implementation right now is to register a class as a ServiceLoader
service, and hope that the precedence is set highly enough that it
overrides any existing mechanism if there are conflicts.
The problem with this is that ServiceLoader registration happens "too
early" and is also global state that will affect any broker instance
that happens to be in the same VM: I don't know which SASL mechanisms
should be registered until the user has produced a list of
authenticators at library initialization time, and I don't want one
broker's authenticators to cause conflicting SASL mechanisms to affect
other brokers in the same VM. I don't expect multiple brokers in the
same VM to be a common use case, but I don't think things should quietly
break if someone does try it.
Only the AMQPConnectionCallback and ProtonProtocolManager use the
MechanismFinder class. Would it be possible to add some method to
explicitly pass in a list of SASL mechanisms, falling back to
MechanismFinder if a list isn't provided?
I'm a proponent of ServiceLoader in general, but I think this is the
wrong way to use it. Library code (of which I consider
artemis-amqp-protocol) should typically always provide a way to pass in
lists of
services explicitly, or fall back to ServiceLoader. It also makes unit
testing a hell of a lot easier.
--
Mark Raynsford | https://www.io7m.com
