TODO: RAR metadata repository

[adrian.brock]

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.

[spiritualmechanic]

"See TransactionSupportMetaData.

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

Okay. That makes sense. For instance,

<transaction-support>NoTransaction</transaction-support>

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.

[spiritualmechanic]

Adrian,

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?

[spiritualmechanic]

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

[spiritualmechanic]

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

[spiritualmechanic]

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.

[adrian.brock]

JIRA Task: http://jira.jboss.com/jira/browse/JBJCA-3

[weston.price]

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?

[weston.price]

Also, in looking at

org.jboss.resource.metadata.ConnectorMetaData

the

org.jboss.resource.metadata.TransactionSupportMetaData

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?

[weston.price]

More

If we got rid of

 org.jboss.resource.connectionmanager.RARDeployment

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.