webentwicklung-frage-antwort-db.com.de

Ein anderer unbenannter CacheManager ist bereits im selben vorhanden VM (ehCache 2.5)

Das passiert, wenn ich meine Junit-Tests durchführe ...

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 ]

Was ist der Grund für die Ausnahme? Könnte mehr als ein cacheManager gleichzeitig laufen?

So habe ich den cachManager mit Sping 3.1.1 konfiguriert. Es legt den Gültigkeitsbereich des cacheManagers explizit auf "Singleton" fest.

<ehcache:annotation-driven />

<bean
    id="cacheManager"
    class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
    scope="singleton"
    />

Die ehcache.xml sieht so aus

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
     updateCheck="false"
     maxBytesLocalHeap="100M" 
     name="cacheManager"
     >
 ....
 </ehcache>

Endlich meine Klasse 

@Component
public class BookingCache implements CacheWrapper<String, BookingUIBean> {

     @Autowired
     private CacheManager ehCacheManager;
      ....
}

Ich bin mir sehr sicher, dass ich nur einen cacheManager in meiner Codebasis habe. Etwas anderes führt wahrscheinlich die n-te Instanz aus.

66
simou

Ihr EhCacheManagerFactoryBean ist möglicherweise ein Singleton, aber es werden mehrere CacheManager erstellt und versucht, ihnen denselben Namen zu geben. Das verstößt gegen Ehcache 2.5 Semantik .

Versionen von Ehcache vor Version 2.5 erlaubten, dass eine beliebige Anzahl von CacheManagern mit demselben Namen (dieselbe Konfigurationsressource) in einer JVM vorhanden ist.

In Ehcache 2.5 und höher dürfen nicht mehrere CacheManager mit demselben Namen in derselben JVM vorhanden sein. CacheManager () - Konstruktoren, die Nicht-Singleton-CacheManager erstellen, können gegen diese Regel verstoßen

Teilen Sie der Factory-Bean mit, dass sie eine gemeinsam genutzte Instanz von CacheManager in der JVM erstellen soll, indem Sie die Eigenschaft shared auf true setzen. 

<bean id="cacheManager"
      class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
      p:shared="true"/>
43

Ich hatte das gleiche Problem mit meinen Integrationstests mit JPA (2.0) + Hibernate (3.6.4) + Spring (3.2.4). Das Problem wurde mit der folgenden Hibernate-Konfiguration behoben: 

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

anstatt zu verwenden 

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
39
Felix Reckers

Ihr Problem ist die Kontextladeoptimierung, die im Spring-Test-Framework eingebaut ist. Spring (standardmäßig) zerstört den Kontext nicht, sobald die Testklasse abgeschlossen ist, in der Hoffnung, dass eine andere Testklasse ihn wiederverwenden kann (anstatt ihn von Grund auf neu zu erstellen).

Sie können diese Standardeinstellung mit @DirtiesContext überschreiben. Wenn Sie maven verwenden, können Sie den surefire forkMode auf "always" setzen und pro Testklasse einen neuen VM erstellen.

20
Dejan P

Sie können auch versuchen, den Namen "xxx" in Ihrer ehcache.xml-Konfiguration (im ehcache-Element) festzulegen.

Das war der Trick für mich, denn ich glaube, ich hatte eine andere Cache-Konfiguration in einem der Module meiner App.

Die gemeinsam genutzte Lösung funktioniert auch, aber ich kenne die weitreichenden Auswirkungen davon nicht.

12
Michael Holst

Nach dem Upgrade auf Hibernate 5 musste ich Folgendes verwenden:

<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>

anstatt:

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

Bitte nicht das andere Paket.

8
eyes

Für die Nachwelt: Eine bessere Methode ist die Verwendung der Eigenschaft "Accept-Vorhanden" von EhCacheManagerFactoryBean .

6
Nishith

In meinem Fall haben wir einen benutzerdefinierten Cache-Manager, der als Bean ..__ definiert ist. Außerdem gibt es einen benutzerdefinierten Anwendungskontext, sodass wir nicht den Spring-Junit-Runner verwenden.

Der Trick besteht darin, die Cache-Instanz aus dem Bean abzurufen. In diesem Cache erhalten Sie den cacheManager (die Instanz aus EHCache). und rufen Sie in diesem Cache-Manager die removeCache-Methode auf.

Fügen Sie dies in eine mit @After kommentierte Methode ein, und der Cache wird nach jedem Test aus dem VM entfernt. So was:

@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;
}
2
Pim Hazebroek

