EHC ❯ Should have better control of deserialization classloader with ehcache-terracotta

• Type: Bug
• Status: Closed
• Priority: 0 Showstopper
• Resolution: Fixed
• Component/s: ehcache-terracotta
• Labels:

• Assignee: hsingh
• Reporter: amiller
• Created: November 16, 2009
• Votes: 0
• Watchers: 1
• Updated:

  January 17, 2013
• Resolved:

  December 07, 2009

Description

This question first arose in the context of using ehcache-terracotta in OSGi. Currently, when using terracotta clustering, the object will be deserialized out of the clustered cache using the defining loader of ehcache-terracotta.jar. However, in cases like OSGi or other app server scenarios, it would be desirable for the loader to be some other classloader.

One way to deal with this is to use the thread-context classloader (TCCL) to allow callers to effectively influence the classloader to use. This would probably be a change that would allow many of these use cases to work (possibly with client changes).

Another jira coming for a longer-term fix.

Comments

Alex Miller 2009-12-07

Added test in terracotta-ehcache/system-tests (OtherClassloaderCacheTest) and made Ehcache clustered serialized value deserialization look at the thread context classloader during deserialization. (Use Thread.currentThread().setContextClassLoader() to control that)