Sorry, but now you are suggesting a different content-model
for the XML element and hence making it even more confusing,
for no additional benefit.
The original e-mail had the following content-model proposed
for jdbc-connection-pool:
<!ELEMENT jdbc-connection-pool (description?, sun-specific-property*, property*)>
What you are suggesting translates to:
<!ELEMENT jdbc-connection-pool (description?, pool-properties?, property*)
and
<!ELEMENT pool-properties (property)*>
From my limited understanding of XML, these two are significantly different.
I don't understand the objection to using <property> elements
*for domain.xml representation* in this case. I understand that
attributes have the problem of changing the schema every now and then, and
hence the provision of <property> came in handy there. I am not sure if
storing the pool properties and driver properties as same <property> elements
in domain.xml is not good. This is what we have been doing (look at the
rest of the app server configuration, please) for quite some time. As long
as the tools do the right thing, no administrator will have to look at the
domain.xml to understand the intricate differences between <property> elements
and <pool-properties> in a jdbc-connection-pool. And as said before, the
name-space issues can be solved by naming the properties in a particular way.
On the CLI, we can think of accepting these pool-specific properties as
--poolproperties (in lieu of --properties) but that too, has limited
benefit. Would the administrator really care? I don't think so.
On the GUI, we can present separate interface for driver properties (a
generic property sheet) and something different for pool properties that
are specific to our implementation.
Regarding making something an attribute of the MBean, I think if anything
that is a get/set kind of attribute of the MBean, it should be represented
as an attribute of the XML element in question.
Another problem with this is it just takes a look at <jdbc-connection-pool>
in isolation. But we should also look at the domain's dtd as a whole. To me,
what you've suggested above is some form of grouping the properties. In essence,
it is same as:
<!ELEMENT properties (property)*>
If we are determined to make a provision for such a thing for connection pool,
we should at least consider keeping it generic, so that others can use it if
there is a need in the future.
I am OK with <properties> (with a grudge), but not OK with <pool-properties>.
Also, think about the CLI commands (we already have 210 of them) required
to provide a decent interface for these. Till now, a connection pool could
be created using:
create-jdbc-connection-pool .... --property foo=bar:foo1=bar1 jcp1
Now we will have
create-jdbc-connection-pool .... --property foo=bar:foo1=bar1 --poolproperties
p1=v1:p2=v2 jcp2.
Is this additional complexity needed?
Not really.
Bill Shannon wrote:
> Jagadish Prasath Ramu wrote:
>
>>> How do all these properties appear in domain.xml? Is something
>>> populating
>>> domain.xml with all *possible* properties for a JDBC driver, even though
>>> the user hasn't changed the value from the default? If so, fixing that
>>> would likely help a lot.
>>>
>> Currently
>> <jdbc-connection-pool>
>> <property name="MaxReconnects" value="3"/>
>> <property name="ConnectTimeout" value="30"/>
>> <property name="AutoReconnectForPools" value="false"/>
>> <property name="ReconnectAtTxEnd" value="false"/>
>> </jdbc-connection-pool>
>>
>> During Con.Pool configuration admin-infrastructure will request the
>> connectors module for properties of datasource.
>>
>> connectors module will introspect the db-driver provided datasource
>> class and provide the properties with their default values.
>>
>> Yes, at present, even if the user has not changed the default value,
>> they are part of con.pool configuration.
>
>
> I think we should consider whether that's the best approach.
> The advantage seems to be that it provides a sort of "documentation"
> of all the properties you can ever possibly set. The disadvantage is
> that it creates a bigger and more confusing domain.xml.
>
>>> Who interprets these properties? I assume that the db-vendor properties
>>> are interpreted by the JDBC driver, correct? Are the sun-specific
>>> properties interpreted only by the app server? If we need two groups,
>>> maybe that's a better way to distinguish them - JDBC driver properties
>>> vs. app server properties or connection pool properties or something
>>> like
>>> that.
>>>
>> Properties obtained from con.pool configuration will be intercepted by
>> app. server and set either as con.pool property or as datasource
>> object's property appropriately.
>
>
> I just talked to Binod about this and now I understand this a bit better.
> As I understand it, the "sun-specific" properties are properties on the
> connection pool. We could, and probably should, provide an MBean that
> exposes these properties as MBean properties (probably as get/set methods)
> for a connection pool. As we update the connection pool implementation,
> we would add more properties to this MBean, and we would like to be able
> to specify values for these properties in the domain.xml file without
> changing the schema, and we would like to be able to set these properties
> in the asadmin "create" command without adding new command line options
> (as is done for existing connection pool properties).
>
> I think this takes us back to one of my earlier comments. It seems
> reasonable to separate these properties into two groups. One group
> is properties that are set on the JDBC driver. The other group is
> properties that are set on the connection pool. The latter set is
> what you were calling "sun-specific".
>
> The important distinction between the two groups of properties is not
> whether they're "Sun specific" or not, it's whether they apply to the
> JDBC driver or to the connection pool. So, with no compatibility
> constraints, I might create <driver-properties> and
> <connection-pool-properties>
> elements in the domain.xml. But since we do have compatibility
> constraints,
> and unfortunately we grouped the properties that apply to the JDBC driver
> under a <jdbc-connection-pool> element, it's a challenge to pick
> appropriate
> names for these elements. One possibility is:
>
> <jdbc-connection-pool>
> <property name="MaxReconnects" value="3"/>
> <property name="ConnectTimeout" value="30"/>
> <property name="AutoReconnectForPools" value="false"/>
> <property name="ReconnectAtTxEnd" value="false"/>
> <pool-property name="ConnectionCreationRetry" value="true"/>
> <pool-property name="ConnectionCreationRetryAttempts" value="3"/>
> <pool-property name="ConnectionCreationTimeout" value="30"/>
> </jdbc-connection-pool>
>
> or, if you really want to reuse the <property> element:
>
> <jdbc-connection-pool>
> <property name="MaxReconnects" value="3"/>
> <property name="ConnectTimeout" value="30"/>
> <property name="AutoReconnectForPools" value="false"/>
> <property name="ReconnectAtTxEnd" value="false"/>
> <pool-properties>
> <property name="ConnectionCreationRetry" value="true"/>
> <property name="ConnectionCreationRetryAttempts" value="3"/>
> <property name="ConnectionCreationTimeout" value="30"/>
> </pool-properties>
> </jdbc-connection-pool>
>
>
> So, bottom line, I agree with the general approach that was proposed,
> but I'm suggesting a different name than "sun-specific-property".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>