Re: [jbosscache-dev] CacheSPI.setStateTransferManager
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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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