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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...