The region-based configuration thing is somewhat of a holdover from the pre-JGroups-multiplexer days, when a cache was an expensive object due to the need for its own JChannel. It allows multiple deployments with different type systems to use the same underlying cache, as long as they store their data in separate regions. HTTP session repl with FIELD granularity uses this, since MarshalledValue wouldn't work properly with what PojoCache needs. My instinct is that with the multiplexer it makes more sense to have an architecture where deployments that need a cache instantiate their own -- see comments on the second half of http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93825 for some thoughts on this. But this takes some thought. It goes in the opposite direction, for example, from an idea Sacha raised last winter about having all data related to a Seam app be stored in the same cache so there could just be one replication event per request. JGroups does provide the needed hooks for applications to do marshalling/unmarshalling of messages as they see fit. JBC makes extensive use of these (as does HAPartition). So JGroups isn't naive in this respect. It's more that JBC is naive, if the overly complex region-based thing isn't used. anonymous wrote : The default configuration of the serialization aspect needs to be triggered by an application level aspect, which could pick up the app thread context class loader. OK, sounds like we're moving toward something like: 1) JBC exposes an API that allows registration of a default classloader but which doesn't trigger the whole region-based marshalling overhead. I suppose registration can be a simple setter in the Configuration object graph. 2) We have a wrapper class that in create() picks up the TCCL and registers it, then calls create on the cache. In destroy() it calls destroy() on the cache and then unregisters the classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989478#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...