Stack overflow on recursive types (again)

[xRodney]

Describe the bug

Hi,

Unfortunately, even after the recent fixes for multimaps, keycloak-operator CRD still does not compile, it still fails with StackOverflowError.
But the stack trace is different this time, and is not connected with multimaps.

This can be reproduced on current master (to be 6.2)

Fabric8 Kubernetes Client version

SNAPSHOT

Steps to reproduce

I have been able to reproduce the issue in a unit test:

@Group("sample.fabric8.io")
@Version("v1alpha1")
public class Cyclic extends CustomResource<CyclicSpec, CyclicStatus> implements Namespaced {
}

public class CyclicSpec {
  private List<Ref> ref;
}

public class Ref {
  private List<Ref> ref;
}

You will probably recognize this as a variation of an existing test. But the existing test has both fields as of simple Ref type, not List<Ref>. It turns out, both Lists are necessary for the Stack Overflow to occur.

Expected behavior

Definitely no StackOverflow.
If the field is otherwise unannotated, I expect to get an error telling me about cyclic references.
But I should be able to use @JsonIgnore, @SchemaFrom or @SchemaSwap to exclude the field from generation or replace it with another type.

Runtime

other (please specify in additional context)

Kubernetes API Server version

other (please specify in additional context)

Environment

other (please specify in additional context)

Fabric8 Kubernetes Client Logs

No response

Additional context

The stack overflow happens in class ClassDependenciesVisitor:

// process all references to see if they need to be added or not
    type.getReferences().forEach(c -> {
      final String fqn = c.getFullyQualifiedName();
      if (ignore(fqn)) {
        return;
      }

      // check if we're dealing with a collection type to extract parameter types if existing
      if (fqn.startsWith("java.util") && (Collections.isCollection(c) || Collections.IS_MAP.apply(c))) {
        c.getArguments().forEach(this::processTypeRef);    // <<<<<<<<<<<<<<<<<<<< HERE
      } else {
        // otherwise, process all non-JDK classes that we haven't already processed
        if (!ignore(fqn) && classesForCR.add(fqn)) {
          // deal with generic arguments if present
          c.getArguments().forEach(this::processTypeRef);
        }
      }
    });

This visitor, it appears, is only used for tests / debugging purposes. The problematic portion can be simplified (or just commented out) and after necessary @SchemaSwaps, the keycloak CRD finally generates.

Unfortunately, as it stands now, the end users cannot work this around using @SchemaSwaps or similar, because the SO happens in a code path that ignores these annotations.