0

Im getting desperate here. I'm able to start my webApp on tomcat7 server locally but when I add a jar that in the pom.xml (Its a module needed to my WebApp) , I get this error and the server won't start:

SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/densite-simulator-WebApp]]
    at java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.util.concurrent.FutureTask.get(FutureTask.java:192)
    at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1122)
    at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:819)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1574)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1564)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/densite-simulator-WebApp]]
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
    ... 6 more
Caused by: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
    at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:284)
    at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:238)
    at java.util.jar.JarVerifier.processEntry(JarVerifier.java:273)
    at java.util.jar.JarVerifier.update(JarVerifier.java:228)
    at java.util.jar.JarFile.initializeVerifier(JarFile.java:383)
    at java.util.jar.JarFile.getInputStream(JarFile.java:450)
    at org.apache.tomcat.util.scan.FileUrlJar.getEntryInputStream(FileUrlJar.java:97)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1964)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1931)
    at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1916)
    at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1330)
    at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:889)
    at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:386)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
    at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5419)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
Jaythaking
  • 2,200
  • 4
  • 25
  • 67
  • Which jar do you want to include? Is it third party or your own? And how do you include it? Please add your pom.xml or a snippet to your question. – Lars Gendner Aug 27 '15 at 10:29

2 Answers2

2

This drove me crazy today. At the end I found out the a dependency to org.bouncycastle libraries where causing this, out of the blue, after it worked unchanged for several months- removing 

'org.bouncycastle:bcprov-jdk16:1.45'

and

'org.bouncycastle:bcpg-jdk16:1.46'

from the dependencies fixed the issue for me.

Andreas Weber
  • 31
  • 2
0

I ran into this exact same issue today. My application has a dependency on Bouncy Castle, and Tomcat was throwing this exact exception when attempting to initialize the servlet.

In my case, I was deploying the bouncy castle JAR file as is into Tomcat (without exploding it into a fat JAR). However, in our build process, we had a plugin that made our builds reproducible (with each build generating the same hash if the source was unchanged). This same plugin was altering the bouncy castle JAR (to strip some time dependent information that would cause the JAR's hash to change between builds), thus causing the error.

While this may not be your exact problem, I hope this helps. The root cause of this error is that something is modifying the bouncy castle signed JAR file, thus causing the signatures to no longer match. Take a look at your build process and check if something might be modifying the JAR files before deploying them (e.g. packaging everything as a fat JAR).

Daniel
  • 383
  • 3
  • 13