...my question is, with this configuration, do i need to "start" ehcache? if yes, how? it is a maze working though the libs dependencies, e.g. need hibernate-ehcache and ehcache? need hibernate-jcache? Here is the final error on tomcat 9 standard out after 3 days of debug:
... 93 common frames omitted
aused by: java.lang.IllegalStateException: Cache provider not started
at org.hibernate.cache.spi.AbstractRegionFactory.verifyStarted(AbstractRegionFactory.java:42)
at org.hibernate.cache.spi.support.RegionFactoryTemplate.buildTimestampsRegion(RegionFactoryTemplate.java:66)
at org.hibernate.cache.internal.EnabledCaching.<init>(EnabledCaching.java:80)
at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:33)
at org.hibernate.engine.spi.CacheInitiator.initiateService(CacheInitiator.java:24)
at org.hibernate.service.spi.SessionFactoryServiceInitiator.initiateService(SessionFactoryServiceInitiator.java:
0)
at org.hibernate.service.internal.SessionFactoryServiceRegistryImpl.initiateService(SessionFactoryServiceRegistr
Impl.java:68)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263
key config files:
ivy.xml (excerpt):
<dependency org="org.hibernate" name="hibernate-core" rev="5.3.0.Final">
</dependency>
<dependency org="org.hibernate" name="hibernate-jcache" rev="5.3.0.Final" />
<dependency org="org.hibernate" name="hibernate-ehcache"
rev="5.3.0.Final" />
<dependency org="org.springframework.boot" name="spring-boot-starter-cache"
rev="2.0.2.RELEASE" />
<dependency org="org.ehcache" name="ehcache" rev="3.5.2" />
<dependency org="org.springframework" name="spring-orm" rev="5.0.6.RELEASE" />
<dependency org="org.springframework" name="spring-core"
rev="5.0.6.RELEASE" />
Spring hibernateContext.xml (excerpt)
<property name="hibernateProperties">
<props>
<prop key="hibernate.c3p0.acquire_increment">5</prop>
<prop key="hibernate.c3p0.idle_test_period">100</prop>
<prop key="hibernate.c3p0.max_size">20</prop>
<prop key="hibernate.c3p0.max_statements">50</prop>
<prop key="hibernate.c3p0.min_size">5</prop>
<prop key="hibernate.c3p0.timeout">300</prop>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.format_sql">false</prop>
<prop key="hibernate.use_sql_comments">false</prop>
<!-- <prop key="hibernate.enable_lazy_load_no_trans">true</prop> -->
<!-- ehcache settings -->
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.region.factory_class">org.hibernate.cache.jcache.JCacheRegionFactory</prop>
<prop key="hibernate.javax.cache.provider">org.ehcache.jsr107.EhcacheCachingProvider</prop>
<prop key="hibernate.cache.use_second_level_cache">true</prop>
<prop key="hibernate.cache.default_cache_concurrency_strategy">read-write</prop>
<prop key="hibernate.javax.cache.uri">classpath:jcache.xml</prop>
</props>
</property>
</bean>
jcache.xml (all of it)
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ehcache.org/v3" xmlns:jsr107="http://www.ehcache.org/v3/jsr107"
xsi:schemaLocation="
http://www.ehcache.org/v3
http://www.ehcache.org/schema/ehcache-core.xsd
http://www.ehcache.org/v3/jsr107
http://www.ehcache.org/schema/ehcache-107-ext.xsd">
<!-- https://hibernate.atlassian.net/browse/HHH-12531 -->
<service>
<jsr107:defaults enable-management="true" enable-statistics="true" default-template="default" />
</service>
<cache alias="org.hibernate.cache.spi.QueryResultsRegion">
<expiry>
<tti unit="seconds">300</tti>
</expiry>
<heap>1024</heap>
</cache>
<cache alias="org.hibernate.cache.spi.TimestampsRegion">
<expiry>
<none />
</expiry>
<heap>4096</heap>
</cache>
<cache-template name="default">
<expiry>
<tti unit="seconds">300</tti>
</expiry>
<heap>1024</heap>
</cache-template>
created a hibernate issue too
https://hibernate.atlassian.net/browse/HHH-12635
I'm not sure creating an issue in Hibernate was a good idea. This is most probably a configuration issue on your side.
The first thing I can say is that hibernate-ehcache should not be there. This is used for Ehcache 2. Not JCache+Ehcache3.
Then, can you please try to rename the jcache.xml to ehcache.xml?
Finally, no, you should not need to start the provided. It should start by itself.
Henri was right that I did not need hibernate-ehcache. But renaming jcache.xml to ehcache.xml was not required.
In short the fix to my error was to add the jcache.xml resource to my ant build, because it was not getting deployed. With that said, for others who may have this error, there is such a maze of possibilities and lack of clear simple-stupid config for hibernate 5.3, spring 5, ehcache 3.5.2, jdk 10, tomcat 9, your only hope (other than dumb luck, which does work) is to put tomcat in debug mode, attach eclipse, add the hibernate-core source to an eclipse project, set a breakpoint in the offending hibernate class/method and see what is not available/expected in your particular configuration.
Also for others trying to make this work, strange, I do need spring-boot-starter-cache, without it none of my spring hibernate config is read. I am a Spring 2.5 guy of 13 years, so i have yet to understand what spring boot is. it is suppose to be an "opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss". but it also seems to be a runtime/embedded tomcat, so whatever, i am sure that it is quite useful sometimes and quite undefined and confusing others....
I am getting class cast exception while trying to Index the entity through Hibernate5 Search API on Websphere 8.5.5.10. The transactions are being managed by Spring Transaction. The document entities are getting indexed properly on local tomcat but not on WebSphere.
I have created a RESTFUl web service call to index the entities.
Spring 4.2
Hibernate Core 5.0.11.Final
Hibernate Search 5.5.5.Final
Here is my config file
<bean id="sessionFactory"
class="org.springframework.orm.hibernate5.LocalSessionFactoryBean">
<property name="dataSource" ref="datasource" />
<property name="packagesToScan">
<list>
<value>model</value>
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.Oracle10gDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.format_sql">false</prop>
<prop key="hibernate.default_schema">dev</prop>
<prop key="hibernate.generate_statistics">true</prop>
<prop key="hibernate.search.default.directory_provider">filesystem</prop>
<prop key="hibernate.search.default.indexBase">/var/lucene/indexes</prop>
</props>
</property>
</bean>
<bean id="transactionManager"
class="org.springframework.orm.hibernate5.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory" />
</bean>
And the stack trace in websphere app logs:-
HSEARCH000058: HSEARCH000116: Unexpected error during MassIndexer operation
org.hibernate.engine.transaction.jta.platform.spi.JtaPlatformException: Could not obtain WebSphere TransactionManager
at org.hibernate.engine.transaction.jta.platform.internal.WebSphereJtaPlatform.locateTransactionManager(WebSphereJtaPlatform.java:66)
at org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform.retrieveTransactionManager(AbstractJtaPlatform.java:87)
at org.hibernate.search.batchindexing.impl.BatchTransactionalContext.lookupTransactionManager(BatchTransactionalContext.java:53)
at org.hibernate.search.batchindexing.impl.BatchTransactionalContext.(BatchTransactionalContext.java:42)
at org.hibernate.search.batchindexing.impl.BatchIndexingWorkspace.runWithErrorHandler(BatchIndexingWorkspace.java:118)
at org.hibernate.search.batchindexing.impl.ErrorHandledRunnable.run(ErrorHandledRunnable.java:32)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:483)
at java.util.concurrent.FutureTask.run(FutureTask.java:274)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
at java.lang.Thread.run(Thread.java:798)
Caused by: java.lang.ClassCastException: com.ibm.ws.tx.jta.TranManagerSet incompatible with javax.transaction.TransactionManager
at org.hibernate.engine.transaction.jta.platform.internal.WebSphereJtaPlatform.locateTransactionManager(WebSphereJtaPlatform.java:63)
I am not sure what am I doing wrong here. Apart from Index Webservice call, other REST webservices are running fine and my UI is populating as expected.
Any help will be much appreciated.
We ran into this issue.
Issue:
If we use a hibernate version that uses JPA 2.1 (> hibernate version 4.3), it will conflict with older versions of websphere (versions 7, 8.5 without the JPA 2.1 fix packs). Specifically the exception you would see is this:
nested exception is java.lang.NoSuchMethodError: javax/persistence/Table.indexes()[Ljavax/persistence/Index;
Solution 1:
One way to resolve this issue is setting the classloader to parent_last so that JPA 2.1 that ships with hibernate will be used. However, you will run into other problems like the ones mentioned above.
Conflict with TransactionManager that ships with hibernate, Exception:
java.lang.ClassCastException: com.ibm.ws.tx.jta.TranManagerSet incompatible
with javax.transaction.TransactionManager
This can be solved by excluding the following jar (example maven
configuration for the hibernate dependency) that causes the
conflict:
<exclusion>
<artifactId>jboss-transaction-api_1.2_spec</artifactId>
<groupId>org.jboss.spec.javax.transaction</groupId>
</exclusion>
Conflict with xml-apis.jar that ships with hibernate resulting in the exception:
javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.DocumentBuilderFactory cannot be found
This can be resolved by excluding the xml-apis.jar from hibernate
dependency like so:
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
Solution 2:
Use a custom PersistenceProviderResolver so that the Websphere classes do not interfere with Hibernate:
https://stackoverflow.com/a/37354979/5150013
According to this article, this is a conflict between 2 different versions of java.transaction packages (one is in websphere, one in GemFire.jar, a lib deployed with websphere).
It also suggests a fix :
Drop the package javax.transaction from GemFire.jar: zip -d gemfire.jar javax/transaction/*
Hope this helps.
From SpringBoot version 2.2.0.RELEASE, there is transaction manager api used from jakarta. In case you want to make it work just exclude
<dependency>
<groupId>jakarta.transaction</groupId>
<artifactId>jakarta.transaction-api</artifactId>
</dependency>
from
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
The basic thought is to have only one transaction manager. Here we are removing the one being provided from the sprintboot-jpa
I'm trying running JMS application using hornetq on tomcat! I tried following this article. I put jndi.properties in my client class path; jndi.properties:
java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory
java.naming.factory.url.pkgs=org.apache.naming
I added these dependencies to pom.xml:
<dependency>
<groupId>tomcat</groupId>
<artifactId>naming-factory</artifactId>
<version>5.5.23</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>tomcat</groupId>
<artifactId>naming-resources</artifactId>
<version>5.5.23</version>
<scope>test</scope>
</dependency>
My JMS spring beans:
<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop key="java.naming.factory.initial">org.apache.naming.java.javaURLContextFactory</prop>
<prop key="java.naming.factory.url.pkgs">org.apache.naming</prop>
</props>
</property>
</bean>
<!-- Connection Factory -->
<bean id="hornetqConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiTemplate" ref="jndiTemplate"/>
<property name="jndiName" value="/ConnectionFactory" />
</bean>
<!-- Destinations -->
<bean id="annotationDeleteCommandDestination" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiTemplate" ref="jndiTemplate"/>
<property name="jndiName" value="/queue/command/annotation/deleteQueue" />
</bean>
I'm using HornetQ default server (standalone, non-clustered)
hornetq-jms.xml:
<queue name="annotationDeleteCommandQueue">
<entry name="/queue/command/annotation/deleteQueue"/>
</queue>
<connection-factory name="NettyConnectionFactory">
<xa>false</xa>
<connectors>
<connector-ref connector-name="netty"/>
</connectors>
<entries>
<entry name="/ConnectionFactory"/>
</entries>
</connection-factory>
But when i starting tomcat i get this error:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hornetqConnectionFactory' defined in ServletContext resource [/WEB-INF/classes/config/spring/applicationContext-jms.xml]:
Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: Name ConnectionFactory is not bound in this Context .........
What is wrong?
Should i put any jar files in the tomcat classpath? (which jars?)
Should i put queues and connection factories definitions in the tomcat configs? (how?)
Can i disable JNDI in tomcat and use hornetq standalone JNDI instead?
I solved this problem by modification of jndiTemplate (using jboss naming) and adding jnp-client.jar to client classpath:
<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop key="java.naming.factory.initial">org.jnp.interfaces.NamingContextFactory</prop>
<prop key="java.naming.factory.url.pkgs">org.jboss.naming:org.jnp.interfaces</prop>
<prop key="java.naming.provider.url">jnp://localhost:1099</prop>
</props>
</property>
</bean>
Are you sur HornetQ is started correctly? The error log seems to indicate that the ConnectionFactory is not present.
Have you tried to access HornetQ using another tool?
You should be able to use JMX or HermesJMS (http://www.hermesjms.com) to verify the presence of your ConnectionFactory
I am trying to integrate Tiles 3.0.0 with Spring 3.1, I have all the tile jar files under my lib folder. When I run the web project I get an
java.lang.ClassNotFoundException: org.apache.tiles.startup.BasicTilesInitializer
error. I need some help understanding why I am getting this error. Here is my configuration to setup in my servlet.xml page.
<bean class="org.springframework.web.servlet.view.tiles2.TilesViewResolver" />
<bean class="org.springframework.web.servlet.view.tiles2.TilesConfigurer">
<property name="definitions">
<list>
<value>/WEB-INF/views/**/views.xml</value>
</list>
</property>
</bean>
Here is a question that's a lot like mine, link, but I've already got my tiles-core-3.0.0 in my build path. So I just need some help understanding how to get over this error.
Morgan
At the time of writing this, Spring still does not support Tiles 3. I'm using Spring 3.1.2 and had to downgrade Tiles back to version 2.2.2 in order for my application to run.
I've make a program working with Spring Framework version 3.2.13.RELEASE and Tiles-3 (version 3.0.5). You need to use following configuration
<bean id="tilesConfigurer"
class="org.springframework.web.servlet.view.tiles3.TilesConfigurer">
<property name="definitions">
<list>
<value>/WEB-INF/tiles/tiles-definitions.xml</value>
</list>
</property>
</bean>
with dependency
<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-extras</artifactId>
<version>3.0.5</version>
</dependency>
<!-- Spring Web MVC -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>3.2.13.RELEASE</version>
</dependency>
I think this is what you're trying to achieve. It works fine in my case !
This is what happens when I run my junit tests...
Another CacheManager with same name 'cacheManager' already exists in the same VM. Please
provide unique names for each CacheManager in the config or do one of following:
1. Use one of the CacheManager.create() static factory methods to reuse same
CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.
The source of the existing CacheManager is:
DefaultConfigurationSource [ ehcache.xml or ehcache-failsafe.xml ]
What's the reason behind the exception. Could there be more than 1 cacheManager running simultaneously?
This is how I configured the cachManager using Sping 3.1.1. It sets explicitly the scope of the cacheManager to "singleton"
<ehcache:annotation-driven />
<bean
id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
scope="singleton"
/>
The ehcache.xml looks like
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="false"
maxBytesLocalHeap="100M"
name="cacheManager"
>
....
</ehcache>
Finally my class
#Component
public class BookingCache implements CacheWrapper<String, BookingUIBean> {
#Autowired
private CacheManager ehCacheManager;
....
}
I'm very sure that I'm dealing with only one cacheManager in my code base. Something else is probably running the n-th instance.
Your EhCacheManagerFactoryBean may be a singleton, but it's building multiple CacheManagers and trying to give them the same name. That violates Ehcache 2.5 semantics.
Versions of Ehcache before version 2.5 allowed any number of CacheManagers with the same name (same configuration resource) to exist in a JVM.
Ehcache 2.5 and higher does not allow multiple CacheManagers with the same name to exist in the same JVM. CacheManager() constructors creating non-Singleton CacheManagers can violate this rule
Tell the factory bean to created a shared instance of the CacheManager in the JVM by setting the shared property to true.
<bean id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
p:shared="true"/>
I had the same issue with my integration tests using JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4).
The issue was resolved using following Hibernate configuration:
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
instead of using
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
Your problem is the context loading optimization built in the Spring test framework. Spring (per default) does not destroy the context once the test class is done, in hope that another test class might reuse it (instead of creating it from scratch).
You can override this default using #DirtiesContext, or if you use maven you can set surefire forkMode to "always" and create a new VM per test class.
After upgrading to Hibernate 5 I had to use:
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>
instead of:
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
Please note that the packages differ from each other.
You may also try to set name"xxx" on your ehcache.xml configuration (on the ehcache element).
That did the trick for me, as I think I had another cache configuration lurking in one of the modules of my app.
The shared solution also works, but I don't know the far-ranging implications of that.
http://forums.terracotta.org/forums/posts/list/6495.page
https://norrisshelton.wordpress.com/2012/03/08/spring-3-1-caching-abstraction-with-ehcache/
For posterity: A better way is to use the "accept-existing" property of the EhCacheManagerFactoryBean.
Setting the EhCacheManagerFactoryBean#shared to true worked for me.
Setting the EhCacheManagerFactoryBean#acceptExisting to true DIDN'T work for me.
import org.springframework.cache.ehcache.EhCacheCacheManager;
import org.springframework.cache.ehcache.EhCacheManagerFactoryBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.ClassPathResource;
#Configuration
public class EhCacheConfiguration {
#Bean
public EhCacheCacheManager ehCacheCacheManager() {
return new EhCacheCacheManager(ehCacheManagerFactoryBean().getObject());
}
#Bean
public EhCacheManagerFactoryBean ehCacheManagerFactoryBean() {
EhCacheManagerFactoryBean cacheManagerFactoryBean = new EhCacheManagerFactoryBean();
cacheManagerFactoryBean.setConfigLocation(new ClassPathResource("ehcache.xml"));
cacheManagerFactoryBean.setShared(true);
return cacheManagerFactoryBean;
}
}
As explained in Using EhCache in Spring 4 without XML
if you just test your business service,not second level cache,you can remove second level configuration in your spring config file,your test will be run successfully. there is my second level configuration :
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceUnitName" value="defaultPU" />
<property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">false</prop>
<!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
<prop key="hibernate.cache.use_second_level_cache">false</prop>
<prop key="hibernate.cache.use_query_cache">false</prop>
</props>
</property>
</bean>
if i change to full configuration of second level cache config ,the real webapp use in running time,like this:
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="persistenceUnitName" value="defaultPU" />
<property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.show_sql">false</prop>
<!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
<prop key="hibernate.cache.use_second_level_cache">true</prop>
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</prop>
<prop key="net.sf.ehcache.configurationResourceName">ehcache/ehcache-hibernate-local.xml</prop>
</props>
</property>
</bean>
then i get the same Exception "Another unnamed CacheManager already exists in the same VM"
In my case, we have a custom cache manager defined as bean.
Also a custom application context so we don't use the spring junit runner... hence the #DirtiesContext doesn't work.
The trick is to retrieve the cache instance from the bean, on that cache get the cacheManager (the instance from EHCache). and on that cachemanager call the removeCache method.
Put this in a method annotated with #After and your cache is removed from the VM after each test. Like this:
#After
public void destroy() {
MyCustomCacheManager customCacheManager = (MyCustomCacheManager) context.getBean("yourCustomCacheManagerBean");
try {
net.sf.ehcache.Cache cache = customCacheManager.getCache();
net.sf.ehcache.CacheManager cacheManager = cache.getCacheManager();
cacheManager.removeCache("nameOfYourCache");
} catch (IllegalAccessException e) {
e.printStackTrace();
}
context.destroy();
context = null;
}
I solved it by adding following to resources.groovy :
beans = {
...
aclCacheManager(EhCacheManagerFactoryBean) {
shared = true
}
...
}
It happened to me when switching to Spring Boot 2.0.2. Resolved it by doing the following:
REMOVE in application.yml
spring.jpa.properties.hibernate.cache.region.factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory
REMOVE in pom.xml
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
</dependency>
KEEP in pom.xml only
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
</dependency>
For future readers, the cause of this problem in my case was that in my pom.xml file I had imported the hibernate-ehcache library, which unknown to me also already contained the ehcache library, and then explicitly imported the net.sf.ehache libray.
This seemed to work fine when I was running as a standalone app (a command line utility for example) but it caused the error in the original post when running on a tomcat server.
Changing my pom file from:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.0.2.Final</version>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>2.7.4</version>
</dependency>
To:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.0.2.Final</version>
</dependency>
<!-- ehcache dependency removed -->
Fixed the problem. If anyone has any idea why the problem only appeared when running in a tomcat container I'd be interested to know..
In glassfish 3.0.1, I traced the issue to IniShiroFilter getting initialize twice, which happens when concurrent requests are fired just after the server start. Following is a stack trace from two different threads corresponding to two HTTP requets:
[#|2012-11-28T08:25:10.630-0800|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=28;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1249)
at org.apache.shiro.web.servlet.IniShiroFilter.<init>(IniShiroFilter.java:124)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:303)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:725)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1948)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:248)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sentilla.filter.DumpFilter.doFilter(DumpFilter.java:152)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:662)
Another thread
[#|2012-11-28T08:25:15.299-0800|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1249)
at org.apache.shiro.web.servlet.IniShiroFilter.<init>(IniShiroFilter.java:124)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:303)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:725)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:1948)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:248)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sentilla.filter.DumpFilter.doFilter(DumpFilter.java:152)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:662)
Looking at the stack trace ApplicationFilterConfig.java:248 could be the culprit. Or, glassfish is initializing filters in the wrong context, for comparison, Tomcat initializes filters during BootStrap.
In my case Problem is component-scan and java config.
root-context.xml
<context:component-scan base-package="org.beansugar">
servlet-context.xml
<context:component-scan base-package="org.beansugar">
spring component-scan work two times on xml files.
it generate beans inside SpringConfig.java each run time.
then duplicate cache manager was created.
so, I changed that like below.
root-context.xml
<context:component-scan base-package="org.beansugar">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
servlet-context.xml
<context:component-scan base-package="org.beansugar" use-default-filters="false">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
This error also happens with wrong mapping files. The message is horrible, doesn't say the cause.
In my case configuration was as follows:
<spring.boot.version>1.5.8.RELEASE</spring.boot.version>
<spring.boot.yarn.version>2.4.0.RELEASE</spring.boot.yarn.version>
<spring.version>4.3.7.RELEASE</spring.version>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.5.1-Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>3.5.1-Final</version>
</dependency>
Changing the EHCache provider class did the job for me. I was using cache provider class as org.hibernate.cache.EhCacheProvider instead i changed this to:
net.sf.ehcache.hibernate.SingletonEhCacheProvider
As of Spring Boot 2.1.2 the following configuration worked to resolve the issue. (Note, these are snippets of the overall config.)
Dependencies:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.2.8.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>5.2.8.Final</version>
</dependency>
application.yml config:
spring:
jpa:
open-in-view: false
hibernate:
ddl-auto: none
show-sql: true
properties:
dialect: org.hibernate.dialect.MySQLDialect
net:
sf:
ehcache:
configurationResourceName: ehcache.xml
hibernate:
cache:
use_second_level_cache: true
region:
factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory
ehcache.xml configuration:
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<!-- Required elements -->
<diskStore path="java.io.tmpdir"/>
<defaultCache
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="true"/>
<!-- Cache settings per class -->
<cache name="com.mystuff.component.services.example.Book"
maxElementsInMemory="1000"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
overflowToDisk="true"/>
</ehcache>
The application I am working on slows down drastically without a working cache. So, to validate I simply ran the application and hit one of the read intense endpoints.
In my case the Manager was created by this bean (ehCache 2.10):
<bean id="ehcache"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="shared" value="false"/>
</bean>
the only solution that worked for me is to destroy it manually in that way :
#Inject
private EhCacheManagerFactoryBean ehCacheManagerFactoryBean;
And then
ehCacheManagerFactoryBean.destroy();