Kedar Mhaswade wrote:
> Sorry, but now you are suggesting a different content-model
> for the XML element and hence making it even more confusing,
> for no additional benefit.
>
> The original e-mail had the following content-model proposed
> for jdbc-connection-pool:
>
> <!ELEMENT jdbc-connection-pool (description?, sun-specific-property*,
> property*)>
>
> What you are suggesting translates to:
>
> <!ELEMENT jdbc-connection-pool (description?, pool-properties?, property*)
> and
> <!ELEMENT pool-properties (property)*>
>
> From my limited understanding of XML, these two are significantly
> different.
I don't think it's *significantly* different, but I don't care that much about
the exact form of the XML. I also suggested the equivalent of:
<!ELEMENT jdbc-connection-pool (description?, pool-properties?, property*)>
> I don't understand the objection to using <property> elements
> *for domain.xml representation* in this case. I understand that
> attributes have the problem of changing the schema every now and then, and
> hence the provision of <property> came in handy there. I am not sure if
> storing the pool properties and driver properties as same <property>
> elements
> in domain.xml is not good. This is what we have been doing (look at the
> rest of the app server configuration, please) for quite some time. As long
> as the tools do the right thing, no administrator will have to look at the
> domain.xml to understand the intricate differences between <property>
> elements
> and <pool-properties> in a jdbc-connection-pool. And as said before, the
> name-space issues can be solved by naming the properties in a particular
> way.
Because the properties don't already have some naming convention
that makes it clear what applies to what, and because the properties
in question apply to two different objects, I thought it made sense
to separate them. Note that, currently, *all* the properties listed
in <property> elements in domain.xml apply to the JDBC driver, only.
These properties aren't properties in the sense of java.util.Properties,
they're properties in the sense of JavaBeans properties. JavaBeans
properties only make sense when qualified by the object they apply to.
java.util.Properties typically follow a naming convention that indicates
the "subsystem" they apply to.
> On the CLI, we can think of accepting these pool-specific properties as
> --poolproperties (in lieu of --properties) but that too, has limited
> benefit. Would the administrator really care? I don't think so.
I think they will. They'll need to look at our docs to determine what
connection pool properties they can set. They'll need to look at the
JDBC driver vendor's docs to determine what properties they can set
for the driver.
> On the GUI, we can present separate interface for driver properties (a
> generic property sheet) and something different for pool properties that
> are specific to our implementation.
>
> Regarding making something an attribute of the MBean, I think if anything
> that is a get/set kind of attribute of the MBean, it should be represented
> as an attribute of the XML element in question.
Why?
> Another problem with this is it just takes a look at <jdbc-connection-pool>
> in isolation. But we should also look at the domain's dtd as a whole. To
> me,
> what you've suggested above is some form of grouping the properties. In
> essence,
> it is same as:
>
> <!ELEMENT properties (property)*>
>
> If we are determined to make a provision for such a thing for connection
> pool,
> we should at least consider keeping it generic, so that others can use
> it if there is a need in the future.
>
> I am OK with <properties> (with a grudge), but not OK with
> <pool-properties>.
If there's an existing pattern to follow in domain.xml, let's do that.
The pattern I was assuming was that <property> elements appeared under
other elements without separate grouping elements. But to separate
the two different types of properties, we needed either a grouping
element or different kinds of <property> elements, your choice.
> Also, think about the CLI commands (we already have 210 of them) required
> to provide a decent interface for these. Till now, a connection pool could
> be created using:
>
> create-jdbc-connection-pool .... --property foo=bar:foo1=bar1 jcp1
>
> Now we will have
>
> create-jdbc-connection-pool .... --property foo=bar:foo1=bar1
> --poolproperties
> p1=v1:p2=v2 jcp2.
>
> Is this additional complexity needed?
What I was told was that all the connection pool properties are *not*
settable using --property, but instead have separate command line
options for each property. Do you want to add new command line options
every time a new connection pool configuration option is added? Probably
not.
We could continue to treat all the connection pool configuration options
as separate command line options, and separate elements in domain.xml,
but it means that the impact of updating the connection pool implementation
to add another configuration option will be felt widely across the app server.
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".
Maybe we need to hear from some other people...