Recursive Method Lookup (Java)

[wdahlenburg]

I'd like to be able to query all method invocation chains in a recursive query from a starting point.

I'm able to get a single lookup, but I'm looking for some advice on how to recursively perform the lookup.

---

In my example, I'm looking to query every Spring Bean defined in a database and identify the methods without arguments. I'd like to then recursively query the return types of those methods and see what methods without arguments can be called. Ideally the output would be in a bean.method.method.method format.

class NoArgMethod extends Method {
    NoArgMethod() {
      exists(Method m |
        m.hasNoParameters()
        and m = this
      )
    }
}
  
class Bean extends Method {
    string identifier;
    Bean() {
        exists(Annotation a | this.getAnAnnotation() = a |
        a.getType().hasQualifiedName("org.springframework.context.annotation", "Bean") and
        if a.getValue("name") instanceof StringLiteral
        then identifier = a.getValue("name").(StringLiteral).getValue()
        else identifier = this.getName()
        )
    }

    /**
     * Gets this bean's name if given by the `Bean` annotation, or this method's identifier otherwise.
     */
    string getBeanIdentifier() { result = identifier }
}

from Bean bean, NoArgMethod m
where bean.getReturnType().(RefType).getAMethod() = m
select bean.getName() + "." + m.getName()

For example on a bean returning a String type, I'd expect to see the getBytes, hashCode, intern, isEmpty, length, toCharArray, toLowerCase, toString, toUpperCase, and trim methods along with clone, finalize, getClass, notify, notifyAll, and wait methods from the Object class.

Spring defines a sample Bean here at 2.2.3.3.

public class Foo {
    public void init() {
        // initialization logic
    }
}
public class Bar {
    public void cleanup() {
        // destruction logic
    }
}
@Configuration
public class AppConfig {
    @Bean(initMethodName="init")
    public Foo foo() {
        return new Foo();
    }
    @Bean(destroyMethodName="cleanup")
    public Bar bar() {
        return new Bar();
    }
}

I'd expect to see foo.init and bar.cleanup along with all of the Object methods. If the Foo or Bar class defined additional methods, then I'd want to recursively grab the methods on their return types as well.

[edoardopirovano]

Greetings, thanks for getting in touch with this question! Would something similar to the following (adapted to handle your specific use-case of beans rather than just any method) do what you need:

class NoArgMethod extends Method {
  NoArgMethod() { this.hasNoParameters() }

  NoArgMethod getNextStep() { result = this.getReturnType().(RefType).getAMethod() }
}

from NoArgMethod m1, NoArgMethod m2
where m1.getNextStep+() = m2
select m1.getName() + " calls " + m2.getName()

In particular, what this is doing is pulling out the logic of going one step further in the search into the getNextStep predicate. Then we can use the + operator to indicate that we want everything that is reachable in one or more applications of getNextStep.

This doesn't quite satisfy your requirement for the output to be in bean.method1.method2... format, but I'm not sure that's possible to write in CodeQL. The issue with writing that is that there may well be an infinite amount of such chains (for instance bean.clone.clone.clone is valid for any number of repeats of clone), whereas results of CodeQL queries have to be finite.

[wdahlenburg]

Thanks @edoardopirovano for the explanation. I haven't seen the + operator used before, which is certainly helpful.

I was able keep the format by extending the query to:

from Bean bean, NoArgMethod m1, NoArgMethod m2
where bean.getReturnType().(RefType).getAMethod() = m1 and m1.getNextStep+() = m2
select bean.getName() + "." + m1.getName() + "." + m2.getName()

I also confirmed that I could query additional NoArgMethod calls by chaining the getNextStep+() functions -> and m2.getNextStep+() = m3 .... As expected, the potential calls grow pretty quickly as additional methods are queried. A few iterations was sufficient for what I was looking for.