1

JRE Version:1.8.0_191-b12 Tomcat version: 9.0.13 Windows 10

I have a large WAR file (300MB) several hundred of files, classes, struts actions etc.

When I start Tomcat 9.0.13 from a Windows Service I get the following error when I try to access the application via a URL:

21-Nov-2018 12:49:42.544 SEVERE [http-nio-9090-exec-1] org.apache.catalina.core.StandardHostValve.invoke Exception Processing /workflow/
 java.lang.SecurityException: AuthConfigFactory error: java.lang.reflect.InvocationTargetException
    at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:85)
    at org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1239)
    at org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1232)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
    at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:791)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1417)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:76)
    at javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:67)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:66)
    ... 17 more
Caused by: java.lang.SecurityException: org.xml.sax.SAXNotRecognizedException: Feature: http://apache.org/xml/features/allow-java-encodings
    at org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:65)
    at org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations(AuthConfigFactoryImpl.java:345)
    at org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.<init>(AuthConfigFactoryImpl.java:68)
    ... 25 more
Caused by: org.xml.sax.SAXNotRecognizedException: Feature: http://apache.org/xml/features/allow-java-encodings
    at org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213)
    at org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143)
    at org.apache.crimson.jaxp.SAXParserImpl.<init>(SAXParserImpl.java:126)
    at org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113)
    at org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141)
    at org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:505)
    at org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:61)
    ... 27 more

If I wait about 2 minutes, everything starts working correctly. Tomcat 8 used to give me a nice error page saying that the resource was not ready yet, but Tomcat 9 however just shows this stack trace.

Is there any way to have tomcat 9 do the same? Return a nicely formatted error page if a specific context is not ready yet?

enter image description here

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
John Tkaczewski
  • 120
  • 1
  • 7
  • This sound similar https://stackoverflow.com/questions/43944803/java-lang-securityexception-org-xml-sax-saxnotrecognizedexception-feature-htt – Peng Tuck Kwok Jan 04 '19 at 07:44
  • This is not related to the size of the WAR file. The solution outlined here: https://stackoverflow.com/questions/43944803/java-lang-securityexception-org-xml-sax-saxnotrecognizedexception-feature-htt does fix the problem. However I need to find a solution that will not require any changes to Tomcat Configuration. I can makechanges to my WAR file but not to Tomcat. – John Tkaczewski Jan 28 '19 at 21:15
  • It looks like if I remove the folder webapps/ROOT from Tomcat and I don't implement the chnages in https://stackoverflow.com/questions/43944803/java-lang-securityexception-org-xml-sax-saxnotrecognizedexception-feature-htt Tomcat will never start correctly. However if I leave the ROOT application and access it at-least once before I access my application everything seems to start working as expected. So my question is how to do this without making any changes to Tomcat config. – John Tkaczewski Jan 28 '19 at 21:19
  • So based your test it is not size related. Can you check if xerces-impl and xerces are compatible versions being used (with each other)? Based on one answer this could be your issue. https://stackoverflow.com/questions/23952888/solution-for-secure-processing-org-xml-sax-saxnotrecognizedexception-causing-jav – Peng Tuck Kwok Jan 29 '19 at 05:24
  • I tried putting the latest xerces libs, I also found some older libraries that could be causing the issue, sax.jar and crimson.jar, I searched all my jar files for any xml / sax relevance but couldn't find anything. I even removed all the relevant jar files to SAX/XML knowing that it will break my app but I wanted to get to the point where Tomcat startup was clean. To no avail. – John Tkaczewski Feb 05 '19 at 00:55

2 Answers2

0

The trigger for this issue is shipping an old XML parser (like Crimson) in the web application. While this was sometimes required with very old versions of Java, with any remotely recent version (I'm thinking at least the last 5 years or so - possibly as far back as the last as 15 years or so) this should not be necessary.

The root cause is that Tomcat's JASPIC implementation assumes that the allow-java-encodings feature is always available. Now this issue has (finally) been brought to the attention of the Tomcat committers we'll get Tomcat fixed so it no longer makes this assumption. Fixes will be in the releases from September 2021 onwards.

Mark Thomas
  • 887
  • 5
  • 8
0

This is an old issue with the Tomcat deploy problem with large war files.

https://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html#Deploying_on_a_running_Tomcat_server

There are two ways of deploying an application: 1. Use the manager application, which it is absolutely a discourageable option (web form usually timeouts requests and exceeds size quotas).

  1. Copy the war file into $CATALINA_HOME/webapps directory.

The second option is the prefered options alwawys.

However with large files this have also an issue:

Copying a large file takes some time, and what deploy daemon does is to try to unzip a large war file before its is properly copied. This is something that can be avoid by moving the large war file instead of coping it:

// Instead of copy:
cp /tmp/mylarge-warfile.war $CATALINA_HOME/webapps/

// Simply move the war file to deploy dir:
mv /tmp/mylarge-warfile.war $CATALINA_HOME/webapps/