Manik Surtani wrote:
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
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
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.
> 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
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
Lead, JBoss Cache
Lead, AS Clustering
JBoss, a division of Red Hat