-
15. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 9:34 AM (in response to adrian.brock)"Talking to yourself in a forum is a scary sign."
If I don't, I forget which personalities knew what about which parts of code.
If I'm getting a little too verbose for anyone's liking I can just start putting it on my blog. I really don't mind and don't want to pollute the forums :) -
16. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 1:54 PM (in response to adrian.brock)MetaData classes, this is just the ConnectionFactory stuff... DataSource will be similar but specialized:
* AbstractConnectionFactoryMetaData
* NoTxConnectionFactoryMetaData extends AbstractConnectionFactoryMetaData
* TxConnectionFactoryMetaData extends AbstractConnectionFactoryMetaData
* ManagedConnectionPoolMetaData
* ManagedConnectionFactoryMetaData
It looks like the XSL uses "connection factory" but the java uses ConnectionManager. So depending on what we want to use (probably the java) we can change the naming.
Let me know what you prefer. -
17. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 2:20 PM (in response to adrian.brock)Also, ConnectionFactoryDeployerMetaData, which will be the main one, passed into the constructor of ConnectionFactoryDeployment, or into an invoke to create the necessary MBeans.
ConnectionFactoryDeployerMetaData will contain the necessary NoTx/TxConnectionFactoryMetaData, Pool, etc. MetaData.
So it's the one that will contain all the specific stuff. -
18. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 4:01 PM (in response to adrian.brock)The idea is to keep it as simple as possible, like the -ds.xml
You are supposed to hide the implementation (the target of the metadata) so it
can be changed in future without breaking applications.
The user doesn't care if a piece of metadata is consumed by the pool,
CM, MCF, etc.
I would expect to see a top level metadata object with most values.
I think you only need a different metadata object for the properties.
So I would suggest:
ConnectionFactoryMetaData (the main object)
ConnectionFactoryPropertiesMetaData (MCF config)
ConnectionPropertyMetaData (getConnection properties for local jdbc)
XADataSourcePropertyMetaData (XADataSource properties)
DataSourceMetaData would be an alternate main object that specializes
ConnectionFactoryMetaData with the magic pixie dust. -
19. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 4:39 PM (in response to adrian.brock)Ok. Simple. Can do.
-
20. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 7:11 PM (in response to adrian.brock)Okay, here's my first attempt at ConnectionFactoryProperties. I think I'm grabbing all the right ones. I'm not experienced in XSL so I'm deciphering that as well.
public class ConnectionFactoryPropertiesMetaData extends ConfigPropertyMetaDataContainer { // Constants ----------------------------------------------------- // Attributes ---------------------------------------------------- private String userName; private String password; private String transactionIsolation; private String newConnectionSQL; private String checkValidConnectionSQL; private String validConnectionCheckerClassName; private String exceptionSorterClassName; private boolean trackStatements; private int preparedStatementCacheSize; private boolean txQueryTimeout; private HashSet configProperties;
-
21. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 7:24 PM (in response to adrian.brock)Actually, I may have put too much in the above one, if we have a ConnectionPropertyMetaData (getConnection properties for local jdbc)
Most of those look like local JDBC params. Maybe I'm wrong.
Yeah. ConnectionFactoryPropertiesMetaData should have:
1. userName
2. password
3. configProperties
There seem to be a lot of common properties between local and XA. From the XSL:
"template for the ManagedConnectionFactory properties shared between our local and xa wrappers"
private String userName;
private String password;
private String transactionIsolation;
private String newConnectionSQL;
private String checkValidConnectionSQL;
private String validConnectionCheckerClassName;
private String exceptionSorterClassName;
private boolean trackStatements;
private int preparedStatementCacheSize;
private boolean txQueryTimeout; -
22. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 7:35 PM (in response to adrian.brock)No, the properties are a set:
name, value (and sometimes type/class)
The properties you list have been promoted to top level items for the DataSource
to make it easy for the user. We can do this because the DataSource always
targets the jboss jdbc rar which has a known set of properties.
We must hide implementation details from the user.
Put another way:
The general ConnectionFactoryMetaData would have a collection of
ConnectionFactoryPropertyMetaData.
The DataSourceMetaData would hide this, exposing the known properties as
top level items - no need for the collection of ConnectionFactoryPropertyMetaData. -
23. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 7:36 PM (in response to adrian.brock)We still need the connection properties (passed the jdbc driver)
or xa datasource properties (to configure the xads) -
24. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 7:36 PM (in response to adrian.brock)But obviously those two are already relevent for a DataSource.
-
25. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 7:51 PM (in response to adrian.brock)public ConnectionFactoryPropertiesMetaData
private String name;
private String value;
private String type;
public ConnectionFactoryMetaData
private Set properties; // of type above
public DataSourceMetaData extends ConnectionFactoryMetaData
public void setUserName(String)
public String getUserName()
public void setNewConnectionSQL(String)
public String getNewConnectionSQL()
etc.
This would make ConnectionFactoryMetaData very generic (which is fine) and DataSourceMetaData would have more type information on the properties. -
26. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 8:05 PM (in response to adrian.brock)Perfect.
-
27. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic May 28, 2004 8:08 PM (in response to adrian.brock)Okay. So does the ConnectionFactoryMetaData include a Local or an XA metadata object, depending on how it's set up?
I'm just trying to see how those fit into the genericity of CFMD thus far. -
28. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 8:22 PM (in response to adrian.brock)See TransactionSupportMetaData.
Where it makes sense, we should "share" metadata with the rar deployment -
29. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
adrian.brock May 28, 2004 8:25 PM (in response to adrian.brock)In fact, for programmatic deployment it would be useful to identity the rar
and connection-definition and pull through the defaults from the rar meta data.
But this would probably require the rar meta data repository mentioned on
a different thread in this forum.