Cycles not detected

[simasch]

slices().matching("ch.jtaf.(*)").should().beFreeOfCycles().check(classes);

does not detect cycle between ch.jtaf.ui and ch.jtaf.security packages.

I assume that the problem is that the cycle comes from a subpackage of ch.jtaf.ui (see attchached image).

[codecholeric]

Ah, I think you need the pattern ch.jtaf.(*).. instead of ch.jtaf.(*). The expression in total is still a package identifier (compare com.tngtech.archunit.base.PackageMatcher), so ch.jtaf.(*) only matches classes that are exactly in those packages, adding the .. will add all sub-packages as well.
Does that help you?

[simasch]

Hi Peter,

Unfortunately the test passes even with this expression:

slices().matching("ch.jtaf.(*)..").should().beFreeOfCycles().check(classes);

[codecholeric]

Do you know how exactly the cycle is formed? I.e. which class from ch.jtaf.ui is depending on ch,jtaf.security and vice versa? ArchUnit still has some missing features that I'm trying to fix at the moment with respect to generic type parameters and method references. So maybe it's one of those causing the cycle? BTW. the most recent version 0.15.0 detects a couple of more occurrences (e.g. generic type parameters and array component types)

[simasch]

You can check it out yourself. It's a public project: https://github.com/72services/jtaf4

These lines of code that produces the cycle:

SecurityContext

 public static boolean isAccessGranted(Class<?> securedClass) {
        final boolean publicView = LoginView.class.equals(securedClass) || DashboardView.class.equals(securedClass)
            || RouteNotFoundError.class.equals(securedClass);

ConfigureUIServiceInitListener

 private void beforeEnter(BeforeEnterEvent event) {
        final boolean accessGranted = SecurityContext.isAccessGranted(event.getNavigationTarget());
        if (!accessGranted) {
            if (SecurityContext.isUserLoggedIn()) {
                event.rerouteToError(AccessDeniedException.class);
            } else {
                event.rerouteTo(LoginView.class);
            }
        }
    }

[codecholeric]

Ah, I see. Yes, the problem is, that for a simple Foo.class.equals(..) there is no trace in the bytecode (at that place) about Foo.class 🤔
Because in the bytecode this is just a call -> java.lang.Class.equals(..). This has already come up in the past, I have to look into it, if it is possible to detect such accesses in a different way 🤔 I just couldn't find a quick way do this with the ASM library yet (because I'm sure there is at least a reference to Foo in the constant pool in such a case, but I haven't seen a way to get this info through the ASM visitor API)

[codecholeric]

@simasch Does the newest release now really detect your cycle? (due to #518) Or is there another issue?

[simasch]

Hi @codecholeric Yes the fix works. Thanks a lot!