You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2005/11/09 20:11:55 UTC
PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Here is the proposed text of the vote describing the approach and impact
of sharing code that would come along with the contribution that I would
be submitting for a vote. Your comments and refinements are requested
now, so that when it comes time for a vote we can avoid a debate on the
wording and just have the vote.
Thanks,
David
=========
This contribution provides a framework to allow code sharing across the
Derby product jars. Sharing code provides many important benefits, such as
- Avoiding code (and bug) duplication (e.g. no cut-and-paste)
- Improving Derby developer productivity
- Ensuring consistency/compatibility between client and server
- Providing a clear repository for code that is usable across Derby
jar files
This framework will not have any significant impact on jar file size or
otherwise affect product distribution or usage.
This contribution provides mechanisms and guidelines, such as guidelines
and tools for supporting forward and backward compatibility, to help
ensure that Derby jars with different versions can be loaded in a Java
VM without having to use specialized classloaders. If an
incompatibility exists between versions, it will be clearly documented.
Any undocumented incompatibilities will be treated as a bug.
However, not all issues can be resolved. For example it is possible for
"shadowing" to take place if there are different versions of network
client and embedded client in the same VM, and each provides a different
implementation of the same common method.
The detailed guidelines for how to provide code sharing to meet these
goals, and what issues may arise, are provided in the package.html for
org.apache.derby.common (as part of this contribution).
Although not included in this initial contribution, we will need to
provide mechanisms to help track down and resolve mixed version issues.
Possible mechanisms include:
- upgrade sysinfo to use the current classloader rather than the
classpath to determine version information
- to print a warning if multiple versions of Derby are detected
within the same classloader context.
- update documentation to warn users about these potential issues and
how they can be resolved (by either changing the order in which Derby
jars are loaded or through using specialized classloaders that isolate
Derby versions from each other).
- example code showing how to use classloaders to isolate versions of
Derby within the same VM
=====
David
Kathey Marsden wrote:
> David Van Couvering (JIRA) wrote:
>
>
>> [ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
>>
>>David Van Couvering updated DERBY-289:
>>--------------------------------------
>>
>> Attachment: DERBY-289.diff
>>
>>Hi, all. Here is the proposed patch that provides the framework for code sharing. I was thinking folks could look at it and discuss, and then once issues have (hopefully) been worked out, we can have a vote.
>>
>>
>>
>
> Thanks David for the patch. What will the wording in the vote describing
> the new restrictions on mixing client and server versions in the same
> JVM and the new classpath ordering requirements be? Having the wording
> now will help provide context in reviewing the patch.
>
>
> Kathey
>
>
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> Great. I have to say your part about how this "will translate into
> SQL and JDBC compatibility with the masking issues going on" has me a
> bit stumped -- can you explain in some more detail?
Let me play with it a bit before we get into more discussion, but
basically what I am thinking about is things like:
DERBY - 396 - In expanding functionality for ALTER STATEMENT , in a
mixed jar environment the existing 10.1 syntax should still work even
if some of the changes for the enhancement are in shared classes.
I updated the Wiki page to include your new wording under Mixed Version
Support. I think it is a clear description of the product behaviour
that users and developers can understand before trying to understand
the underlying implementation.
Thanks
Kathey
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Great. I have to say your part about how this "will translate into SQL
and JDBC compatibility with the masking issues going on" has me a bit
stumped -- can you explain in some more detail?
Thanks,
David
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>So, how about
>>
>>"Older versions of Derby jars will get their expected behavior in a
>>mixed version environment regardless of jar ordering. Newer versions
>>of Derby jars will get new behavior if the newer jar files are loaded
>>first, and older behavior if the older jar files are loaded first.
>
>
> I like the sound of it! Now that I know for sure that is what we are
> promising users, next week I'll try some stuff out with the patch and
> try to understand how maintaining the internal API backward/forward
> compatibility will translate into SQL and JDBC compatibility with the
> masking issues going on.
>
> Kathey
>
>
>
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
>
> So, how about
>
> "Older versions of Derby jars will get their expected behavior in a
> mixed version environment regardless of jar ordering. Newer versions
> of Derby jars will get new behavior if the newer jar files are loaded
> first, and older behavior if the older jar files are loaded first.
I like the sound of it! Now that I know for sure that is what we are
promising users, next week I'll try some stuff out with the patch and
try to understand how maintaining the internal API backward/forward
compatibility will translate into SQL and JDBC compatibility with the
masking issues going on.
Kathey
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Yes that's right. In general things should still work, even if they
don't work in the "new way." We should never have an *accidental*
situation where something just doesn't work (e.g. MethodNotFound or
whatever the exception is). It may be that we are forced to introduce
functionality that is not forward-compatible, but that is to be avoided.
So, how about
"Older versions of Derby jars will get their expected behavior in a
mixed version environment regardless of jar ordering. Newer versions
of Derby jars will get new behavior if the newer jar files are loaded
first, and older behavior if the older jar files are loaded first.
There should never be an where Derby can not find the common code it
needs due to mixed versions. Such incompatibilities should be avoided
as much as possible, and where they are unavoidable, should be
documented and introduced only as part of a major release. Any
unexpected and undocumented incompatibilities should be treated as a bug."
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>Yes, that's correct, that's the intent of the forward-compatibility
>>guidelines and mechanisms.
>>
>>I could add this text:
>>
>>"Older versions of Derby jars will get their expected behavior in a
>>mixed version environment regardless of jar ordering. Newer versions
>>of Derby jars will get their expected behavior as long as the newer
>>jar files are loaded first."
>
>
> But it is also important that the newer jars still work at the lower
> revision level even if they are not loaded first. Will that be the case ?
> For instance if I have a 10.2 client and a 10.3 server with the client
> loaded first, all of the 10.2 functionality even if it uses shared code
> should still work for the server. We always need to at least negotiate
> down to the lower level and I don't think your sentence says that.
>
>
>
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> Yes, that's correct, that's the intent of the forward-compatibility
> guidelines and mechanisms.
>
> I could add this text:
>
> "Older versions of Derby jars will get their expected behavior in a
> mixed version environment regardless of jar ordering. Newer versions
> of Derby jars will get their expected behavior as long as the newer
> jar files are loaded first."
But it is also important that the newer jars still work at the lower
revision level even if they are not loaded first. Will that be the case ?
For instance if I have a 10.2 client and a 10.3 server with the client
loaded first, all of the 10.2 functionality even if it uses shared code
should still work for the server. We always need to at least negotiate
down to the lower level and I don't think your sentence says that.
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Yes, that's correct, that's the intent of the forward-compatibility
guidelines and mechanisms.
I could add this text:
"Older versions of Derby jars will get their expected behavior in a
mixed version environment regardless of jar ordering. Newer versions of
Derby jars will get their expected behavior as long as the newer jar
files are loaded first."
David
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>This contribution provides mechanisms and guidelines, such as
>>guidelines and tools for supporting forward and backward
>>compatibility, to help ensure that Derby jars with different versions
>>can be loaded in a Java VM without having to use specialized
>>classloaders. If an incompatibility exists between versions, it will
>>be clearly documented. Any undocumented incompatibilities will be
>>treated as a bug.
>>
>>However, not all issues can be resolved. For example it is possible
>>for "shadowing" to take place if there are different versions of
>>network client and embedded client in the same VM, and each provides a
>>different implementation of the same common method.
>>
>
> I think that it would be good to communicate that in such cases
> regardless of the order the jars are loaded, functionality will not be
> affected at the lower revision level for either the embedded or client
> jar. The higher revision behaviour can be used if the higher revision
> jar is loaded first.
>
> Is that true? And if so can we include it in the vote?
>
> For instance if I have a 10.2 derbyclient.jar and a 10.3 derby.jar in
> the same JVM, everything should work ok at the 10.2 level regardless
> of class loading order, but If I put derby.jar first, the embedded
> application should be be able to function at the 10.3 level and the
> client at the 10.2 level.
>
>
> Thanks
>
>
>
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> This contribution provides mechanisms and guidelines, such as
> guidelines and tools for supporting forward and backward
> compatibility, to help ensure that Derby jars with different versions
> can be loaded in a Java VM without having to use specialized
> classloaders. If an incompatibility exists between versions, it will
> be clearly documented. Any undocumented incompatibilities will be
> treated as a bug.
>
> However, not all issues can be resolved. For example it is possible
> for "shadowing" to take place if there are different versions of
> network client and embedded client in the same VM, and each provides a
> different implementation of the same common method.
>
I think that it would be good to communicate that in such cases
regardless of the order the jars are loaded, functionality will not be
affected at the lower revision level for either the embedded or client
jar. The higher revision behaviour can be used if the higher revision
jar is loaded first.
Is that true? And if so can we include it in the vote?
For instance if I have a 10.2 derbyclient.jar and a 10.3 derby.jar in
the same JVM, everything should work ok at the 10.2 level regardless
of class loading order, but If I put derby.jar first, the embedded
application should be be able to function at the 10.3 level and the
client at the 10.2 level.
Thanks
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Oh, great! I remember you complaining about this, but I didn't know
your patch addressed this -- for some reason I thought it was a
completely unrelated problem.
I'll try to take a look at this.
David
Bryan Pendleton wrote:
>> Although not included in this initial contribution, we will need to
>> provide mechanisms to help track down and resolve mixed version
>> issues. Possible mechanisms include:
>>
>> - upgrade sysinfo to use the current classloader rather than the
>> classpath to determine version information
>
> ...
>
> I just wanted to note that I submitted a proposed patch for DERBY-668
> earlier this week which does exactly this, albeit only for the db2jcc
> driver. I think this technique can be used throughout sysinfo to
> accomplish your goal.
>
> http://issues.apache.org/jira/browse/DERBY-668
>
> I'd be interested to hear from anyone who has time to review the patch.
>
> thanks,
>
> bryan
>
Re: PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> Although not included in this initial contribution, we will need to
> provide mechanisms to help track down and resolve mixed version issues.
> Possible mechanisms include:
>
> - upgrade sysinfo to use the current classloader rather than the
> classpath to determine version information
...
I just wanted to note that I submitted a proposed patch for DERBY-668
earlier this week which does exactly this, albeit only for the db2jcc
driver. I think this technique can be used throughout sysinfo to
accomplish your goal.
http://issues.apache.org/jira/browse/DERBY-668
I'd be interested to hear from anyone who has time to review the patch.
thanks,
bryan