sharing code between the client and server

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

sharing code between the client and server

Rick Hillegas-2
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
Reply | Threaded
Open this post in threaded view
|

Re: sharing code between the client and server

David Van Couvering
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


david.vancouvering.vcf (288 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sharing code between the client and server

Rick Hillegas-2
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: sharing code between the client and server

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

Reply | Threaded
Open this post in threaded view
|

Re: sharing code between the client and server

Rick Hillegas-2
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
>>>>        
>>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>  
>

Reply | Threaded
Open this post in threaded view
|

Re: sharing code between the client and server

francois.orsini
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 <[hidden email]> 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: sharing code between the client and server

Daniel John Debrunner
In reply to this post by Rick Hillegas-2
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.

So constants (Java static final fields) at least for primitive and
String types are already handled for shared code. Classes in the package
org.apache.derby.iapi.reference can be used by any code/jar file.This is
because the java compiler inlines such constants, so these classes
themselves are not included in any jar files.

Dan.