Thanks for the encouraging reply, Brian. My followup is inline, and there's a proposed patch at the end.<br><br>Bill<br><br><div><span class="gmail_quote">On 4/6/07, <b class="gmail_sendername">Brian Stansberry</b> <
<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bill Middleton wrote:<br>> A cursory (and likely naive) inspection of DefaultCacheFactory and<br>> CacheImpl seems to indicate that providing my own channel should be<br>> fairly easy to implement, even if an extension won't quite get the job
<br>> done, since channel is private. The intimidating part is the binding<br>> between the "official" multiplexed channel (mbean) and other<br>> functionality which implies a full app-server, such as the
<br>> TransactionManager.<br><br>Not sure what you mean here by "binding". Passing a JChannelFactoryMBean<br>to the RuntimeConfig doesn't carry with it a requirement to pass in a<br>TransactionManager. Think of RuntimeConfig as basically being a
<br>placeholder through which the external environment can pass in complex<br>objects the cache may need and through which callers can get access to a<br>few of the cache internals.</blockquote><div><br>Every test I run does insist upon looking for a TransactionManager, if one isn't found then a DummyTransactionManager is the "fall back" solution. Granted though, it's not bound to an app server.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> If I were to pass in a channel to CacheImpl,<br>> whether multiplexed or not, I don't think I'll mess with
<br>> setUsingMultiplexer() and friends in the Configuration. Since I'm going<br>> to manage the muliplexer functionality myself I guess it makes sense to<br>> let Cache think that it's just a simple channel. This seems safe
<br>> enough, I hope.<br>><br><br>Sure, as long as in reality it's a multiplexed channel, so the cache<br>doesn't get messages it won't understand. If you're writing your own<br>extensions, then presumably you know how the code will be used and can
<br>guard against misuse. So, the barrier for what's considered "safe" can<br>be a lot lower. :)</blockquote><div><br>My proposed patch doesn't require a multiplexed channel be passed in. The implementation can pass in either an ordinary JChannel (via new JChannel()) or one that's created via createMultiplexerChannel(). All of the state transfer tests pass in either case. In neither case is the Configuration set using setUsingMultiplexer(true). isUsingMultiplexer is always false. Seems to work ok - all tests pass using an adapted
StateTransferCompatibilityTest.java, anyhow.<br><br></div>Generally, my patch adds a new constructor, CacheImpl(Channel c). This is called by a new createChannel() method in the DefaultChannelFactory which accepts a channel, configuration, and boolean. If the new constructor is used to construct a ChannelImpl, then a global boolean is set which makes the create() method do the right thing at init-time.
<br><br>Is this approach way too simple minded? It's not providing any additional access to the internals of the cache per se, but yes, one must be careful in configuring the channel. Whats still missing here is the ability to fetch the entire Element <protocol_stacks> from the Configuration and pass it directly to the JChannelFactory(Element) constructor, so that the external JGroups stack would be guaranteed to match the one which is specified in the config.
<br><br><br>Bill<br><br>PS - sorry about the indentation in the patch, Eclipse cant quite figure out the scheme that jbosscache is using.<br><br><div><br><br><br></div><br></div><br>