AS 5 interoperability rules

[brian.stansberry]

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?

[adrian.brock]

Why don't you just create a "FirstAvailable2" policy and make it the default,
then people can revert to the old policy if they want to use older clients.

You can even backport FirstAvailable2 to earlier branches in future releases
to minimize the problem.

[brian.stansberry]

Thanks. :-) That's what I meant by "new (i.e. replacement) load balance policy classes" but I worded it badly by throwing in "replacement".

[brian.stansberry]

Thinking out loud a bit here, so feel free to ignore me... :-)

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:

public Object chooseTarget (FamilyClusterInfo clusterFamily,
org.jboss.invocation.Invocation routingDecision);

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

public Object chooseTarget (FamilyClusterInfo clusterFamily,
org.jboss.aop.joinpoint.Invocation invocation);

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.

I'll also deprecate the method with the legacy Invocation class.

[adrian.brock]

You need two different versions of the load balancing policy
for the two different invocation models.

The legacy EJB2 invocation is not going away anytime soon.

At least until JavaEE drops support for the old EJB model or our EJB3 project takes
over implementing the old model.

[brian.stansberry]

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.