https://bz.apache.org/bugzilla/show_bug.cgi?id=59226
--- Comment #12 from saschakarc...@gmx.de --- Just found an interesting problem: We're trying to migrate a bunch of webapps from tomcat 7 to 8.5.4 with the goal in mind not to change too much. Our Tomcat has got a whole bunch of 3rd party libraries in a separate folder which is loaded by the common (or shared) class loader (i.e. not in WEB-INF/lib). Since current version of StandardJarScanner now also follows the class-path in header in the JARs manifest.mf, it tries and fails to load all those additional JARS mentioned in the manifest. But we never hat these additional JARS in classpath and collecting them all is a bit of not so funny work although feasible. Don't get me wrong. I understand that following the class-path mentioned in the manifest.mf files is technically totally correct. But it somehow complicates migration of already existing apps. Wouldn't it be useful to have sort of "don't resolve class-path header" switch (with default FALSE) but giving the the option to do so? What do you guys thing? Or have I just missed an already existing workaround? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
