db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Client data source, propertyKey_XXX fields
Date Wed, 06 Jul 2005 00:33:58 GMT
The client data source code (ClientBaseDataSource) has variables like these:

public final static String propertyKey_databaseName = "databaseName";
public final static String propertyKey_securityMechanism =
"securityMechanism";

These are used by the class to create a Reference from a DataSource and
to create a DataSource from a reference.

The name of such a property provides mapping to the name of an instance
 field within the client data source, using substring(12), e.g.
'databaseName'.

The value of such a property provides a key name to use in the Reference
object, for the StringRefAddr object.

It may be the the instance field name and the key name are always the same.


The code (ClientBaseDataSource.getReference) to create a reference uses
reflection to obtain a list of such static final fields (propertyKey_*),
and then obtains the value of the instance field and its key and adds it
to the Reference as a StringRefAddr. If either the static final
propertyKey_ is transient or the instance field is transient then the
value is not added to the Reference.

The code (ClientBaseDataSource.hydrateFromReference) to create a data
source from the Reference uses similar logic, using reflection to loop
through all the static fields (property_key*) and drive the setting of
the values from the values stored in the Reference.


These static final variables (property_key*) are also used to obtain a
Properties object that contains keys being the keys used for
StringRefAddr and the values being a String representation of the value
of the corresponding instance field. Again reflection is used to drive
the contents, from the list of property_key values.
This properties object is only used for tracing.

So this leads me to a question, what is the benefit of these static
final fields (propertyKey_*) and the complexity (reflection) they
introduce? In addition, use of reflection means the fields need to be
pubic, thus forcing them into the javadoc for this class, when they are
not meant to be part of the public api.

Wouldn't a list (array) of Java bean property names fulfill the same
functionality, in a much clearer way?

I could understand the use of reflection if the list was created
automatically, by say looking for public setXXX methods, but adding a
DataSource property into the Reference requires the manual step of
creating a propertyKey_XXX field, so this would be comparable to adding
an entry to a list.

In addition it doesn't seem  (from Raman's code coverage numbers) that
this code is currently tested. I'll add tests for creating a Reference
out of a DataSource object (and the other way) for client and embedded
if that is also not tested.

Dan.




Mime
View raw message