| Summary: | JDG as a library breaks Hibernate 2LC with java.lang.ClassCastException: org.infinispan.remoting.ReplicationQueueImpl cannot be cast to org.infinispan.remoting.ReplicationQueue | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 6 | Reporter: | Martin Gencur <mgencur> | ||||
| Component: | Infinispan | Assignee: | Tristan Tarrant <ttarrant> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Gencur <mgencur> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.1.0 | CC: | dereed, jdg-bugs, maschmid, mnovotny, myarboro, slaskawi | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 6.2.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | 999354 | Environment: | |||||
| Last Closed: | 2015-09-23 07:27:33 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Martin Gencur
2013-08-30 09:24:06 UTC
Mircea Markus <mmarkus> made a comment on jira ISPN-3496 ReplicationQueueImpl does implements ReplicationQueue, possibly a class loading issue. LegacyConfigurationAdaptor has been dropped in 6.0.0.Beta1, I'd be curious to see if this bug reproduces. This bug is from LegacyConfigurationAdaptor#adapt(org.infinispan.config.Configuration) -- a new method added in Infinispan 5.2.
The calls in this method to legacy.getClassLoader() return the wrong classloader.
public ClassLoader getClassLoader() {
if (cl != null)
// The classloader has been set for this configuration
return cl;
else if (cl == null && globalConfiguration != null)
// The classloader is not set for this configuration, and we have a global config
return globalConfiguration.getClassLoader();
else
// Return the default CL
return Thread.currentThread().getContextClassLoader();
}
The correct classloader to use was set by AS in the GlobalConfiguration.
But at the point that DefaultCacheManager#defineCache calls LegacyConfigurationAdaptor#adapt, setGlobalConfiguration has not been called on the configuration object, so globalConfiguration is null, causing getClassLoader to incorrectly return the TCCL instead of the correct classloader.
(In 5.1 setGlobalConfiguration was called later on during wireCache, but is no longer called at all in 5.2+)
This bug can be reproduced also with ISPN 6.0.0.Alpha4 deployed in EAP 6.1.1 (which uses 5.2.7.Final-redhat-1 internally). The exception is still the same. Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-3496 Indeed, this is a classloading issue. The Infinispan classes provided by EAP and the Infinispan classes in the WAR deployment are getting messed up to lead to a CCE caused by different classloaders. This particular issue might be fixable, but there's a whole host of other issues that could surface. The question is: is this something we really want to be fixing? What is the problem with JDG Helloworld quickstart piggy backing on the provided Infinispan JAR by EAP? I'd expect that to work without problems. Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-3496 @dereed, {quote} This bug is from LegacyConfigurationAdaptor#adapt(org.infinispan.config.Configuration) – a new method added in Infinispan 5.2. {quote} ^ Not a new method at all, it was there already in Infinispan [5.1.x|https://github.com/infinispan/infinispan/blob/5.1.8.Final/core/src/main/java/org/infinispan/configuration/cache/LegacyConfigurationAdaptor.java#L294]. I suspect the problem is due to different classloader() method defaults in 5.1.x vs 5.2.x. In 5.1.x, the default was [Thread.currentThread().getContextClassLoader();|https://github.com/infinispan/infinispan/blob/5.1.8.Final/core/src/main/java/org/infinispan/configuration/cache/ConfigurationBuilder.java#L7], whereas in 5.2.x is [null|https://github.com/infinispan/infinispan/blob/5.2.7.Final/core/src/main/java/org/infinispan/configuration/cache/ConfigurationBuilder.java#L34]. If null, Util class' classloader will be used. Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-3496 @dereed, {quote} This bug is from LegacyConfigurationAdaptor#adapt(org.infinispan.config.Configuration) – a new method added in Infinispan 5.2. {quote} ^ Not a new method at all, it was there already in Infinispan [UPDATED] The default of ConfigurationBuilder has nothing to do here. Galder Zamarreño <galder.zamarreno> made a comment on jira ISPN-3496 @dereed, {quote} This bug is from LegacyConfigurationAdaptor#adapt(org.infinispan.config.Configuration) – a new method added in Infinispan 5.2. {quote} ^ Not a new method at all, it was there already in Infinispan 5.1.x [UPDATED] The default of ConfigurationBuilder has nothing to do here. > ^ Not a new method at all, it was there already in Infinispan 5.1.x
You're right. What's new is that it's now called from DefaultCacheManager.defineConfiguration where setGlobalConfiguration has not been called on the configuration passed in.
In order for LegacyConfigurationAdaptor#adapt to work correctly, DefaultCacheManager.defineConfiguration must call setGlobalConfiguration on the configuration before passing it to adapt (or something equivalent, to get the classloader set correctly).
> The question is: is this something we really want to be fixing? Definitely. We have to fix it, or you can't use JDG (or community Infinispan) in any deployment that also uses a hibernate 2nd level cache (or possibly other use cases). > What is the problem with JDG Helloworld quickstart piggy backing on the > provided Infinispan JAR by EAP? I'd expect that to work without problems. Then it's using the EAP Infinispan instead of JDG. (Which we don't support) we can't rely on bundled ISPN in EAP/AS as that is private module and as such is not supported to use in applications, so there is no official supported way how to use ISPN in application with JPA layer, because of hibernate 2LC classloader conflict. Mircea Markus <mmarkus> updated the status of jira ISPN-3496 to Resolved Mircea Markus <mmarkus> updated the status of jira ISPN-3496 to Reopened Pedro Ruivo <pedroruivo2> made a comment on jira ISPN-3496 [~mgencur] can you give it a try with https://github.com/pruivo/infinispan/tree/ISPN-3496_5_2_x ? I'm setting the global configuration before invoking the adapt... Also, the adapter as dropped in 6.0.beta1. Can you also give it a try with that version? Dennis Reed <dereed> made a comment on jira ISPN-3496 PR2107 should fix the specific use case, but it's still different behavior than 5.1.x. 5.1.x: if ( configuration classloader set ) use it else if ( global configuration classloader set ) use it else use TCCL 5.2.x before patching: if ( configuration.classloader set ) use it else use TCCL 5.2.x after PR2107: use global configuration classloader Dennis Reed <dereed> made a comment on jira ISPN-3496 PR2107 should fix the specific use case, but it's still different behavior than 5.1.x. 5.1.x: if ( configuration classloader set ) use it else if ( global configuration classloader set ) use it else use TCCL 5.2.x before patching: if ( configuration.classloader set ) use it else use TCCL 5.2.x after PR2107 (order change if set in multiple places): if ( global configuration classloader set ) use it else if ( configuration.classloader set ) use it else use TCCL The fix for this bug was actually applied to 5.2.x ISPN branch so it does not affect JDG 6.2. There's no need for a fix in JDG 6.2 |