1) I don't belive Spring reports anywhere constraints of deployment in the shared locations. If this is the case, it would be fine. There's no class loader problems using it in such configurations. I don't have a problem deploying it with applications for Tomcat installation, and actually do deploy it this way. But in this case I'm not using a standard way of deploying just b/c of problems with logging.
Problems that sharing libs can cause:
Class loader problems - you found this one
Independance - what if you want to deploy two instances of your app - one with spring 1.2 and one with 2.0?
Maintenance - like independance (above), good luck upgrading shared libs. I've had multiple apps deployed on the same servers that *required* different lib versions
2) While there're certainly problems with shared deployments, but the same is true with in-war deployments as well. Otherwise, managing dependencies from war deployment to shared lib deployment is not a huge problem, and probably is done for at least one library in the system.
3) Finally, the same issues related to Tomcat applications/shared hold for application server deployments, where you might be forced to deploy Spring outside of WAR files. The same problems will appear here.
In either case, JCL requirements to avoid static logs doesn't seem to be too harsh. But that would ensure appropriate work of the library in any environment.
Dimitry E Voytenko