What are the interoperability rules for AS 5? JIRA http://jira.jboss.com/jira/browse/JBAS-4802 suggests a change to a load balance policy that will break interoperability with earlier releases. Is this impermissible?

Is it permissible to create new (i.e. replacement) load balance policy classes; i.e. require a 4.x client to have them on the classpath?

The JBAS-4802 issue is a simpler aspect of the general problem, since as you say I can just keep the old policy impl around and people can make a config change to revert to the old policy if they want to use older clients.

Trickier is the LoadBalancePolicy interface itself, which unfortunately has this method:

That's the legacy invocation class. Useless method for an AOP-based client. Our standard impls don't currently use this method, but http://jira.jboss.com/jira/browse/JBAS-4455 is a customer feature request that would. Logically, an AOP-based client should support an analogous method, with org.jboss.aop.joinpoint.Invocation as the param type.

I'd like to refactor this into a base interface, and then an AOP-based subinterface, with the existing legacy interface also a subinterface. But, can't really do that since the legacy interface is used extensively in EJB3 client code (in @Clustered, in the bean proxy classes, in the cluster interceptor.) Changing the type used there will break older clients.

What I should be able to do is create a subinterface of the existing LoadBalancePolicy adding

The only place that type would be used would be in the ClusterChooserInterceptor, which could do an instanceof check on the lbp and call the overloaded method if available. That shouldn't break existing clients, since if they have an old version of ClusterChooserInterceptor, they don't have that code.

Yeah, I don't mind that so much; just the way it is. But, the interface that exposes the new invocation model is going to have to extend the interface that uses the old model, which is ugly. Otherwise we break older clients. The LoadBalancePolicy is an instance field in the 4.x EJB3 StatefulClusteredProxy and StatelessClusteredProxy; change the type of the field and serialization will break.

Hmm; will it? If the policy actually serialized with the proxy implements the old interface, will old clients be able to deserialize it? I'll have to test. Unfortunately the proxies don't implement Externalizable; if they did for sure it would work.