db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: sharing code between the client and server
Date Wed, 17 Aug 2005 16:36:28 GMT
So I guess we are in agreement about having a "common" dir for the
client and server parts -  I'm also interested in seeing this
happening for some work am currently doing. As Satheesh mentioned we
would still package "common" classes in both jars for now...

--francois

On 8/17/05, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> 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