Hi Kathey,
Thanks for getting your users to agree to this change. I wonder if it
would be useful to add some more logic to sysinfo so that it will print
out a big warning if mixed Derby versions are found on the classpath. It
should be possible for sysinfo to do this: sysinfo already knows what
jars are on the classpath and ProductVersionHolder knows how to look up
the Derby version stored in org/apache/derby/info/*.properties. In some
cases this may save tech support some trouble.
Thanks,
-Rick
On 11/4/11 10:29 AM, Kathey Marsden wrote:
I promised some time ago to get back to the list regarding user input
on mixed jar version support in the same class-loader context from
consumers that have required this in the past.
The ones that I talked to are willing to give that up starting with
10.9. I think starting with 10.9 we should no longer support mixed
jars in the same classloader context and document that isolated
classloaders are required for mixed version jars in the same JVM.
Tasks in doing that I think would be:
1) Inform derby-user and see if there are any objections there.
2) DERBY-4689 - Provide a JUnit test option to isolate client from
server jars.
This will allow us to conduct mixed version protoocol testing
which is still important.
3) Put a blurb in the documentation about this.
Can anyone think of anything else or have any objections? I think
still this would not let us freely share code because of potential
sealing violations, but I am not sure of the issues there.
Thanks
Kathey
