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. 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 _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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