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 OutBoundConnectionFactory MessageListener AdminObject 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. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988590#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...