I'm a bit confused with protocolStackConfiguration and protocolStackConfigurations.
On one side, you mention that a Channel will expose a Channel protocolStackConfiguration. Wouldn't it make more sense for stackName to be part of it rather than be a different attribute?
And protocolStackConfigurations property? Is a property of a Channel? I guess not. If anything, this sounds like a property of the channel factory but then again, why have that property and then individual Channels via the ChannelFactory MO?
Finally, would it make sense to add a coordinator attribute to View indicating which node is the coordinator? Or are we assuming the 1st node in the view is always the coordinator?
The protocolStackConfigurations property is a property of the ChannelFactory itself. Simple way to think about it is it represents the data structure that is created when a -stacks.xml is parsed. By writing to that property, a tool can update the configs that will be used for *future* channel creation.
The protocolStackConfiguration property is a piece of read-only information about a running Channel, gotten to indirectly via the openChannels property of the ChannelFactory. It shows actual configuration of the channel.
Stack name isn't a property of a protocol stack configuration because
1) A minor reason is a protocol stack configuration doesn't necessarily have an associated stack_name, since the ChannelFactory exposes an API to create channels from other config resources besides the configs parsed from -stacks.xml. I.e. you can pass in the config directly to createChannel(Object).
2) the type that represents the protocol stack configuration is CollectionMetaValue. It represents org.jgroups.conf.ProtocolData. The data structure is essentially an array and has no place for a stack_name field.
I didn't add a coordinator field to the view because the JGroups View class didn't have one. But, the class javadoc says the first member in the member list is the coordinator, so that's enough of a contract for me to add it. ;) So I will.
Thanks for the link on the JBossHA page!