Thank you for the update. Some more responses inline.
>
> 1) - the jdbc-resource and connector-resource are the elements that
> have pool-name as an attribute and that contains the value of
> the name of the jdbc/connector-connection-pool defined in the
> same config. So, in effect, you are suggesting changing the
> description of the "pool-name" attribute from this, to a list
> names that are comma separated. Is that right?
> Yes
>
> - if yes, then what are the implications of the same on the creation
> of jdbc-resource itself? For example, will the following kind
> of config now be seen in domain.xml:
>
> <resources>
> ..
> <jdbc-resource jndi-name="jdbc/clustered-pool" pool-name="jcp1,jcp2" .../>
>
> <jdbc-connection-pool name="jcp1" .../>
> <jdbc-connection-pool name="jcp2" .../>
>
> </resources>
>
> - if yes, then this is not a change in the description alone. It gives me
> an impression that you are using existing infrastructure to expand
> the relationship between a resource and connection-pool. Currently, the
> relationship is one->one and you are extending it to be one->many.
> Is that right, or am I missing something?
> Yes
>
> - this is most likely going to complicate the behavior of --cascade
> option on
> delete-jdbc/connector-connection-pool commands. Can you give a little
> more thought to it? This is of course, if above is correct.
> Thanks for pointing this out.
> Yes, cascade option will get affected.
> eg: With ClusteredPool. if a con.pool is deleted with --cascade,
> we cannot delete the resource as the resource is using more than one
> connection pool.
Hmm. This also affects the dynamic reconfiguration because the logic
now will have to change to get the side-effected changes on
jdbc-resource creation/deletion. Currently only the associated pool
was being sent along with resource changes. Now, it will need to
effect other things as well.
Is there a specific reason you are trying to use "pool-name" attribute
for multiple pools? Can this be handled differently?
>
> - Secondly, why do you need a <sun-specific-property> which is just
> same as <property> element? Why can't we reuse <property>? After all,
> <property> was designed to take care of vendor specific configuration
> options.
> Yes, however currently we are not differentiating
> appserver-vendor-specific and EIS-specific properties.
> This differentiation will help users to actually know the
> appserver-vendor-specific & EIS properties.
>
> eg: MySQL has 100+ datasource properties. In domain.xml/ GUI,
> it is difficult for the user to differentiate which are sun-specific &
> EIS specific properties.
I don't understand this. It is GUI that needs to show "pages" of
the properties showing most significant ones before others.
Are you saying that we should now distinguishing at the level
of properties themselves? That's confusing.
Why should customer care if we put <property> or
<sun-specific-property> in domain.xml? Shouldn't tools
do the right thing?
I don't think we should go this path of having
sun-specific-property.
>
>
> 2) If the properties you want to add are sun-specific, is there any reason
> you couldn't make them optional attributes?
>
> These are optional attributes.
> <!ELEMENT jdbc-connection-pool (description?, *sun-specific-property**
> property*)>
No, she meant making them "attributes" like:
<!ATTLIST jdbc-connection-pool sun-specific-property-name CDATA #IMPLIED
...
>
>
> 3) From an API (eg AMX) perspective, I strongly dislike comma-separated
> lists of values. It forces the user to do an "all or none" whack of
> the value eg use a String[]. It forces the AMX code to parse the
> value to provide a decent API, which further couples the code:
>
> String[] getPoolNames(); <= attribute must be parsed.
>
> Also, we typically are lax about saying whether the following are all
> equivalent. Are these the same, or not?
>
> {p1,p2,p3}
> {p1, p2, [3}
> {p1,p2, p3}
> {p1,p2, p3}
> We can assume that all of the above are same
>
> What about
> {p1,,p2,p3}
> Erroneous configuration
>
> I could see other configurations that allow comma separated values.
>
> eg:
> bin/asadmin get --port 4848 default-config.http-service.virtual-server.server.*
> default-config.http-service.virtual-server.server.http-listeners = http-listener-1,http-listener-2
>
>
> Thanks,
> -Jagadish
>
>
>
>
>
>