I have a prelim fix for JBCACHE-752 in HEAD. I know it's a little hacky, but couldn't come up with a better solution without significantly reengineering a lot of stuff. Here's where the problem lies. Note that this only pertains to when region-based marshalling is used. 1) When marshalling method calls, we run through a switch statement on method id to determine which parameter contains the Fqn in question, and we use the Fqn to determine the cache region and use the appropriate context class loader. A bit hacky in the way the region is identified, but works well. 2) Now for return values, there is no way to determine the region with which to attach the response value to, without changing the interface of the marshaller (which implements a JGroups interface) so the Region or Fqn or maybe even a ClassLoader is somehow passed in. What I've done is that I've assumed that when objectFromByteBuffer() is called, you could safely assume that if the object that you recreate is NOT a MethodCall, then it is a return value. If it is a MethodCall, we get a hold of the Fqn (see (1)) and put it in a ThreadLocal container. This way, when the same thread calls objectToByteBuffer() to marshall a return value, it will have a handle on the Fqn and hence the class loader. Like I said, this is a bit hacky and only really works for RPC based use of the marshaller to deal with return values of method calls. I don't think this is a problem for other uses of the marshaller like State Transfer and cache loaders since it is not used in an RPC context, but I just thought I'd post this here in case someone feels like proving me wrong. :-) Cheers, -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani