[jbosscache-dev] Re: ComponentRegistry and TransactionManager

[Manik Surtani]

Done


On 11 Jan 2008, at 15:23, Brian Stansberry wrote:

> 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 at redhat.com
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manik at jboss.org
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberry at redhat.com

--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org