It's very bad practice to include driver jars in webapps, and this is one reason why. What you are seeing is the kind of stuff that happens when some classes are being loaded from one location and some are loaded from another, resulting in an unholy mishmash where two or more discrete versions of a single class are in play, and which one a given function will end up with is more a game of roulette than anything else.
Unlike a certain other platform I could mention, both
Java and the open-source databases take a lot of care in maintaining version inter-compatibility, although I can mention one notable offender at the binary (non-JDBC) client level. It's not MySQL, however, so that's not your problem. So in most cases, the problem would be cured by simply removing the MySQL driver from the WAR entirely.
From what you're saying, however, I understand that the newer MySQL driver does
not function properly for this particular webapp. Perhaps, in part since it apparently wasn't designed according to best practices to begin with. Tomcat's class-loading rules are very explicit, so in normal cases, the WAR driver classes should take precedence within the webapp, regardelss of what other apps or the Realm are doing. However, if the webapp itself isn't well-designed, it may be making reference to resources outside of its expected boundaries.
Bottom line. Although people like to say "if it ain't broke, don't fix it", this is a naive thing to say in IT, where things get far more often broken from the outside in than vice versa. It's probably about time for that 150,000 mile overhaul on the offending webapp.