Hopefully, you've been following the request for
proposed connection pool behavior enhancement. In the spirit
of making it easier to follow, I am starting this
thread regarding the specific recommendation of having
an element called: <sun-specific-property> and favoring
it over the good old <property>.
Benefits of having <sun-specific-property> in addition
to <property>:
1- gives more control to the jdbc-connection-pool implementors
to add these sun-specific properties at will without changing
the schema. But I don't think it is the right precedent to set.
2- a separation of namespace is achieved which is useful in the
event there is a conflict for the name of the property. This
too can be taken care of by providing optional attributes. Or
even by naming the sun-specific properties in a particular
way.
Shortcomings of having <sun-specific-property> in addition
to <property>:
- does not provide a real value add to the config. It is basically
the same as <property>. So, the same could be achieved by
just having additional attributes that are IMPLIED. This is
preferred and is certainly consistent with rest of the config.
This might result in dependence between config and jdbc but
that is how the config changes work across the entire app
server.
- on the admin console, they will probably be required to be
presented differently. Another advantage of not making
a "property" is that we can help users by not making
them "key in" the name of the property. If something
is an attribute, GUI can present it much better.
So, I am not convinced that we need this new element that is
same as an existing attribute. My recommendation is to make
use of additional attributes that are optional. By no means
does this suggest that attributes are better in XML-schema
designs, but that's the way it has been for years, with
app server configuration.
I would like to close soon on this (particular topic).
Kedar