Ultimately, this will allow us to have references that point to multiple addresses (e.g. in a federated server)
Just some questions. Not educated enough in this area to comment yet #:)
Could you explain the federated scenario in more detail and how the
referenceable DataSource would come into play?
Some JNDI implementations support Java objects directly, so when you bind them in the actual object is stored in the directory usually by Serialization.
However, others don't. Instead a Reference gets stored which typically contains the information needed to reconstruct the object. JNDI uses an ObjectFactory associated with the Reference to convert it into the acutal Object.
A Reference typically stores the address of the target as a RefAddr, often as a StringRefAddr containing a URL as that makes it easier to understand when managing the directory.
It can actually store multiple RefAddrs indicating multiple places where the named resource can be found.
We are currently storing individual properties from the DataSource as RefAddr's in the reference. This works but IMO is an abuse of the system.
I would like to replace this with storing all the properties in a single RefAddr. This would ultimately allow us to store multiple addresses in the Reference which the object factory could use to create the actual DataSource instance.
A simple case would be where is used two different protocols depending on whether the client and server were on the same machine (e.g. shared memory based vs. TCP/IP based). Others would be where we had a clustered configuration and the reference contained the list of possible nodes to try. And so forth ...
Also my JS169 red flag went up when I saw "URL" and "Driver". I was wondering are there JSR169 implications in doing this?
All I meant was that the String stored in the reference should be of the same format as the String passed to the Driver. That should not cause any issues for JSR169.
-- Jeremy
