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

  • This sound similar stackoverflow.com/questions/43944803/… – Peng Tuck Kwok Jan 4 at 7:44
  • This is not related to the size of the WAR file. The solution outlined here: stackoverflow.com/questions/43944803/… 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 at 21:15
  • It looks like if I remove the folder webapps/ROOT from Tomcat and I don't implement the chnages in stackoverflow.com/questions/43944803/… 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 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. stackoverflow.com/questions/23952888/… – Peng Tuck Kwok Jan 29 at 5: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 5 at 0:55

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


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/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.