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.
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
>