Sorry - I probably wasn't clear in my previous post:
I'm not suggesting changing JBossMQ, but rather whether we should do it the same way in JBossMessaging. :)
It is a none issue.
There is nothing to stop a JBossMQ plugin implementing all the interfaces
Although I didn't design this, I do like it.
I prefer keeping a logical model that allows flexibility over making
implementation decisions in interfaces/contracts.
It does not make sense to force the user permission constructs into the message persistence schema as its a completely seperate aspect that certainly can be managed by a higher level service/component in a deployment. For example, the existing authorization checks can be replaced by a permission check that delegates to the JACC policy and JMS has no idea how the permissions are stored as the JACC layer can be implemented by an abitrary thirdparty.
If we cannot replace the authorization decision point with an implementation that uses the JACC policy today, the security layer needs to be refactored to allow for this. We should in fact create such an interceptor and add tests to the current jacc server configuration unit tests with custom jms permissions to validate sufficient seperation of the security aspect.
I shall make sure we support a FileStateManager and a JDBCStateManager, and keep this all separate from the message persistence schema.
I see no need to change the state-file xml structure or schema so this will be compatible with their JBossMQ equivalents.
One more question, do we need to provide compatibility with OldStateManager in JBoss Messaging? (org.jboss.mq.sm.file.OldStateManager)
OldStateManager is for non-JAAS usage.
It dates back to the SpyderMQ days of JBossMQ
where it would authenticate/authorize internally from the xml config.
I'd provide implementations based on what people actually use/need
rather than try to guess upfront the implementations.