db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: sharing code between the client and server
Date Wed, 17 Aug 2005 01:10:29 GMT
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
>
>


Mime
View raw message