Andrew McIntyre wrote:
On 2/21/07, Kim Haase <[EMAIL PROTECTED]> wrote:
2) In a JDBC program, calling the
org.apache.derby.jdbc.ClientDataSource.setSecurityMechanism method
3) Specifying the connection URL property securityMechanism
Note that these two are for specifying the security mechanism for the
connection client side.
But with the last one it seems you have to use a numeric literal? This
seems unfortunate. I wonder if that is why it is not documented?
I'm not clear on the reason for the lack of documentation, but I agree
it is unfortunate. I've opened DERBY-2361 for adding documentation for
the connection URLs. See also DERBY-963 for changing the client to use
text names instead of numbers to match (1) and (2).
To be precise, 2) and 3) are both setting the same client
property/attribute using a numeric value. In the example shown for 2) a
Java constant is used that represents a number. In the DataSource case
the property is a int property, in the JDBC attribute case the value
needs to be an integer, but the api means that the integer has to be
passed as a string (use of a Properties object or a JDBC URL).
Alternate ways of setting 2) & 3) can show use of a numeric literal for
2) and use of the Java constant for 3).
2a) setting the database source property through a application server
api would have to use 3 (e.g. xml configuration file, html form).
2b) ds.setSecurityMechanism(3);
3a) Setting the JDBC attribute in a Java program could use the
constant, e.g. properties.setProperty("securityMechanism",
Integer.toString(ClientDataSource.STRONG_PASSWORD_SUBSTITUTE_SECURITY));
Dan.
