Detected inconsistency in enter/leave sequence. Must always be LIFO

[LeovR]

I have the following class hierarchy:
https://gist.github.com/LeovR/01580e56aa49f4707b66

And I always get the IllegalArgumentException: Detected inconsistency in enter/leave sequence. Must always be LIFO

[SQiShER]

Thanks for reporting this issue and providing the Gist. That was very helpful!

I added it to the test suite and managed to get rid of the error by changing your exclusion from

... exclude().node(NodePath.with("map", "a")) ...

to

... exclude().propertyName("map").propertyName("a") ...

but I'm not sure, if that's really what you wanted. The node path describes a hierarchical sequence of matching nodes (in this case the property a of property map in the root object.)

The change I made simply excludes all properties called a or map, regardless of their location in the hierarchy. Is that what you actually intended?

[LeovR]

No, unfortunately not.
In my use-case I only want to exclude the "a" within the "map"-path, thus, I think my path is correct.

[SQiShER]

Ok, I see. In that case, the path is almost correct. But NodePath.with("map", "a") would only exclude the property a of a Map object (if maps would be treated like any other object, which they are not), but not of the map entries. What you need is something like

NodePath.startBuilding()
    .propertyName("map")
    .element(/* a custom element selector that simply matches everything */)
    .propertyName("a")
    .build()

However, even that is just a workaround and would only work for this exact path starting from the root object. So it wouldn't apply to objects deeper in the hierarchy.

I'm currently working on an improved inclusion mechanism that allows for much more flexible inclusion rules like the one in your case. Basically I'm going for a way to plug in additional inclusion strategies that receive a DiffNode and can decide on their own whether it should be included or not. But I'm only half way done with it.

You can see the current state on this branch.

[LeovR]

Thanks for the update.

I tried your workaround here: https://gist.github.com/LeovR/6c18712848a77c3f2cd0
I tested whether this would be sufficient for my use-case but I get the same IllegalArgumentException.

[SQiShER]

Can you attach the stack trace?

[LeovR]

java.lang.IllegalArgumentException: Detected inconsistency in enter/leave sequence. Must always be LIFO.
    at de.danielbechler.diff.circular.CircularReferenceDetector.remove(CircularReferenceDetector.java:113)
    at de.danielbechler.diff.differ.DifferDispatcher.forgetInstances(DifferDispatcher.java:178)
    at de.danielbechler.diff.differ.DifferDispatcher.compareWithCircularReferenceTracking(DifferDispatcher.java:150)
    at de.danielbechler.diff.differ.DifferDispatcher.compare(DifferDispatcher.java:133)
    at de.danielbechler.diff.differ.DifferDispatcher.dispatch(DifferDispatcher.java:107)
    at de.danielbechler.diff.ObjectDiffer.compare(ObjectDiffer.java:49)
    at CircularReferenceTest.testCircularReference(CircularReferenceTest.java:120)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

[SQiShER]

Meh, my bad. The element selector approach won't work because of the way the path is resolved internally. Currently the node path is meant to uniquely match exactly one node. Changing that would break a whole lot of other things. Bummer, I always thought of this match-all selector approach to be a pretty neat solution for many theoretical problems, but I never actually tried it.

Alright, so that's not gonna work. But fret not! Turns out the new inclusion mechanism I've been talking about is the perfect solution for your problem. I quickly extended the config API to allow users to register custom so called InclusionResolvers and I tried it on your use case. The solution looks like this:

ObjectDiffer differ = ObjectDifferBuilder.startBuilding()
      .inclusion().resolveUsing(new InclusionResolver() {
  @Override
  Inclusion getInclusion(DiffNode node) {
      if (node.propertyName == "a" &&
              node.parentNode != null &&
              node.parentNode.elementSelector instanceof MapKeyElementSelector &&
              node.parentNode.parentNode != null &&
              node.parentNode.parentNode.propertyName == "map") {
          return Inclusion.EXCLUDED
      }
      return Inclusion.DEFAULT
  }
}).and().build()

As soon as any of the registered resolvers returns EXCLUDED the node will be ignored.

This feature is still in development, but I'm spending every free minute I can find to make it ready for a new release. It would definitely help, if you could take the branch version for a spin and let me know, if it solves the problem in your actual code base.

[LeovR]

The branch version is working in my code base.

my InclusionResolver looks as follows:

new InclusionResolver() {

                    @Override
                    public Inclusion getInclusion(DiffNode node) {
                        if (node.getPropertyName() != null
                                && node.getPropertyName().equals("a")
                                && node.getParentNode() != null
                                && node.getParentNode().getElementSelector() instanceof MapKeyElementSelector
                                && node.getParentNode().getParentNode() != null
                                && node.getParentNode().getParentNode()
                                        .getPropertyName()
                                        .equals("map")) {
                            return Inclusion.EXCLUDED;
                        }
                        return Inclusion.DEFAULT;
                    }
                }

Thanks for the effort.
I'm looking forward to the next release

[ClaudioNazareth]

Hi.. Again!! I'm having the same problem, can u help me to solve?

My classes are

public class GrupoSegurado extends AbstractGrupoSegurado {
//attributes 
}

public abstract class AbstractGrupoSegurado {

//attributes

// I need to compare only these two fields
private AbstractGrupoSegurado grupoPrincipal; // circular reference

private Integer codigo;
}

Using your new build do the following:

final ObjectDifferBuilder builder = ObjectDifferBuilder.startBuilding();        
builder.inclusion().include().propertyNameOfType(GrupoSegurado.class, "grupoPrincipal");
builder.inclusion().include().propertyNameOfType(GrupoSegurado.class, "codigo");

and e get de error:

Caused by: java.lang.IllegalArgumentException: Detected inconsistency in enter/leave sequence. Must always be LIFO.
    at de.danielbechler.diff.circular.CircularReferenceDetector.remove(CircularReferenceDetector.java:113)
    at de.danielbechler.diff.differ.DifferDispatcher.forgetInstances(DifferDispatcher.java:178)
    at de.danielbechler.diff.differ.DifferDispatcher.compareWithCircularReferenceTracking(DifferDispatcher.java:150)
    at de.danielbechler.diff.differ.DifferDispatcher.compare(DifferDispatcher.java:133)
    at de.danielbechler.diff.differ.DifferDispatcher.dispatch(DifferDispatcher.java:107)
    at de.danielbechler.diff.ObjectDiffer.compare(ObjectDiffer.java:49)

How i use the InclusionResolver in my problem ?

Thx

[SQiShER]

@LeovR Awesome! Glad I could help!

[SQiShER]

@ClaudioNazareth @LeovR Thanks for pointing the "Detected inconsistency in enter/leave sequence. Must always be LIFO." out to me. I never really expected this exception to be thrown. So after some digging, I actually found a nasty, nasty bug in the DifferDispatcher that was most likely the cause of the exception in both of your cases. (Although we somehow managed to make the bug go away for @LeovR, by fiddling with the inclusion rules.) I pushed the changes onto the type-based-inclusion branch for you to try.

@ClaudioNazareth: Please let me know if the branch version solves your problem.