Reposting the same response, this time with a reason.
Binod P G wrote:
>
>
> 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
>>>
>