Like Paul said, this is intended behavior and is even explicitly stated in the reference documentation here.

When I am in your situation I usually do something slightly different than what Paul suggested:

1. I create a subclass of the LazyConstraintCallback that has a public API that allows querying the current values and adding lazy constraints (basically provide public access to the protected functions getValues() and add()).
2. I register an instance of this class with the IloCplex instance.
3. In the callback's main() I invoke the separation algorithm of the three other classes, passing 'this' as argument.

This way it is pretty simple to write your callbacks in a way so that they can either be used individually or can be combined as a list.

If you want to do that and have trouble implementing it, I can dig out an example from my old code.

Like Paul said, this is intended behavior and is even explicitly stated in the reference documentation here.

When I am in your situation I usually do something slightly different than what Paul suggested:

1. I create a subclass of the LazyConstraintCallback that has a public API that allows querying the current values and adding lazy constraints (basically provide public access to the protected functions getValues() and add()).
2. I register an instance of this class with the IloCplex instance.
3. In the callback's main() I invoke the separation algorithm of the three other classes, passing 'this' as argument.

This way it is pretty simple to write your callbacks in a way so that they can either be used individually or can be combined as a list.

If you want to do that and have trouble implementing it, I can dig out an example from my old code.

import ilog.cplex.IloCplex;import ilog.concert.IloException;import ilog.concert.IloNumVar;import ilog.concert.IloRange;import java.util.Collection;/** Interface that represents a solution. * This could be the current solution at a callback as well as the solution * returned after solve(). */interface Solution {   /** Get the value of a variable.    * @param var The variable to query.    * @return The current value for <code>var</code>.    */   public double getVariableValue(IloNumVar var) throws IloException;}/** Interface for separators. * Separators implement this interface in order to be invoked from the * callback's <code>main()</code> method. */interface Separator {   /** Separate constraints for the current solution represented by    * <code>sol</code>.    * @param sol The current solution.    * @return A (potentially empty) list of violated constraints.    */   public Collection<IloRange> separate(Solution sol) throws IloException;}public class PublicLazyConstraintCallback extends IloCplex.LazyConstraintCallback implements Solution {   private Collection<Separator> separators = new java.util.Vector<Separator>();   public PublicLazyConstraintCallback(Collection<Separator> separators) {      this.separators.addAll(separators);   }   @Override   public double getVariableValue(IloNumVar var) throws IloException {      return getValue(var);   }   public void main() throws IloException {      for (Separator s : separators)         for (IloRange r : s.separate(this))            add(r);   }}​

Like Paul said, this is intended behavior and is even explicitly stated in the reference documentation here.

When I am in your situation I usually do something slightly different than what Paul suggested:

1. I create a subclass of the LazyConstraintCallback that has a public API that allows querying the current values and adding lazy constraints (basically provide public access to the protected functions getValues() and add()).
2. I register an instance of this class with the IloCplex instance.
3. In the callback's main() I invoke the separation algorithm of the three other classes, passing 'this' as argument.

This way it is pretty simple to write your callbacks in a way so that they can either be used individually or can be combined as a list.

If you want to do that and have trouble implementing it, I can dig out an example from my old code.