https://bz.apache.org/bugzilla/show_bug.cgi?id=57736
Frank Holler <frank.hol...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #2 from Frank Holler <frank.hol...@gmx.de> ---
Hi again,
i'm sorry to bother you again, but the slight difference between Tomcat 7 and
Tomcat 8 causes many support trouble for me. To use unpackWars="true" is a
problem for us. As you suggested, unpackWars="true" worked, but
unpackWars="false" seems to be broken with Tomcat 8.
So i digged a little deeper into the problem.
I found out that Tomcat 7 and Tomcat 8 both extract classes and libs from
WEB-INF to CATALINA_BASE/work/[app]/, even if unpackWars="false" is set.
The difference seems to be that Tomcat 7 delives resource or class loader
requests from the "work" direktory. So there is at least a file to open and all
things worked fine.
The javax.crypto.JarVerifier.verifySingleJar is happy and bouncycastle provider
gets registered.
With Tomcat 8 the things changed, so the classloader(?) returns an URI to the
relativ path within the war instead of the jar in "work". This causes
javax.crypto.JarVerifier.verifySingleJar to verify the WAR instead of the jar.
The same behavior seems to match for the resource loader, which delived a
relative path for our xsd stored within a jar.
As Tomcat 7 worked fine i assume that many other webapps would have the same
problem, if they running with unpackWars="false"
So i beg you, please take a look at this behavior change from Tomcat 7 to
Tomcat 8
Kind regards,
Frank
--
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
