when I deploy my war file on tomcat it is ok but when I deploy it on glassfish it gives the exception, I searched but found no result how to solve this.
java.lang.ArrayIndexOutOfBoundsException: 9578
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
...............
[#|2018-10-07T15:19:22.345+0330|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=84;_ThreadName=Thread-2;|Exception while loading the app|#]
[#|2018-10-07T15:19:25.182+0330|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=84;_ThreadName=Thread-2;|Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'TestController' defined in file [E:\glassfish3-Reservation\glassfish3\glassfish\domains\domain1\applications\myproject\WEB-INF\classes\com\company\controller\TestController.class]: Instantiation of bean failed; nested exception is java.lang.ExceptionInInitializerError
Your best option is to update your Glassfish server if you can. Your version 3.1.2 is way too old, the current one is 5.0.
Another option would be to look for Lambda expressions in the TestController class and to remove or replace them with standard code.
This exception seems to occur when you are using Lambda expressions or newer Java bytecode with a version of asm.jar which is too old. This is related to your old version of Glassfish which comes bundled with Jersey 1.x which has bundled asm.jar 3.1. This version seems to be not fully compatible with Java8 or newer bytecode.
More related information:
Strange java.lang.ArrayIndexOutOfBoundsException thrown on jetty startup
Java 8 Lambda Expression Within REST Service not working
ArrayIndexOutOfBoundsException when using Java 8 language features
Related
I am getting this exception during tomcat start. I am using jdk1.8.0_152, apache-tomcat-8.5.24
I have been updating my elasticsearch from version 1.7 to 6.0. For that I had to include few new jars and had to update few existing to latest versions.(commons-io-2.6,lucene-core-7.0.1,log4j-api-2.9.1) After that I am getting this error on tomcat starting.
SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log
StandardWrapper.Throwable java.lang.ArrayIndexOutOfBoundsException:
41981 at org.objectweb.asm.ClassReader.(Unknown Source) at
org.objectweb.asm.ClassReader.(Unknown Source) at
org.objectweb.asm.ClassReader.(Unknown Source)
What version of asm do you use? According to this post https://github.com/joaoarthurbm/designwizard/issues/36:
asm-3.1 doesn't support lambdas expression available in JDK 8.
So you might be want to upgrade to asm 5.0.1 or higher.
My issue si very onclear, as i'm copying and pasting a project which works in liferay (a test portlet), i'm renaming the portlet in the various files needed and i'm trying to deploy it. It Throws a NullPointer and i cannot really see why. Below is the error:
GRAVE: Exception sending context destroyed event to listener instance of class com.liferay.portal.kernel.servlet.SecurePluginContextListener
java.lang.ExceptionInInitializerError
at com.liferay.portal.kernel.deploy.hot.HotDeployEvent.initDependentServletContextNames(HotDeployEvent.java:97)
at com.liferay.portal.kernel.deploy.hot.HotDeployEvent.<init>(HotDeployEvent.java:53)
at com.liferay.portal.kernel.servlet.PluginContextListener.fireUndeployEvent(PluginContextListener.java:170)
at com.liferay.portal.kernel.servlet.SecurePluginContextListener.fireUndeployEvent(SecurePluginContextListener.java:294)
at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalDestroy(PluginContextListener.java:132)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalDestroy(BasePortalLifecycle.java:31)
at com.liferay.portal.kernel.servlet.PluginContextListener.contextDestroyed(PluginContextListener.java:97)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:5063)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5723)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1028)
at org.apache.catalina.startup.HostConfig.undeploy(HostConfig.java:1547)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1453)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1695)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:333)
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.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1556)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at com.liferay.portal.kernel.util.PropsUtil.get(PropsUtil.java:32)
at com.liferay.portal.kernel.deploy.hot.DependencyManagementThreadLocal.<clinit>(DependencyManagementThreadLocal.java:40)
... 22 more
I'am deploying through the deploy directory of liferay's tomcat.
This is not a question about nullpointer exception but on portlet deployment in liferay.
It's likely a Portlet configuration prolem since you renamed the Portlet files. Can you give us the content of Portlet.xml and Liferay-portlet.xml please ?
I'm using JBoss 7.1.3 (built from sources) with Ubuntu 13.10 64 bits and open-jdk 7. And all the application works fine. Works fine with other developers using Windows and other Linux too (with java 7 from Oracle and OpenJDK).
Now I'm trying to start the application in another machine (a virtual machine with Redhat 6 - 64 bits with open-jdk 7)
Using extacly same jboss from other machine (zip the jboss folder and unzip in the new machine) and the application do not start anymore.
I tryed with a clean JBoss 7.1.3, 7.2.0 and even WildFly 8.1.0.CR1 but the error persists.
I also compile the application sources on the new machine, but the error persists.
Follow the error:
20:49:12,388 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."vendas-1.0.1-SNAPSHOT.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."vendas-1.0.1-SNAPSHOT.war".WeldService: com.google.common.collect.ComputationException: java.lang.reflect.MalformedParameterizedTypeException
at org.jboss.as.weld.services.WeldService.start(WeldService.java:83)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
Caused by: com.google.common.collect.ComputationException: java.lang.reflect.MalformedParameterizedTypeException
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:397)
at org.jboss.weld.resources.SharedObjectCache.getTypeClosure(SharedObjectCache.java:82)
at org.jboss.weld.resources.SharedObjectFacade.getTypeClosure(SharedObjectFacade.java:65)
at org.jboss.weld.introspector.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:52)
at org.jboss.weld.introspector.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:31)
at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:34)
at org.jboss.weld.introspector.jlr.AbstractWeldAnnotated.getTypeClosure(AbstractWeldAnnotated.java:193)
at org.jboss.weld.bean.AbstractBean.initTypes(AbstractBean.java:187)
at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:280)
at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:253)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:212)
at org.jboss.weld.bootstrap.BeanDeployer.createBeans(BeanDeployer.java:139)
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:204)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
... 5 more
Caused by: java.lang.reflect.MalformedParameterizedTypeException
at sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.validateConstructorArguments(ParameterizedTypeImpl.java:60) [rt.jar:1.7.0_55]
at sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.<init>(ParameterizedTypeImpl.java:53) [rt.jar:1.7.0_55]
at sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.make(ParameterizedTypeImpl.java:95) [rt.jar:1.7.0_55]
at sun.reflect.generics.factory.CoreReflectionFactory.makeParameterizedType(CoreReflectionFactory.java:105) [rt.jar:1.7.0_55]
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:140) [rt.jar:1.7.0_55]
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49) [rt.jar:1.7.0_55]
at sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:84) [rt.jar:1.7.0_55]
at java.lang.Class.getGenericSuperclass(Class.java:696) [rt.jar:1.7.0_55]
at org.jboss.weld.util.reflection.HierarchyDiscovery.discoverFromClass(HierarchyDiscovery.java:126)
at org.jboss.weld.util.reflection.HierarchyDiscovery.discoverTypes(HierarchyDiscovery.java:95)
at org.jboss.weld.util.reflection.HierarchyDiscovery.init(HierarchyDiscovery.java:74)
at org.jboss.weld.util.reflection.HierarchyDiscovery.getTypeClosure(HierarchyDiscovery.java:58)
at org.jboss.weld.resources.SharedObjectCache$4.apply(SharedObjectCache.java:58)
at org.jboss.weld.resources.SharedObjectCache$4.apply(SharedObjectCache.java:55)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
... 20 more
Is there any clue?
thanks
Have you tried changing your maven artifactId ?
That strangely solved my issue (while reinstalling jboss and restarting the PC didn't).
Had same issue with latest Payara 4.1 173 (I know, not JBoss/WildFly but it utilizes same WELD engine). I was able to fix this by doing the following:
re-install Payara's lib and modules directory (within glassfish directory)
make sure to keep mariadb*.sql in, else the JDBC resources won't work
purge ~/personal_domain/osgi-cache/
This is the place where JARs are being collected, maybe there is a similar place? If you downgrade e.g. javax.faces.jar from 2.3.2 (beta) to 2.2.14 (bundles with Payara) and you don't purge osgi-cache, you still have 2.3.2 and not 2.2.14 because it is being loaded from osgi-cache. Upgrading such JARs works fine, not downgrading.
Again, I know it is not WildFly/JBoss, but this did solve my issue.
I thought this might be worthing it because that same exception drove me crazy here. I also added a new logger org.jboss.weld with FINEST as log-level and saw that it successfully parsed the annotations and still the exception came. I also tried to remove public constructors from all converters and validators but no avail. Only until I did the mentioned above steps, I was able to recover Payara.
Following is the timeline of how i got error in my application
Used Spring 2.5.3 and tomcat 7.0.27 - No Error
Upgraded to Spring 3.1.1 with same tomcat (7.0.27) - No Error
Upgraded tomcat to 7.0.42, used with Spring 3.1.1 - VerifyError
When i stop my application, i get 1000 verifyerrors (seperate error for every destroyBean) when i upgraded to tomcat 7.0.42.
Following is the Stack Trace:
java.lang.VerifyError: (class: org/springframework/orm/jpa/EntityManagerFactoryUtils, method: convertJpaAccessExceptionIfPossible signature: (Ljava/lang/RuntimeException;)Lorg/springframework/dao/DataAccessException;) Wrong return type in function
at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessBeforeDestruction(PersistenceAnnotationBeanPostProcessor.java:357)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:193)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:498)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:509)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:442)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1066)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1040)
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:988)
at org.springframework.web.context.ContextLoader.closeWebApplicationContext(ContextLoader.java:556)
at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:142)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4980)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5626)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Possible Cause:
fixed EntityManagerFactoryUtils's "convertJpaAccessException" to always return rather than throw DataAccessExceptions
This line is in ChangeLog of Spring 2.5.6
But my application works fine with Spring 3.1.1 and tomcat 7.0.27 but throws this error when upgraded to tomcat 7.0.42
AFAIK, Tomcat doesn't depend on Spring, and Spring doesn't depend on Tomcat. Not in any version of either.
I suspect that in the intermediate version of your application after "upgrade to Spring 3.1.1 with same tomcat (7.0.27)", you either didn't trigger that code to be run. Note that it is happening in code that is run when a webapp is shut. If you never attempted a clean shutdown in the intermediate version of your application, that postProcessBeanBeforeDestruction method wouldn't be called on that bean, and the problem wouldn't arise.
My guess is that the real problem is caused by mixing versions of Spring JAR files.
I try to deploy a war into Tomcat 7.0.29. I'm having the following log stack :
GRAVE: Error waiting for multi-thread deployment of context descriptors to complete
java.util.concurrent.ExecutionException: java.lang.StackOverflowError
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:574)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1413)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:346)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1140)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:785)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.StackOverflowError
at java.util.HashSet.<init>(HashSet.java:86)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2208)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
(Many stack frames ommited...)
Does anybody face the same problem ?
This is reported upstream as issue #53871 in Tomcat. The problem appears to be with annotation scanning, and Tomcat 7.0.38 includes a clearer error message.
From the bug report:
Due to dependency management problems I deployed a WAR file containing two JAR files containing different versions of a library, where version 1 contained a class A which inherited from B and another version 2 which contained a class B inheriting from A.
The classes were loaded in such an order that A and B cyclically inherited from each other which leads to a stack overflow in populateSCIsForCacheEntry because it does not detect cycles in the inheritance tree.
This was exactly the problem in my case: an old version of dom4j bundled an incompatible version of jaxen. The new error diagnostic in 7.0.38 showed exactly which classes formed a loop and I fixed it by upgrading those dependencies.
I'm also encountering this issue in Tomcat 7.0.29 and Tomcat 7.0.30. However with Tomcat 7.0.28 everything works fine, so I suspect it's Tomcat issue, that was recently introduced.
The error encountered in 7.0.29 and 7.0.30, when starting Tomcat and deploying a war file:
14:01:06,380 ERROR [HostConfig:576] Error waiting for multi-thread deployment of context descriptors to complete java.util.concurrent.ExecutionException: java.lang.StackOverflowError
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:574)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1413)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:346)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1140)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:785)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.StackOverflowError
at java.util.HashSet.<init>(HashSet.java:103)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2243)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2260)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2260)
For me this behavior reproduced in IntelliJ Idea when I set the Application Context to the same name as the the Maven atrifactId in the .pom file.
E.g. my artifactId is 'test', then I set the Application Context (Edit configuration -> Tomcat Server -> Deployment, select the exploded artifact) to '/test'. As soon as I changed the Application Context, everything worked.
I had the same problem. I think it was caused by Tomcat 7, so when I changed to Tomcat 6.0.35, the problem resolved itself like a charm.
Use a lower version of Tomcat. There are problems with the version of Tomcat you are using.
A workaround : I changed the name of the WAR (no finalName in pom.xml and changed the artifact version) and it worked .... why? I don't know till now!
A real and a genuine solution? Definitely a new Tomcat Release . . .