Rick Hillegas wrote: > Thanks, Kathey. I still don't understand the scenario you're > describing. It seems to me that application A never saw the bug fix at > all because the shared code was always shadowed by the version which > application B needed.
Because for 10.1 there is no shared code, the Application B 10.1 derby.jar and the Application A 10.2 derbyclient.jar were able to coexist totally independently. Upgrading Application B to 10.2 with the shared code caused the regression in Application A. It is a very subtle trap but very dramatic in its effect. > It's worth pointing out that this problem already exists today: > It is true that there are problems in this regard today with multiple embedded apps or multiple client apps. There is almost always a jar mixing issue in the support queue for jar conflicts and they are ugly. The one we are working on right now (with an older version of Cloudscape) is not just a matter of let's find all the duplicate jars we can and replace them, but includes necessary patches to some of the products involved. I personally am not keen on exacerbating the problem. That's perhaps just selfishness because I get to deal with it all the time, but I hope you can agree that the scope of user impact in the proposal is incorrect. It should be clear that we are regressing the ability to mix the client and server jars. Kathey
