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 16:30:09 GMT
Hi Satheesh,

I also am in favor of redundantly packaging these classes in the 
existing jar files and not creating a new jar file. Admittedly, this 
could use some more discussion. I agree with you that this simplifies 
setup for our users. I'm a big fan of simplifying the customer's first 
experience with Derby. I think it helps sell the technology.

Cheers,
-Rick

Satheesh Bandaram wrote:

>Dan is still on vacation and is expected next week, I think. We may be
>able to start sharing code by refactoring things like these, but we
>could still continue to package these classes in both JARs. This would
>allow us to not duplicate code, still keeping the same JARs. When this
>common code crosses a critical mass, may be we could revisit the idea of
>breaking into a common jar.
>
>Having another JAR makes setup more involved (for end users) and need to
>address multiple different version issues... but this would allow us to
>start sharing code now. Just a suggestion..
>
>Satheesh
>
>Rick Hillegas wrote:
>
>  
>
>>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