Wie man ein Guice-Abhängigkeitsinjektionsproblem abfängt und behebt, indem man Sensei

Das Sensei Projekt selbst hat seine eigene Reihe von Rezepten, die sich im Laufe der Zeit aufgebaut haben. Dieser Blog-Beitrag ist ein Beispiel für eines der Szenarien, für die das Sensei -Team ein Rezept erstellt hat. Eine Fehlkonfiguration von Guice, die dazu führte, dass zur Laufzeit beim Testen eine NullPointerException gemeldet wurde.

Dies kann auf viele Dependency-Injection-Szenarien verallgemeinert werden, in denen der Code syntaktisch korrekt ist, aber aufgrund einer falschen Konfiguration der Verdrahtung ein Fehler durchschlüpft.

Das passiert oft, wenn wir die Technologie lernen, und wir machen immer wieder den einfachen Fehler, dass wir vergessen, Dinge zu verdrahten. Aber das passiert auch erfahrenen Profis, denn, nun ja... wir alle machen Fehler, und wir haben vielleicht keine Unit-Tests, die alles abdecken.

Laufzeitausnahmen durch fehlerhafte Dependency Injection-Verdrahtung

Der folgende Code schlägt zur Laufzeit mit einer NullPointerException fehl.

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

Der Code ist syntaktisch korrekt, schlägt aber fehl, weil wir eine requestStaticInjection in unserer SystemOutModule-Konfiguration ausgelassen haben.

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

Wenn wir versuchen, den mit dem Injector erstellten Reporter zu verwenden, wird er nicht vollständig instanziiert und wir erhalten eine NullPointerException, wenn wir reportThisMany aufrufen.

Es kann gut sein, dass wir das in unserem Code-Review übersehen haben, oder wir hatten keine Unit-Tests, die die Dependency Injection ausgelöst haben, und es ist in unserem Build herausgerutscht.

‍

Warnschilder

In diesem Fall gibt es ein Warnzeichen, der CountReporter hat ein statisches Feld, das mit @Inject annotiert ist, aber... die CountReporter-Klasse selbst ist package private.

In einer komplizierten Codebasis könnte dies ein Warnzeichen dafür sein, dass der Code nicht korrekt ist, da die Modulklasse, die die Bindungen konfiguriert, im selben Paket sein muss, damit dies funktioniert.

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

Ein weiterer Fehler, der uns unterlaufen ist und den wir vielleicht bei einer Codeüberprüfung festgestellt haben, ist, dass wir vergessen haben, die Felder in der Konfigurationsmethode des SystemOutModule tatsächlich zu binden.

binder().requestStaticInjection(CountReporter.class);

Hätten wir den requestStaticInjection-Code geschrieben, dann hätte uns der Syntaxfehler, der beim Versuch, den CountReporter zu verwenden, generiert wird, auf den einfachen Fehler aufmerksam gemacht.

> 'reporters.CountReporter' ist nicht öffentlich in 'reporters'. Kann nicht von außerhalb des Pakets aufgerufen werden

‍

Traurig. Wir haben es vergessen, und es gab keine syntaktischen Warnzeichen im Code.

Wie kann Sensei helfen?

Wir würden wahrscheinlich nicht Sensei verwenden, um die fehlende requestStaticInjection zu übernehmen, da alle unsere Guice-Konfigurationsverdrahtungen diese Methode verwenden müssten, und wir können nicht garantieren, dass alle Verdrahtungen so einfach sein werden wie dieser Anwendungsfall.

Wir könnten eine Sensei Regel schreiben, um nach einigen Warnzeichen zu suchen, dass unser Code nicht den Anforderungen entspricht.

In diesem Fall würde das bedeuten:

• Suchen Sie alle Klassen mit @Inject-kommentierten Feldern
• Wo die Klassen nicht öffentlich sind.

Das oben genannte war das Warnzeichen, dass sie wahrscheinlich nicht verkabelt waren.

Indem wir ein Rezept erstellen, haben wir ein Warnzeichen in einem frühen Stadium, während der Codierung, und reduzieren die Abhängigkeit von unseren Pull-Requests oder der Lösung unserer Tech Debt, damit wir Unit Tests hinzufügen können.

Wie erstellt man ein Rezept?

Die Aufgabe, die ich erledigen möchte, ist:

• Erstellen eines Rezepts, das mit @Inject annotierte Felder abgleicht, die sich in geschützten privaten Klassen befinden

Das sollte uns hoffentlich genug Warnung geben, um alle Module zu identifizieren, die dies verwenden, und den fehlenden Verdrahtungscode hinzuzufügen.

In meiner CountReporter-Klasse werde ich mit Alt+Enter ein neues Rezept erstellen und bei Null anfangen

Ich werde dies benennen und eine Beschreibung hinzufügen:

Name: Guice: Injected Field Not Public
Beschreibung: Wenn das Injected-Feld nicht öffentlich ist, ist der Code möglicherweise nicht verdrahtet
Level: Warnung

Die Suche, die ich schreibe, sucht nach einer Klasse mit einem Feld, das als Inject annotiert ist, aber nicht als public gescoped wurde.

search:
field:
with:
annotation:
type: "com.google.inject.Inject"
in:
class:
without:
modifier: "public"

Fix

Der QuickFix im Rezept ändert die injizierte Klasse, indem er den Bereich ändert. Aber das ist nicht der einzige Code, den ich ändern muss.

availableFixes:

- name: "Klasse auf public ändern. Remember to also request injection on this class"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"

Wenn das Rezept ausgelöst wird, muss ich noch einen manuellen Schritt in meinem Code durchführen, indem ich die Zeile mit requestStaticInjection hinzufüge, um das Objekt vollständig zu instanziieren.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

Ich könnte möglicherweise ein weiteres Rezept schreiben, um dies aufzugreifen. Ich würde das wahrscheinlich nicht tun, es sei denn, das Vergessen, die statische Injektion hinzuzufügen, wird zu einem halbwegs regelmäßigen Fehler, den ich beim Kodieren mache.

‍

Zusammenfassung

Wenn wir jemals einen Fehler mit einem häufigen Grundmuster machen, dann kann Sensei helfen, das Wissen um die Erkennung und Behebung des Problems zu kodifizieren, und dann wird es hoffentlich nicht durch die Code-Reviews und in die Produktion rutschen.

Manchmal identifizieren die Rezepte, die wir schreiben, heuristische Muster, d. h. eine Übereinstimmung garantiert nicht, dass es ein Problem gibt, aber es ist wahrscheinlich, dass es ein Problem gibt.

Außerdem müssen die Rezepte und QuickFixes, die wir schreiben, nicht vollständig umfassend sein. Sie müssen gut genug sein, dass sie uns helfen, Probleme zu identifizieren und zu beheben, ohne dabei übermäßig kompliziert zu sein. Denn wenn sie zu kompliziert werden, werden sie schwieriger zu verstehen und schwerer zu warten.

---

Sie können Sensei aus IntelliJ heraus über "Preferences \ Plugins" (Mac) oder "Settings \ Plugins" (Windows) installieren und dann einfach nach "sensei secure code" suchen.

Den Quellcode und die Rezepte für diesen Beitrag finden Sie im Repository "sensei-blog-examples" im GitHub-Konto Secure Code Warrior , im Modul "guiceexamples".

https://github.com/securecodewarrior/sensei-blog-examples

Erfahren Sie mehr über Sensei