Rebecca Parks wrote On 08/24/06 21:55,:
> I've been following this discussion, and I still don't see why these
> pool settings can't be implemented as attributes. The advantage of
> attributes is that they're right there in the DTD and anyone can see
> what the available settings are and what their defaults are. If the
> attributes are optional, there is no backward compatibility issue. I
> don't mind expanding the DTD a little bit for the sake of clarity.
> I've always been suspicious of properties because they have in the
> past been a way of sneaking features into the product.
That is one main reason for introducing this new set of properties.
In the past many times, we encountered situations where we had to
add additional tuning capability in the pool using system properties or
by introducting another property hidden inside the JDBC driver
property set.
Generally this happen when a special request come from a team (eg.
seebeyond wanted a periodic validation capability) or for custimer
(sustaining team added a system property for enabling statement wrapping).
It is not practical to change the DTD always in these cases. Mainly because
the request might reach you during a patch release. Making a DTD change
at all these occasions may not be feasible.
Most (or many) of these properties are useful features. If we have
flexible set
of properties, it is simpler to introduce these features, perhaps in an
undocumented way for a particular customer initially and document it in the
next major release.
- Binod.
>
> June
>
> Binod wrote On 08/24/06 08:39,:
>
>>
>>>
>>> Alternatively, we could treat all these as properties, distinguished
>>> only
>>> by name, so that connection pool properties are always named
>>> "pool.*" and
>>> any property name that doesn't start with "pool." is considered a JDBC
>>> driver property. Given the way these properties are used, that doesn't
>>> feel like the right solution to me, but admittedly it will certainly
>>> work
>>> and it's not "terrible".
>>
>>
>>
>> That would work. But it doesnt seem the right way of implementation
>> to me.
>>
>> Even if take this approach, CLI and GUI should be able to distinguish
>> these
>> two sets of properties. Overall, it will be simpler to modify the DTD
>> to allow
>> these two sets properties.
>>
>> - Binod.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
--