On 09/08/2021 19:21, James H. H. Lampert wrote:
On 8/6/21 9:17 AM, Konstantin Kolinko wrote:
Try to find what *.jar file in your system contains the above classes.
E.g. searching for string "crimson" in *.jar files.
That string will be visible in the archive file as it is a name of a
directory.
I've learned that QShell (a *nix-like shell that was added with Java
support) on an AS/400 does have both "find" and "grep," so it wasn't
quite so futile as I thought.
If I go into QShell, navigate to the JVM home directory, and do a
"find . -name '*.jar'"
I get
./jre/lib/ppc64/compressedrefs/jclSC180/vm.jar
./jre/lib/ppc64/default/jclSC180/vm.jar
./jre/lib/ext/db2_classes18.jar
./jre/lib/ext/CmpCrmf.jar
./jre/lib/ext/IBMSecureRandom.jar
./jre/lib/ext/cldrdata.jar
./jre/lib/ext/dnsns.jar
./jre/lib/ext/dtfj.jar
./jre/lib/ext/dtfjview.jar
./jre/lib/ext/gskikm.jar
./jre/lib/ext/healthcenter.jar
./jre/lib/ext/ibmcmsprovider.jar
./jre/lib/ext/ibmjcefips.jar
./jre/lib/ext/ibmjceplus.jar
./jre/lib/ext/ibmjceprovider.jar
./jre/lib/ext/ibmkeycert.jar
./jre/lib/ext/ibmpkcs11impl.jar
./jre/lib/ext/ibmsaslprovider.jar
./jre/lib/ext/ibmxmlcrypto.jar
./jre/lib/ext/ibmxmldsigprovider.jar
./jre/lib/ext/ibmxmlencprovider.jar
./jre/lib/ext/jaccess.jar
./jre/lib/ext/localedata.jar
./jre/lib/ext/nashorn.jar
./jre/lib/ext/traceformat.jar
./jre/lib/ext/xmlencfw.jar
./jre/lib/ext/zipfs.jar
./jre/lib/aggressive.jar
./jre/lib/charsets.jar
./jre/lib/dataaccess.jar
./jre/lib/ddr/j9ddr.jar
./jre/lib/deploy.jar
./jre/lib/ibmcertpathfw.jar
./jre/lib/ibmcertpathprovider.jar
./jre/lib/ibmcfw.jar
./jre/lib/ibmjcefw.jar
./jre/lib/ibmjgssfw.jar
./jre/lib/ibmjgssprovider.jar
./jre/lib/ibmjssefw.jar
./jre/lib/ibmjsseprovider2.jar
./jre/lib/ibmorb.jar
./jre/lib/ibmorbapi.jar
./jre/lib/ibmpkcs.jar
./jre/lib/ibmsaslfw.jar
./jre/lib/javaws.jar
./jre/lib/management-agent.jar
./jre/lib/math.jar
./jre/lib/plugin.jar
./jre/lib/resources.jar
./jre/lib/rt.jar
./jre/lib/se-service.jar
./jre/lib/security/US_export_policy_56bit.jar
./jre/lib/security/local_policy_56bit.jar
./jre/lib/security/policy/limited/US_export_policy.jar
./jre/lib/security/policy/limited/local_policy.jar
./jre/lib/security/policy/unlimited/US_export_policy.jar
./jre/lib/security/policy/unlimited/local_policy.jar
./jre/lib/tools/monitoring-api.jar
./jre/lib/xml.jar
./jre/lib/xmldsigfw.jar
./IBMmisc.jar
./lib/dt.jar
./lib/ibmorbtools.jar
./lib/jconsole.jar
./lib/tools.jar
./lib/IBMi5OSJSSE.jar
If I do a "find . -name '*crimson*'", I get nothing.
If I do a "find . -name '*.jar' -exec grep -l 'crimson' {} \;", I also
get nothing.
So unless anybody else has any ideas, I'm once again stuck, at least on
this angle.
Mark Thomas wrote:
Tomcat 7 doesn't have JASPIC support so you'll never see this issue in
Tomcat 7.
. . . to which I replied (seriously, rather than flippantly) "What's a
JASPIC?"
I've finally taken a look at what JASPIC is. Interesting. If it's JASPIC
support in Tomcat 8 that is throwing exceptions and killing manager
under this particular Java 8 JVM, is there a way to disable it, at least
until the customer has their PTFs up to date?
Sorry, no. The code in question is always going to get executed.
Future versions of Tomcat won't see this issue but if the customer is
prepared to update Tomcat to fix this issue then they might as well just
update Java (assuming that is indeed sufficient to fix this).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
