Whatever we end up doing, please supply javadoc for every property
and/or changed feature as part of the change so that AMX can be
updated appropriately. I just need the text, and will add it to AMX.
Lloyd Chambers
On Aug 24, 2006, at 9:55 AM, 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
>>>
>
> --
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>