[jboss-dev-forums] [Design of JBossCache] - Re: JBC and RPC
bstansberry@jboss.com
do-not-reply at jboss.com
Sun Nov 5 22:54:34 EST 2006
The multiplexer shouldn't really be tied to JMX; you should be able to inject the same JChannelFactory pojo into both a JBC instance and some other RPCDispatcher-based class. But, all we can do now is call a setter in the Configuration, passing a String with the multiplexer service object name. That works fine in the AS (until Scott Stark reads this post and tells me it's not acceptable), but Ben's right, it's too painful in a non-JBoss AS environment.
One question is where to do the injection:
1) In the Configuration. But then Configuration is no longer a simple, lightweight, Serializable object.
2) In the CacheSPI. But then a major piece of configuration information is no longer in the Configuration.
The same question applies with the TransactionManager. The whole TransactionManagerLookupClass business seems silly when it should be possible to inject the TransactionManager.
My vote is these things should be injected into the Configuration. The Configuration encapsulates all the external inputs needed to build the cache.
anonymous wrote : How about we expose the JBC channel in the CacheSPI, say, getJChannel()? This way, a regular Cache user won't have access to that API but a customized provider can.
Giving access to the JChannel doesn't help much, since JBC puts an RpcDispatcher on top of it, plugs in a very custom Marshaller, etc. If a user had access to the JChannel without access to all that stuff, all they could do would be send messages that would cause exceptions on the other end when our marshaller didn't know how to handle them.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983347#3983347
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983347
More information about the jboss-dev-forums
mailing list