ClusterPartition vs HAPartition

[brian.stansberry]

Been doing a lot of refactoring, etc. related to ClusterPartition due to using JBoss Cache for state and multiplexer for the Channel.

One thing that is confusing me is the distinction between HAPartition, HAPartitionImpl and ClusterPartition.

HAPartition is a generic interface that is part of the end user API. No problem.

HAPartitionImpl is an internal implementation that uses JGroups as an implementation detail. Again clear.

ClusterPartition though doesn't really seem to be part of an end user API. It's function is just to 1) expose an MBean interface so it can accept config attributes from the deployer and pass them on to HAPartitionImpl and 2) create a JChannel and pass it on the HAPartitionImpl. All of these functions are really just part of the implementation details of HAPartitionImpl. It's not clear to me why it's a separate service.

I'm thinking the way to go here is to combine the ClusterPartition and HAPartitionImpl classes, with the combined class exposing a management interface that extends HAPartition with the implementation specific config attributes. From the end user point of view, the API is still HAPartition.

[starksm64]

The ClusterPartition is just the management ojbect for configuring the HAPartition implementation details. Supporting configuration of the HAPartition Impl via a pojo exposing the dependencies and configuration properties is the way to go. Just make sure to loose the explicit dependency on xml.

[brian.stansberry]

ClusterPartition/HAPartitionImpl will no longer accept an XML element with the JGroups protocol stack. Rather it uses injected refs to a JChannelFactory and the name of the stack config to use. The JChannelFactory is then responsible for providing the channel.

So, the configuration requirements for HAPartitionImpl are pretty simple -- injection of needed services, plus a few primitive properties. Were you talking about a separate configuration pojo largely because of complexity related to the protocol stack config (which no longer exist) or is that a general approach to service configuration that you want in AS 5?

The above doesn't remove the issue of XML-based configuration of JGroups; it just moves it to a different place (the JChannelFactory.) Configuring a JChannel via a POJO is something I'll have to take up with Bela; JBoss Cache is going to need the same kind of thing.