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