[jbosscache-dev] Re: ComponentRegistry and TransactionManager

Manik Surtani wrote: > Brian > This is a bug in the ComponentRegistry. The way it works at the > moment, when we start(), we recreate any components where > construction differs based on configuration, such as the > interceptor chain and node factory. the TM should be there as well > - will patch this up and check it into trunk. Thanks for the quick work! The way I interpret this, sounds like it will try to resolve the TM twice -- once during bootstrap, and again in start()? If so, can we avoid an ERROR logging during bootstrap? (This happens when OL is configured.) > Cheers > Manik > On 10 Jan 2008, at 18:39, Brian Stansberry wrote: >> Interesting change from the ComponentRegistry has bitten me in the >> ass. >> >> The resolution of the TransactionManager used to take place in >> CacheImpl.create(), now it's happening via >> DefaultCacheFactory.bootstrap() -- i.e. as part of cache >> construction. >> >> This causes problems with the Hibernate integration, which injects >> the TM it knows about into the RuntimeConfig of the already- >> existing cache, before it calls create(). But that's too late -- >> the TransactionManagerFactory has already logged an error about a >> missing TM. >> >> A solution would be for Hibernate to get a Configuration first, >> inject the TM, and then build the cache. But the CacheManager API >> doesn't expose a good way to do that. An external caller can't >> modify the registered configurations. >> >> So: >> >> 1) What do you think about changing the ConfigurationRegistry API >> to allow some sort of updating of registered configurations? >> >> 2) In general, do you think it's a problem that we are now >> resolving things earlier in the process than we used to? Other >> users may also be doing things programatically after cache >> construction but before create/start. >> >> -- >> Brian Stansberry >> Lead, AS Clustering >> JBoss, a division of Red Hat >> brian.stansberry(a)redhat.com > -- > Manik Surtani > Lead, JBoss Cache > manik(a)jboss.org -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com