Manik and I have just chatted. One possibility. Instead of have a setter on STM, we expose a sort of a static factory method to obtain the STM class. But this also has the same concern as you do to expose this prior to defining the contract.

The other possibility is I defer the implementation of PojoCacheStateTransferManager after the alpha release and wait for the STM API to settle down, althouhg I'd prefer to implement it ASAP, especially for partial state transfer piece.

Another question. Currently, StateTransferManager is using TreeCache directly. Would it be possibel to use CacheSPI instead? Otherwise, any subclass of StateTransferManager isn't having access to TreeCache.

-Ben -----Original Message----- From: Vladimir Blagojevic Sent: Tuesday, September 19, 2006 9:41 PM To: Manik Surtani; Ben Wang Cc: jbosscache-dev(a)lists.jboss.org Subject: RE: [jbosscache-dev] CacheSPI.setStateTransferManager One downside is that we are opening StateTransferManager API to extensions and plugins prior to clearly defining the contract around StateTransferManager. It is sort of internal class that has to be promoted to a new role without being completely ready for it. Brian? > -----Original Message----- > From: jbosscache-dev-bounces(a)lists.jboss.org > [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik > Surtani Sent: Tuesday, September 19, 2006 7:29 AM > To: Ben Wang > Cc: jbosscache-dev(a)lists.jboss.org > Subject: Re: [jbosscache-dev] CacheSPI.setStateTransferManager > > There should be a setter as well. Vladimir, Brian: can you think of > a > good reason not to allow this to be set programmatically in the SPI? > -- Manik Surtani > > Lead, JBoss Cache > JBoss, a division of Red Hat > > Email: manik(a)jboss.org > Telephone: +44 7786 702 706 > MSN: manik(a)surtani.org > Yahoo/AIM/Skype: maniksurtani _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev