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
>
>
|