An FYI.
I'm about to implement a refactor of load balance policies as discussed on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=120423. Basic goal is to create an LBP interface that doesn't leak the legacy Invocation class into the API. Basically, I'll:
1) Create a clean interface org.jboss.ha.client.loadbalance.LoadBalancePolicy
2) Existing o.j.ha.framework.interfaces.LoadBalancePolicy will extend this base interface to include the legacy methods that leak classes.
3) Will write parallel versions of the standard LBP impls (RoundRobin, etc) that only implement the clean interface. None of them needed the legacy methods to function.
4) Change the type of all references to the legacy interface with the clean interface (e.g. @Clustered, StatefulClusteredBeanProxy, StatelessClusteredBeanProxy, etc.) I've tested that clients with legacy versions of these classes on their classpath will have no trouble deserializing proxies if I do this, as long as the class of the actual serialized LBP impl is available to them.
All this is straightforward enough.
Bit awkward is the handling of the default value for @Clustered.loadBalancePolicy. Currently it's the legacy LoadBalancePolicy interface class. We need to change that to the new interface or we leak the old Invocation class.
Question is what do we do if people leave the default attribute value. A user leaving the default value basically is saying "let the container pick an impl". Currently the container picks the *legacy* impls of RoundRobin or FirstAvailable. Now we have a choice:
1) Pick one of the new impls. This will break existing clients who don't have the new clients on their classpath. (They can easily fix this by putting the new clients on their classpath or by changing their @Clustered annotation to specify the legacy impl).
2) Pick the same legacy impls as before. This forces new clients to include the legacy Invocation classes on their classpath.
My vote is for #1. Any other opinions?
