[jbosscache-dev] Re: [javagroups-users] Considering migrating to jboss cache from DistributedTree

[Brian Stansberry]

Hmm. The cache's RuntimeConfig object only allowing injection of 
JChannelFactoryMBean isn't good; at least being able to inject a plain 
org.jgroups.JChannelFactory seems called for.  The ugly bit is the class 
and the interface have no direct type relationship, so you'd have to 
expose properties of both types.

I think the reason for not allowing passing a Channel to the 
RuntimeConfig is that would imply exposing the Channel as well.  The 
Channel is not meant to be exposed to outside callers for the same 
reason we no longer expose the RpcDispatcher.

Bill Middleton wrote:
> 
>      > It does appear that I can get access to the rpcdispatcher for the
>      > jboss cache using getRPCManager(), or via implementing the
>     depracated
>      > RpcTreeCache, so it may be that my implementation can just use an
>      > standard CacheSPI, and doesn't need to extend CacheImpl (or some
>     other
>      > concrete class), right?
> 
>     I would discourage you from doing that. Exposing the RpcDispatcher in
>     JBossCache was necessary for our internal aspects to invoke the (public)
>     methods on it, but we never intended for users of cache to use it. So,
>     in 2.0 we removed them (or made them available only through the SPI
>     API). 
> 
> 
> Thanks for the advice, Bela.  Unfortunately, an mbean is not a viable 
> option for us.  I can gladly create a multiplexer using the standard 
> jgroups api (as seen in MultiplexerStressTest.java, for example), but 
> that'd imply an ability to pass in my Channel directly to the Cache 
> constructor, I assume, and DefaultCacheFactory doesn't seem to 
> interested in letting me do that. 
> 
> Bill


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com