David W. Van Couvering wrote:
In my ongoing investigation, it has become quickly obvious to me that
the various DataSource implementations we have must be serializeable so
they can be stored in a JNDI repository.
An excerpt from the javax.naming Description javadoc:
------------
References
Objects are stored in naming and directory services in different ways.
If an object store supports storing Java objects, it might support
storing an object in its serialized form. However, some naming and
directory services do not support the storing of Java objects.
Furthermore, for some objects in the directory, Java programs are but
one group of applications that access them. In this case, a serialized
Java object might not be the most appropriate representation. JNDI
defines a reference, represented by the Reference class, which contains
information on how to construct a copy of the object. JNDI will attempt
to turn references looked up from the directory into the Java objects
they represent, so that JNDI clients have the illusion that what is
stored in the directory are Java objects.
------------
So, instead of trying to store a serialized java object, with all its
inner gory details, I think it is better to let DataSource objects
implement javax.naming.Referenceable and only store a Reference
containing the required information for a JNDI client to create a
DataSource object based on the information in the Reference. I think
it's going to be easier to handle version skew using this rather than
relying on serialization, you'll have more control. The logic you write
for creating a DataSource object based on the information in a JDNC
repository is independent of any internal fields you may have deleted
from the class, etc.
This means that they must maintain a strict level of compatibility so
that there are not serialization errors if the version of the class
stored in the JNDI repository is older than the version of the class in
the classloader of the client.
From the comments of ClientDataSource:
- No deleting of fields
- No changing of non-static to static or non-transient to transient, as
this is equivalent to deleting fields
- No changing of field types within the class
- Cannot alter the position of the class in the class hierarchy
- Cannot change class name or package name
Also, it appears we are making every effort to keep the size of these
objects reasonably small as they will in all likelihood be serialized
over the network from the JNDI repository to the client.
Do I have that right?
Thanks,
David
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