Es ist mir beim Wechseln zu Spring Boot 2.0.2 passiert. Es wurde folgendermaßen gelöst: 

ENTFERNEN in application.yml

spring.jpa.properties.hibernate.cache.region.factory_class: org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory

ENTFERNEN in pom.xml

<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
</dependency>

KEEP nur in pom.xml

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-ehcache</artifactId>
</dependency>
2
Ronny Shibley

Ich habe es gelöst, indem Sie resources.groovy folgendes hinzugefügt haben:

bohnen = { ... aclCacheManager (EhCacheManagerFactoryBean) { shared = true } ...}

2
Dasma

wenn Sie nur Ihren Business-Service und nicht den Second-Level-Cache testen, können Sie die Second-Level-Konfiguration in Ihrer Spring-Konfigurationsdatei entfernen. Der Test wird erfolgreich ausgeführt. Es gibt meine zweite Stufe Konfiguration:

 <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>

wenn ich auf die vollständige Konfiguration der Second-Level-Cache-Konfiguration umsteige, verwende die echte Webapp zur Laufzeit:

    <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>

dann erhalte ich die gleiche Ausnahme "Ein anderer unbenannter CacheManager existiert bereits in derselben VM"

2
roger.li

Für zukünftige Leser war die Ursache dieses Problems in meinem Fall, dass ich in meine pom.xml-Datei die Hibernate-ehcache-Bibliothek importiert hatte, die mir auch bereits die ehcache-Bibliothek enthielt, und dann die net.sf.ehache explizit importierte Bibliothekar 

Dies schien gut zu funktionieren, wenn ich als Standalone-App (z. B. ein Befehlszeilendienstprogramm) ausgeführt wurde. Bei der Ausführung auf einem Tomcat-Server trat jedoch der Fehler im ursprünglichen Beitrag auf. 

Meine Pom-Datei ändern von:

        <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>

Zu:

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-ehcache</artifactId>
            <version>5.0.2.Final</version>
        </dependency>
        <!-- ehcache dependency removed -->

Problem behoben Wenn jemand eine Idee hat, warum das Problem nur bei der Ausführung in einem Tomcat-Container aufgetreten ist, würde ich das gerne wissen.

1
Matt Watson

Ab Spring Boot 2.1.2 funktionierte die folgende Konfiguration, um das Problem zu beheben. (Beachten Sie, dies sind Ausschnitte der Gesamtkonfiguration.)

Abhängigkeiten:

<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 Konfiguration:

<?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>

Die Anwendung, an der ich arbeite, verlangsamt sich drastisch, ohne dass ein Cache aktiv ist. Zur Validierung habe ich einfach die Anwendung ausgeführt und einen der intensiven Lesepunkte getroffen. 

0
kroolk

In glassfish 3.0.1 habe ich das Problem darauf zurückgeführt, dass IniShiroFilter zweimal initialisiert wurde. Dies geschieht, wenn gleichzeitig nach dem Serverstart gleichzeitige Anforderungen ausgelöst werden. Im Folgenden finden Sie eine Stack-Ablaufverfolgung von zwei verschiedenen Threads, die zwei HTTP-Requets entsprechen:

[#|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)

Ein weiterer 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)

Ein Blick auf die Stack-Spur ApplicationFilterConfig.Java:248 könnte der Täter sein. Oder Glassfish initialisiert Filter im falschen Kontext. Zum Vergleich initialisiert Tomcat Filter während der BootStrap. 

0
jsh

Dieser Fehler tritt auch bei falschen Mapping-Dateien auf. Die Nachricht ist schrecklich, sagt nicht die Ursache.

0
ejaenv

Das Einstellen des EhCacheManagerFactoryBean#shared auf true hat für mich funktioniert.

Das Festlegen von EhCacheManagerFactoryBean#acceptExisting auf true hat für mich nicht funktioniert.

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;
    }
}

Wie in Verwenden von EhCache in Spring 4 ohne XML

0
Mate Šimović

In meinem Fall Problem ist Component-Scan und 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 funktioniert zweimal für XML-Dateien . Sie generiert Beans in SpringConfig.Java zu jeder Laufzeit.

also habe ich das wie unten geändert.

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>
0
archmagece

In meinem Fall war die Konfiguration wie folgt:

<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>

Das Ändern der EHCache-Providerklasse hat die Aufgabe für mich erledigt. Ich habe die Cache-Provider-Klasse als org.hibernate.cache.EhCacheProvider verwendet, stattdessen habe ich Folgendes geändert: net.sf.ehcache.hibernate.SingletonEhCacheProvider

0
Ritesh