ComponentRegistry and TransactionManager

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.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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.stansberryredhat.com

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Just added a unit test to prove this as well.


On 11 Jan 2008, at 13:48, 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.
>
> 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.stansberryredhat.com
>
> --
> Manik Surtani
> Lead, JBoss Cache
> manikjboss.org
>
>
>
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.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.stansberryredhat.com
> 
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manikjboss.org
> 
> 
> 
> 
> 
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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.stansberryredhat.com
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberryredhat.com

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev