Sorry - slow response on this one -- too many threads this week :-) Segregating these kinds of things into a separate transient Runtime subobject sounds fine. Without objection I'm going to proceed down that line now, as it solves some issues with wiring things together in the AS. I'd like to explore more what you're thinking about here though in terms of reuse. I was thinking I'd like to have a service that's somewhat like the JChannelFactory, but instead for cache configs. Service creates (or is injected with) a bunch of named configs on startup. Users then say "give me the "HttpSession" config. Service hands it out. I was thinking in terms of cloning the config though, instead of using a shared ref. All of the testImmutability("xyz") stuff in Configuration kind of rules out a shared ref. Usage I was thinking about: jboss-web.xml has properties "cacheConfigName" and "cacheMode". The "cacheConfigName" is almost never set; defaults to "HttpSession". When webapp is deployed, it accesses the cache config service, gets a Configuration, changes it's cacheMode to match jboss-web.xml, gives it a unique clusterName, and creates the cache. Voila, cache per webapp. REPL_SYNC/REPL_ASYNC easily configurable per webapp. No activate/inactivateRegion, partial state transfer, problems with choosing a buddy who doesn't have the webapp deployed, etc. In this scenario, the webapp would *like* to have the TransactionManager and Multiplexer service already in the config. The MC injects them into the configs it uses to create the cache config service. When a config is cloned by the service, the refs to TM and Mux remain. Not absolutely needed, but nice. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984688#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...