[jbosscache-dev] CacheSPI.setStateTransferManager

[Ben Wang]

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 at 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 at lists.jboss.org
> [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of Manik 
> Surtani
> Sent: Tuesday, September 19, 2006 7:29 AM
> To: Ben Wang
> Cc: jbosscache-dev at 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 at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani