[infinispan-issues] [JBoss JIRA] (ISPN-5043) Composite Key caching problem when deploying multiple applications in a single Jboss Application Server using Infinispan (classloader issues).

Stijn Vlaes created ISPN-5043: --------------------------------- Summary: Composite Key caching problem when deploying multiple applications in a single Jboss Application Server using Infinispan (classloader issues). Key: ISPN-5043 URL: https://issues.jboss.org/browse/ISPN-5043 Project: Infinispan Issue Type: Bug Components: Core, Server Affects Versions: 5.2.1.Final Environment: JBOSS AS 7.2.0.FINAL, Windows 7/Linux, Spring framework 4.1.1 Infinispan/Hibernate versions included in JBoss AS Reporter: Stijn Vlaes While developing our applications we encountered a problem with the use of Composite ID's when using Hibernate with Infinispan causing us to have classcast exceptions like the following: Request processing failed; nested exception is org.hibernate.PropertyAccessException: could not get a field value by reflection getter of be.vaph.cachingtest.common.barema.Barema.wettelijkeFunctieCode. Our setup: - 2 applications (1 with a rest interface, 1 with a web interface) - Both applications use the same bussiness logic and data (same database, pojo's, ...) - Both applications are deployed on the same Jboss AS, with infinispan configured in jboss and thus shared between the 2 applications. Let's take the following example: - Jboss AS 7 runs infinispan on its own main ClassLoader A and gives each application running on it it's own classloader. - App 1 (rest) uses ClassLoader B. - App 2 (web) uses ClassLoader C. - App 1 does a query for some pojo's en puts these in the cache (using a composite key). - App 2 does the same query and since it notices these pojo's are available in its cache and tries to load them. The problem: App 2 gets an exception, saying it can't cast the key to a key of the correct type. We discovered in the above case, that infinispan stored the instance of the key that was created while loading the object in app 1. Because this key is made in app 1 it was created by a different classloader then the one currently used by app 2. This causes the above exception, since the code thinks the found key isn't of the correct type. As a side note: we have also encountered this issue with enumerations in keys, which are also created by a specific classloader, and thus bound to it. Included is an example project made with Spring Boot to simulate the problem we are having. The example contains a single application that is configured to be deployed twice on a single jboss AS server. -- This message was sent by Atlassian JIRA (v6.3.8#6338)