Aidan Skinner wrote:
In my continuining quest to make the java broker a pluggable,
maleable, customisable swiss army knife of a message broker, I've been
thinking about making our authorization (not authentication)
mechanisms pluggable. I've put up a quick sketch ritchiem and I hashed
out at
http://cwiki.apache.org/confluence/display/qpid/Java+authorization+plugins
Comments gratefully recieved.
I think if you don't want your plugins to be somewhat brittle and tied
to a particular qpid release, then you need a more abstract interface
for them. It's quite likely something like allowBind(...) will make no
sense in the future.
Do we have a demand for a publicly supported extension point for this
sort of thing? I tend to think this sort of thing exposes us to more
backwards compatibility issues as we move forward, so my inclination is
to be quite careful with what we expose as a supported API.
Of course if the intent is to simply refactor the existing private code
for our own sanity and not make public APIs, then that's another matter.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
