9 Replies Latest reply on Nov 26, 2006 12:30 AM by Weston M. Price

    TODO: RAR metadata repository

    Adrian Brock Master

      Implement a RAR metadata repository. This would be useful for deployment tools
      and where a connection-definition or message-listener is unique across all
      deployments would negate the need to explicity identity the rar-name in deployments.

        • 1. Re: TODO: RAR metadata repository
          Steve Lewis Expert

          "See TransactionSupportMetaData.

          Where it makes sense, we should "share" metadata with the rar deployment"

          Okay. That makes sense. For instance,


          If the ConnectionFactoryDeployer does not have the transaction support defined, it would grab the property from the RAR as a default.

          Obviously, we could implement it in a (somewhat) obvious way,where we define all the "required" properties, and if a particular one is not set, then grab it from the default.

          But that may be more brittle than what you're thinking about, using the nomenclature of "MetaData Repository." That sounds pretty generic :) Which is fine.

          • 2. Re: TODO: RAR metadata repository
            Steve Lewis Expert


            Do you want to put the ConnectorMetaData in the repository as well? I'm looking at RARDeployment and there's really no reason to pass the ResourceAdapter & ConnectorMetaData in if you have a handle to the data. How do you want to organize it, by MBean name? Or maybe by something else .. JNDI name?

            • 3. Re: TODO: RAR metadata repository
              Steve Lewis Expert

              Actually, resourceadapter isnt' passed in. It's generated from the factory (passing in metadata). The RARDeployer is passed in. Maybe that's not really necessary either. Although if you're creating a connection programmatically, I doubt you'd want to send it the deployer. (Since we're assuming JCA anyways).

              • 4. Re: TODO: RAR metadata repository
                Steve Lewis Expert

                What kind of store were you thinking of using for the metadata repository. Would JBossCache be overkill?

                • 5. Re: TODO: RAR metadata repository
                  Steve Lewis Expert

                  HashMaps. I'm going to try that first. I just found ResourceAdapterObjectModelFactory after looking through SimpleSubDeployerSupport. I don't know why I didn't see this earlier.

                  I'm going to start experimenting with putting the metadata from ResourceAdapterObjectModelFactory into some sort of repository, and organizing it in a way that makes sense, so it can be reused later. I'm not committing anything, although I'm not even sure I have commit access.

                  • 7. Re: TODO: RAR metadata repository
                    Weston M. Price Master

                    Because the new *-dsx.xml deployment work could really benefit from something like this I started thinking about it and implementing a simple prototype. Right now the JcaMetaDataRepository is pretty basic with an internal HashMap() and a set of JcaMetaDataRepostoryKeys. Each key corresponds to a particual type of RAR deployment object


                    However, the problem quickly becomes apparent in trying to do a 'match'. Our JDBC RAR(s) have the same connection definition (javax.sql.DataSource), and it doesn't take much to come up with a pretty trivial example of a message listener conflict (say jms-ra.rar and another JMS providers' RAR both supporting javax.jms.MessageListener).

                    The ra.xml metadata is not the problem, its the limited amount of knowledge the XDeployment types have about their target environment. RARDeployment (the old guy in connectionmanager) simply has the connection defintion and that's about it everything else known is driven on the ConnectorMetaData fetched using the oldRarDeployment name. The EJB(X) deployer has just as limited amount of information in the form of the messageType.

                    Of course we don't want to start forcing more that we have to in the *-ds.xml/*-dsx.xml because at that point, sticking with the oldRarDeployment hack starts to look better and better. On the ConnectionFactory side, we could add an attribute to the RARDeployment, say, transaction support and that would narrow it down some. The message listener and the admin object are still problematic.


                    • 8. Re: TODO: RAR metadata repository
                      Weston M. Price Master

                      Also, in looking at




                      is found at the ConnectorMetaData level. I would actually expect this to be hanging of the ConnectionDefinitionMetaData as it is only applicable to outbound connection factories. Was this done this way for a reason or did it just slip through?

                      • 9. Re: TODO: RAR metadata repository
                        Weston M. Price Master


                        If we got rid of


                        and replaced it with an updated version, say something more appropriate like ManagedConnectionFactoryDeployment we could pass more deployment hints as to the underlying metadata (transaction support, reauthentication support etc).

                        Since we now have 3 classes named RARDeployment, this might not be such a bad thing ;-). Plus, he was always a bit sketchy to being with. Not sure why we ever exposed him as a ManagedConnectionFactory since a majority of those methods are useless from a management perspective.