5 Replies Latest reply on Nov 3, 2005 9:50 AM by Adrian Brock

    State manager

    Tim Fox Master

      In JBoss MQ, the jms users, roles and subscriptions are handled by StateManager, the rest of the persistent data is handled by PersistenceManager.

      Logically at least, they all seem to be part of the same schema, since subscription references destination, and subscripton references user, etc.

      I was wondering what the reasons were for seperating different parts of the logical schema in this way?

      Do you think it would make sense to have all of this managed by persistencemanager, and we could forget StateManager altogether?

      The user could keep the ability to choose a login module that either uses the users/roles data in the db, or some other login module as they choose.





        • 1. Re: State manager
          Tim Fox Master

          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. :)

          • 2. Re: State manager
            Adrian Brock Master

            It is a none issue.

            There is nothing to stop a JBossMQ plugin implementing all the interfaces

            * PersistenceManager
            * CacheStore
            * StateManager

            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.

            • 3. Re: State manager
              Scott Stark Master

              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.

              • 4. Re: State manager
                Tim Fox Master

                Ok good.

                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)

                • 5. Re: State manager
                  Adrian Brock Master

                  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.