Datasource Connection Properties using CollectionMetaType, i

[bytor99999]

So the connection properties property is using a CollectionMetaType with a List of GenericMetaValues Is this the correct mapping that should be used.

connection properties needs a name-value pair for each property.

Should connection properties be CompositeValue types?

[starksm64]

CompositeMetaType with CompositeValue is the most logical representation of a Properties.

[bytor99999]

It also looks like for XA Datasources it is different too.

XA connection properties shows as

xa-datasource-properties=
 ManagedProperty{xa-datasource-properties,
 metaType=ImmutableTableMetaType:
 typeName=[java.util.Map]
 rowType=[ImmutableCompositeMetaType{java.util.Map$Entry
 items=[name=key type=java.lang.String],
 [name=value type=java.lang.String]}]
 indexNames=[key]}

But I guess we were expecting

ManagedProperty{(xa-)datasource-properties,
 metaType=ImmutableCompositeMetaType{java.util.Map$Entry
 items=[name=key type=java.lang.String],
 [name=value type=java.lang.String]}

Thanks

[starksm64]

I'm currently fixing this while looking into the missing stats problem, but an issue with the CompositeMetaType for the ds connection properties is that we don't really know what the allowed properties are. Its a function of the driver class. I guess to properly build this set we need to load the java.sql.Driver class for the current driver and call getPropertyInfo(String url, Properties info) to obtain the supported java.sql.DriverPropertyInfo[].

Its a chicken and egg problem though in that unless I have a value for the driver-class property, I don't know what the allowed properties are. In general, its the admin client that would need to do this.

What is jon doing now for these properties?

[bytor99999]

Yep, for some properties it will be like that. Where there isn't a finite or known set of values.

In those cases, JON doesn't need to know the valid value, the UI will allow the user to enter name-value pairs to their content. :)

We definitely have the ability and do set properties to only accept certain valid values for a property, when needed.

In each Property definition we have an xml tag for constraints on the property (Integer, Float, and Regex constraints) and there can be more than just one on a property.

So for connection properties there is no constraints set on it in JON.

Does the MetaTypes need to always have the valid values, or can the Composite type be more open ended if needed?

Mark

[starksm64]

There should be open ended versions of CompositeMetaType/CompositeValue, but currently it looks a little cumbersome. You would have to use a MutableCompositeMetaType implementation of CompositeMetaType, and use MutableCompositeMetaType.addItem(String itemName, String itemDescription, MetaType itemType) before calling CompositeValueSupport.set(String key, MetaValue value).

This should really be internalized in the CompositeValueSupport.set method for MutableCompositeMetaTypes I believe.

[bytor99999]

I understand what you mean.

Because the only way to actually get the KeySet of the underlying Map is through the Type object, which can't be done with an open ended type property

Unless you add the key via MutableCompositeMetaType.addItem(String itemName, String itemDescription, MetaType itemType)

I am not so against having to do that process. If that is what it takes to make it general purpose.

I can also see how you can get the basic information you need for addItem (except for the itemDescription) from the set(String key, MetaValue value)

I would like to avoid the Table types. They seem overkill for configuration properties. They could probably hold the entire set of DS properties within that one Value type object. :)

[starksm64]

This is now working in trunk. See the use of the ProfileServiceUnitTestCase.compositeValueMap for creating the CompositeValue from a Map(String,String). This needs to be moved into the mc metatype MetaValueFactory to allow one to create the CompositeValue directly from the map instance. I'm not sure if your using the MetaValueFactory currently.

[bytor99999]

Thank you Scott.

Yes, I am using the MetaValueFactory in some of my Unit Tests, and might also need to use it in the other code.

[starksm64]

Ok, then a new mc release is needed to obtain an updated MetaValueFactory and move the MapCompositeValueSupport, MapCompositeMetaType into the mc metatype project. Currently they are in the profileservice jars of the server. We won't do an mc release before beta4.

[bytor99999]

Thanks Scott.

Yeah, we don't have to have that in the Factory for right now.

[starksm64]

Note that the testAddNoTxConnectionFactory/testAddTxConnectionFactory are not working yet as the List(ManagedConnectionFactoryPropertyMetaData) config-property type is still not correct. I was trying to convert this into a Map(String,String) composite value by using a ManagedConnectionFactoryPropertyMetaData.name to ManagedConnectionFactoryPropertyMetaData.value entry along with a ManagedConnectionFactoryPropertyMetaData.name+".type" to ManagedConnectionFactoryPropertyMetaData.type entry, but this is not working yet. I'll come back to it after beta4.

[starksm64]

http://jira.jboss.com/jira/browse/JBAS-5221

[bytor99999]

In the ProfileServiceUnitTestCase class, it is only testing xa connection properties, but doesn't test NonXA connection properties.

I was noticing in the NoTx template

DeploymentTemplateInfo noTXinfo = mgtView.getTemplate("NoTxDataSourceTemplate");

that connections properies looked like it is now a CollectionMetaType of CompositeMetaTypes. So a List of Maps. Am I just seeing things, or am I missing something?

I am currently coding a test that logs out all the values and types for the DefaultDS ManagedComponent, just to make sure I saw what I thought I saw. :)

Thanks

[starksm64]

When I look at the connection-properties its a MapCompositeMetaType:

connection-properties=ManagedProperty{connection-properties,dataSourceConnectionProperties,metaType=MapCompositeMetaType{java.lang.Map}}