[jbosscache-dev] CacheSPI.setStateTransferManager

[Manik Surtani]

We'll need to expose some of these managers.  Remember, the SPI will  
be used by interceptor authors who will need access to this  
functionality.

+1 to revisiting these classes though, to ensure they are in a state  
to be considered 'public' (I mean javadocs, and that their contracts  
are unit-tested and fulfilled)


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


On 19 Sep 2006, at 17:02, Brian Stansberry wrote:

> Ah good, didn't know you had the RPCManager.
>
> Which leads me back to the API question, because maybe RPCManager
> exposes stuff too that we may not consider "public API". Public in the
> sense that people can code against it and rely on it for the life of a
> major release.  Like the JGroups Address and MethodCall classes.   
> But if
> exposed through the CacheSPI getter, the class is out there.  So a
> general question is, where do we draw the line on what is the public
> API?
>
> Ideally it would be Cache and CacheSPI, plus any API exposed by a
> class/interface that those interfaces expose.  So, RPCManager and
> StateManager would be "public".  But following that rule exposes all
> sorts of other stuff as well (RegionManager, TransactionManager, ...).
>
> Manik Surtani wrote:
>> It should call CacheSPI.getRPCManager().callRemote...
>>
>>
>> On 19 Sep 2006, at 16:31, Brian Stansberry wrote:
>>
>>>
>>> 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.
>
>
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry