Just a clarification in case you are confused by
my recommendation.
This is a recommendation (optional attribute) only if
we don't want to do the properties named in a Sun-specific
way (e.g. prefixing property name by "com.sun.enterprise"
to make it "Sun-specific).
If we indeed settle for naming the properties so that
they don't collide with other software (by naming them
like above), we can just remove this topic from config
change request because that support already exists.
Kedar
Kedar Mhaswade wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>