Issues with EJB2 ClusterConfigMetaData

[brian.stansberry]

Been chasing down EJB2 clustering testsuite failures, which got me looking into handling of org.jboss.metadata.ejb.jboss.ClusterConfigMetaData. Found a few things:

1) Class exposes properties home(bean)LoadBalancingPolicy. DTD says they should be home(bean)LoadBalancePolicy (Balance not Balancing).

That's a simple fix I've already made in my workspace; please advise if I should check it in; don't want to step on people.

2) The way ClusterConfigMetaData.determineHome(Bean)LoadBalancingPolicy() work, you only get the default policy if you added a cluster-config element to your bean declaration in jboss.xml. If the ClusterConfigMetaData came from a container-configuration, you *don't* get any default. You get null unless the value was specifically set in the relevant container-configuration/cluster-config element. This leads to test failures. A simple workaround to fix the test failures is to add the default policies to standardjboss.xml.

3) (I could be wrong about this; haven't tested, just looked at code. So, take this as more about how it should work). If you do something like this:

In jboss.xml:

<!-- A clustered SLSB -->
<session>
 ... ...
 <clustered>true</clustered>
 <cluster-config>
 <partition-name>MyPartition</partition-name>
 </cluster-config>
</session>

In standardjboss.xml:

<container-configuration>
 <container-name>Clustered Stateless SessionBean</container-name>
 ... ...
 <cluster-config>
 <partition-name>${jboss.partition.name:DefaultPartition}</partition-name>
 <!-- Use RANDOM ROBIN!!! -->
 <home-load-balance-policy>
 org.jboss.ha.framework.interfaces.RandomRobin
 </home-load-balance-policy>
 <bean-load-balance-policy>
 org.jboss.ha.framework.interfaces.RoundRobin
 </bean-load-balance-policy>
 </cluster-config>
</container-configuration>

Your bean will end up using RoundRobin instead of RandomRobin. AFAICT, the code checks the bean's config, and if not set goes to a hard coded default.

Wouldn't it be better to pull the default from the container-configuration? If that's agreeable I can do that.

4) If yes to last question, that suggests there shouldn't be a hard coded default at all; the defaults should come from a container-configuration, ultimately from standardjboss.xml.

[starksm64]

1) Class exposes properties home(bean)LoadBalancingPolicy. DTD says they should be home(bean)LoadBalancePolicy (Balance not Balancing).

That's a simple fix I've already made in my workspace; please advise if I should check it in; don't want to step on people.

fine, in the metdata project right?

2) The way ClusterConfigMetaData.determineHome(Bean)LoadBalancingPolicy() work, you only get the default policy if you added a cluster-config element to your bean declaration in jboss.xml. If the ClusterConfigMetaData came from a container-configuration, you *don't* get any default. You get null unless the value was specifically set in the relevant container-configuration/cluster-config element. This leads to test failures. A simple workaround to fix the test failures is to add the default policies to standardjboss.xml.

The default really should come from the container config. There still is too much logic in the ClusterConfigMetaData, and in fact I don't think we should be associating the ClusterConfigMetaData with a JBossEnterpriseBeanMetaData instance to figure out defaults based on bean type. We need a merge(ClusterConfigMetaData) added to ClusterConfigMetaData to merged the standardjboss.xml config into a partial jboss.xml config.

3) (I could be wrong about this; haven't tested, just looked at code. So, take this as more about how it should work). If you do something like this:
...
Your bean will end up using RoundRobin instead of RandomRobin. AFAICT, the code checks the bean's config, and if not set goes to a hard coded default.

Wouldn't it be better to pull the default from the container-configuration? If that's agreeable I can do that.

4) If yes to last question, that suggests there shouldn't be a hard coded default at all; the defaults should come from a container-configuration, ultimately from standardjboss.xml.

Yes, we need to get the metadata to be a standalone description of the configuration with no logic regarding defaults if possible.

[brian.stansberry]

1) Class exposes properties home(bean)LoadBalancingPolicy. DTD says they should be home(bean)LoadBalancePolicy (Balance not Balancing).

That's a simple fix I've already made in my workspace; please advise if I should check it in; don't want to step on people.

fine, in the metdata project right?

Yes.

2) The way ClusterConfigMetaData.determineHome(Bean)LoadBalancingPolicy() work, you only get the default policy if you added a cluster-config element to your bean declaration in jboss.xml. If the ClusterConfigMetaData came from a container-configuration, you *don't* get any default. You get null unless the value was specifically set in the relevant container-configuration/cluster-config element. This leads to test failures. A simple workaround to fix the test failures is to add the default policies to standardjboss.xml.

The default really should come from the container config. There still is too much logic in the ClusterConfigMetaData, and in fact I don't think we should be associating the ClusterConfigMetaData with a JBossEnterpriseBeanMetaData instance to figure out defaults based on bean type. We need a merge(ClusterConfigMetaData) added to ClusterConfigMetaData to merged the standardjboss.xml config into a partial jboss.xml config.

Good. I'll do it this way and get rid of defaults.

[brian.stansberry]

JIRA is http://jira.jboss.com/jira/browse/JBAS-4947 .

Trivial bit about the property name is checked in. Please let me know next time you update the snapshot in the repository; once that change is in I'll add default load balance policy elements to standardjboss.xml.

[starksm64]

The metadata snapshot has been updated with these changes.