David W. Van Couvering wrote: > This is correct, except I think limiting it to "classpath" may cause > confusion in some environments. See for example Bryan's struggles > because he had a Derby jar file in $JAVA_HOME/lib/ext, which takes > precedence over the classpath. > > You might say something more general like "ensuring that the higher > revision level jar is first in the order that classes are loaded (e.g. > by placing it first in the classpath) will make the functionality and > bugfixes from the higher revision level available" > good point
> Also, it's possible that the higher revision functionality is still > visible *if* it's from a package that doesn't exist in the older > revision of the common code. Since most users are not really up on what classes exist in the Derby implementation, I just punted with "may not be available" as in don't bank on it. > Also, you don't talk about upgrade scenarios, where the bugfix is > there, but then someone upgrades and all of a sudden the bugfix is gone. Yes, that one is a bit scary and worthwhile making people aware that it might happen, but assuming this change is approved, it mostly seems to me I need to get folks focused on the immediate workaround which is to get the highest rev jar loaded first, and hopefully make headway on the long term application isolation education issue which as Rick mentioned is already an issue (albeit a less mysterious one) for multiple embedded applications/components running in the same JVM. But first I better educate myself on class loaders, which apparently won't be a small task. http://mail-archives.apache.org/mod_mbox/www-women/200510.mbox/[EMAIL PROTECTED] Thanks for updating the user impact on the Wiki page http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines. I think the description of user impact, while less attractive is much more accurate now and I can believe it. Kathey
