Hey Dan,
I'm going to hold off on this until you get back. It would be nice to
work out a code-sharing model soon. My particular issue here is that I
want to add some new constants to the network layer and it seems brittle
to me to have to make identical edits in two sets of files.
Cheers,
-Rick
David Van Couvering wrote:
You go, Rick! I think the edge case is going to bite you, though. I
don't think you can wave your hands and say customers can just write a
classloader to fix the problem.
If I remember correctly, the motivation for the edge case was to allow
different versions of the network driver and embedded driver running
next to each other.
I think this was motivated by some IBM customers. My questoin is: is
the real motivation for compatibility between client and server? If
so, it seems to me that what you really want is for a new version of
the network client driver to be backward compatible with an older
version of the server running elsewhere, or, vice-versa, a newer
version of the server to be backward compatible with an older version
of the client. This was managed at Sybase with the TDS protocol using
a handshake at login time where the client and server agree at what
version of the protocol to run at. Perhaps this is what we want to do
here.
If the motivation was something else, I'd like to understand it
better. Dan D. was the main person who brought this up. Is Dan back
yet?
Thanks,
David
Rick Hillegas wrote:
When we last visited this issue (July 2005 thread named "Size of
common jar file"), we decided not to do anything until we had to.
Well, I would like to start writing/refactoring some small chunks of
network code for sharing by the client and server. My naive approach
would be to do the following.
o Create a new fork in the source code: java/common. This would be
parallel to java/client and java/server.
o This fork of the tree would hold sources in these packages:
org.apache.derby.common...
o The build would compile this fork into
classes/org/apache/derby/common/...
o The jar-building targets would be smart enough to include these
classes in derby.jar, derbyclient.jar, and derbytools.jar.
As I recall, there was an edge case: including a derby.jar from one
release and a derbyclient.jar from another release in the same VM. I
think that a customer should expect problems if they mix and match
jar files from different releases put out by a vendor. It's an old
deficiency in the CLASSPATH model. With judicious use of
ClassLoaders, I think customers can hack around this edge case.
I welcome your feedback.
Cheers,
-Rick
