On 2/27/06, Kathey Marsden <[EMAIL PROTECTED]> wrote: > > So from what I understand, your patch for DERBY-1063 will reintroduce > the DERBY-1045 regression that derbytools will load a different > derbyclient.jar than the one specificed by the user CLASSPATH but will > improve the sysinfo output . Is that correct?
First, let me say that I think that the sysinfo change could probably stand on its own, in light of DERBY-668, although I made it with the goal of resolving DERBY-1063 in mind. With the sysinfo change, there is less chance of shadowing in general with sysinfo. Any classes available to sysinfo will be displayed, first, followed by any non-duplicated jars found to contain Derby classes. The answer to your question is yes, though, but DERBY-1045 is a specific regression that occurs if: * derbytools.jar, from 10.2 - with my patch for DERBY-1063 - is on the classpath before some other version of derbyclient.jar, and the new derbytools.jar resides in the same directory as derby.jar or derbyclient.jar from 10.2 and: * a previous version of derby.jar or derbyclient.jar is on the classpath, but after derbytools.jar + DERBY-1063. but not if: * derbytools.jar from 10.2 (or, perhaps, later) is not on the classpath * derbytools.jar from 10.2 appears later in the classpath than a previous version of derbyclient.jar * derbytools.jar is not in the same location as derby.jar or derbyclient.jar The question arises: How often is this likely to occur? Is this a typical use of Derby? It's interesting that the testing brought DERBY-1045 to light, but that's because the test just puts all the jars in the classpath. I'm wondering how typical it is to have multiple versions of Derby on the classpath (not necessarily loaded via classloaders). It would seem to me that having multiple versions of Derby (or, at least different major/minor versions of the same jar file) on the classpath would never be guaranteed to work. If there are two versions of the same jar on the classpath, it seems there would be no way to prevent NoSuchMethodExceptions or IncompatibleClassChangeErrors for classes that had methods removed or method signatures changed between versions, and that would apply to all internal classes, not just public api. Also note that it only affects jars loaded via the -jars option or via the classpath. The Class-Path attribute would have no affect on classes loaded via a custom classloader or in an environment where custom classloaders are used to partition resources, such as in a J2EE environment. > I am really very uncomfortable with anything that requires > CLASSPATH ordering or causes one derby installation to affect > another, but I'll think about it some more. And this is a valid concern, which I understand. I think the question here boils down to: in what situations would a third party ship derbytools.jar, and include it on the classpath with a previous version of derbyclient.jar? Is that a good practice anyway? I don't have an immediate answer to either of those questions, although my instict is to say "no" to the second one. > I'd like to hear what others think. Meanwhile could you say how > this would be documented. Maybe that would better help me to understand > the impact. It should be documented in the Tools and Utilities guide, demonstrating the optional syntax for executing the tools, as well as in Getting Started where appropriate. Also, it seems like, based on this and other issues and your proposal for an 'application impact' checkbox in JIRA, that a section in the Release Notes, or perhaps even a separate document, that covers all potential application-visible changes is called for. Perhaps as a part of a larger document about upgrading from previous versions to 10.2. If you have other suggestions for how to document the change, I would like to hear them. andrew
