[jbosscache-dev] CacheSPI.setStateTransferManager

[Brian Stansberry]

jbosscache-dev-bounces at lists.jboss.org wrote:
> 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.
> 

We already expose StateTransferManager via the getter.  Unless that can
be removed, the class is already exposed.

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

The STM API is going to have to be settled before 2.0.0.CR1.  It doesn't
have to be settled for an alpha.  We need to get the alpha out for
preliminary integration work in the AS, or else cut a snapshot to
integrate.  IMHO we shouldn't worry too much about the current state of
the StateTransferManager API as long as we're comfortable we can settle
it for the CR1.

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

StateTransferManager invokes TreeCache.callRemoteMethods, which I can't
imagine being added to CacheSPI.  There may be other methods as well.
It has a public getter/setter for the cache that subclasses can use.

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



Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry