spring cloud gateway herunterladen - spring cloud gateway Quellcode herunterladen

spring cloud gateway

JAVA-Quellcode

4.2.0

Herunterladen

Merkmale

Java 17
Frühlings-Framework 6
Spring Boot 3
Dynamisches Routing
In Spring Handler Mapping integrierter Routenabgleich
Routenabgleich bei HTTP-Anfrage (Pfad, Methode, Header, Host usw.)
Auf Matching Route beschränkte Filter
Filter können Downstream-HTTP-Anfragen und HTTP-Antworten ändern (Header hinzufügen/entfernen, Parameter hinzufügen/entfernen, Pfad neu schreiben, Pfad festlegen, Hystrix usw.)
API- oder konfigurationsgesteuert
Unterstützt Spring Cloud DiscoveryClient zum Konfigurieren von Routen

Gebäude

Ungelöste Direktive in <stdin> – include::https:///raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/docs/modules/ROOT/partials/building.adoc[]

Mitwirken

Spring Cloud wird unter der nicht restriktiven Apache 2.0-Lizenz veröffentlicht und folgt einem sehr standardmäßigen Github-Entwicklungsprozess, bei dem Github-Tracker für Probleme verwendet und Pull-Anfragen in Main zusammengeführt werden. Wenn Sie auch nur etwas Triviales beitragen möchten, zögern Sie bitte nicht, sondern befolgen Sie die nachstehenden Richtlinien.

Unterzeichnen Sie die Mitwirkenden-Lizenzvereinbarung

Bevor wir eine nicht triviale Patch- oder Pull-Anfrage annehmen, müssen Sie die Lizenzvereinbarung für Mitwirkende unterzeichnen. Die Unterzeichnung der Mitwirkendenvereinbarung gewährt niemandem Rechte am Hauptrepository, bedeutet aber, dass wir Ihre Beiträge annehmen können und Sie in diesem Fall eine Urheberangabe erhalten. Aktive Mitwirkende werden möglicherweise gebeten, dem Kernteam beizutreten, und erhalten die Möglichkeit, Pull-Anfragen zusammenzuführen.

Verhaltenskodex

Dieses Projekt hält sich an den Verhaltenskodex des Contributor Covenant. Durch Ihre Teilnahme wird von Ihnen erwartet, dass Sie diesen Kodex einhalten. Bitte melden Sie inakzeptables Verhalten an [email protected].

Kodexkonventionen und Housekeeping

Nichts davon ist für eine Pull-Anfrage unbedingt erforderlich, aber sie werden alle hilfreich sein. Sie können auch nach der ursprünglichen Pull-Anfrage, aber vor einer Zusammenführung hinzugefügt werden.

Verwenden Sie die Codeformatkonventionen des Spring Framework. Wenn Sie Eclipse verwenden, können Sie Formatierungseinstellungen mithilfe der Datei eclipse-code-formatter.xml aus dem Spring Cloud Build-Projekt importieren. Wenn Sie IntelliJ verwenden, können Sie das Eclipse Code Formatter Plugin verwenden, um dieselbe Datei zu importieren.
Stellen Sie sicher, dass alle neuen .java -Dateien einen einfachen Javadoc-Klassenkommentar mit mindestens einem @author -Tag zur Identifizierung Ihrer Person und vorzugsweise mindestens einem Absatz darüber haben, wofür die Klasse gedacht ist.
Fügen Sie den ASF-Lizenz-Header-Kommentar zu allen neuen .java Dateien hinzu (kopieren Sie ihn aus vorhandenen Dateien im Projekt).
Fügen Sie sich selbst als @author zu den .java-Dateien hinzu, die Sie erheblich ändern (mehr als nur kosmetische Änderungen).
Fügen Sie einige Javadocs und, wenn Sie den Namespace ändern, einige XSD-Dokumentelemente hinzu.
Ein paar Unit-Tests würden auch sehr helfen – jemand muss es tun.
Wenn niemand sonst Ihren Zweig verwendet, stellen Sie ihn bitte auf den aktuellen Hauptzweig (oder einen anderen Zielzweig im Hauptprojekt) um.
Befolgen Sie beim Schreiben einer Commit-Nachricht bitte diese Konventionen. Wenn Sie ein bestehendes Problem beheben, fügen Sie bitte Fixes gh-XXXX am Ende der Commit-Nachricht hinzu (wobei XXXX die Problemnummer ist).

Karostil

Spring Cloud Build enthält eine Reihe von Checkstyle-Regeln. Sie finden sie im Modul spring-cloud-build-tools . Die bemerkenswertesten Dateien unter dem Modul sind:

spring-cloud-build-tools/

 └── src
   ├── Karostil
   │ └── checkstyle-suppressions.xml (3)
   └── Haupt
   └── Ressourcen
   ├── checkstyle-header.txt (2)
   └── checkstyle.xml (1)

Standard-Checkstyle-Regeln
Datei-Header-Setup
Standardunterdrückungsregeln

Checkstyle-Konfiguration

Checkstyle-Regeln sind standardmäßig deaktiviert . Um Ihrem Projekt Checkstyle hinzuzufügen, definieren Sie einfach die folgenden Eigenschaften und Plugins.

pom.xml

 <Eigenschaften>
<maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1)
        <maven-checkstyle-plugin.failsOnViolation>true
        </maven-checkstyle-plugin.failsOnViolation> (2)
        <maven-checkstyle-plugin.includeTestSourceDirectory>true
        </maven-checkstyle-plugin.includeTestSourceDirectory> (3)
</properties>

<Build>
        <Plugins>
            <plugin> (4)
                <groupId>io.spring.javaformat</groupId>
                <artifactId>spring-javaformat-maven-plugin</artifactId>
            </plugin>
            <plugin> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>

    <Berichterstattung>
        <Plugins>
            <plugin> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>
    </reporting>
</build>

Der Build schlägt aufgrund von Checkstyle-Fehlern fehl
Der Build schlägt aufgrund von Checkstyle-Verstößen fehl
Checkstyle analysiert auch die Testquellen
Fügen Sie das Spring Java Format-Plugin hinzu, das Ihren Code neu formatiert, um die meisten Checkstyle-Formatierungsregeln zu erfüllen
Fügen Sie das Checkstyle-Plugin zu Ihren Build- und Berichtsphasen hinzu

Wenn Sie einige Regeln unterdrücken müssen (z. B. muss die Zeilenlänge länger sein), dann reicht es aus, wenn Sie unter ${project.root}/src/checkstyle/checkstyle-suppressions.xml eine Datei mit Ihren Unterdrückungen definieren. Beispiel:

projectRoot/src/checkstyle/checkstyle-suppresions.xml

 <?xml version="1.0"?>
<!DOCTYPE unterdrückt PUBLIC
		"-//Puppy Crawl//DTD Suppressions 1.1//EN"
		„https://www.puppycrawl.com/dtds/suppressions_1_1.dtd“>
<Unterdrückungen>
	<suppress files=".*ConfigServerApplication.java" checks="HideUtilityClassConstructor"/>
	<suppress files=".*ConfigClientWatch.java" checks="LineLengthCheck"/>
</suppressions>

Es empfiehlt sich ${spring-cloud-build.rootFolder}/.editorconfig und ${spring-cloud-build.rootFolder}/.springformat in Ihr Projekt zu kopieren. Auf diese Weise werden einige Standardformatierungsregeln angewendet. Sie können dies tun, indem Sie dieses Skript ausführen:

$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/.editorconfig -o .editorconfig
$ touch .springformat

IDE-Setup

Intellij-IDEE

Um Intellij einzurichten, sollten Sie unsere Codierungskonventionen und Inspektionsprofile importieren und das Checkstyle-Plugin einrichten. Die folgenden Dateien finden Sie im Spring Cloud Build-Projekt.

spring-cloud-build-tools/

 └── src
   ├── Karostil
   │ └── checkstyle-suppressions.xml (3)
   └── Haupt
   └── Ressourcen
   ├── checkstyle-header.txt (2)
   ├── checkstyle.xml (1)
   └── intellij
     ├── Intellij_Project_Defaults.xml (4)
     └── Intellij_Spring_Boot_Java_Conventions.xml (5)

Standard-Checkstyle-Regeln
Datei-Header-Setup
Standardunterdrückungsregeln
Projektstandards für Intellij, die die meisten Checkstyle-Regeln anwenden
Projektstilkonventionen für Intellij, die die meisten Checkstyle-Regeln anwenden

Abbildung 1. Codestil

Gehen Sie zu File → Settings → Editor → Code style . Klicken Sie dort auf das Symbol neben dem Abschnitt Scheme . Klicken Sie dort auf den Wert Import Scheme und wählen Sie die Option Intellij IDEA code style XML aus. Importieren Sie die Datei spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml .

Abbildung 2. Inspektionsprofile

Gehen Sie zu File → Settings → Editor → Inspections . Klicken Sie dort auf das Symbol neben dem Abschnitt Profile . Klicken Sie dort auf das Import Profile und importieren Sie die Datei spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml .

Karostil

Damit Intellij mit Checkstyle funktioniert, müssen Sie das Checkstyle Plugin installieren. Es empfiehlt sich, auch Assertions2Assertj zu installieren, um die JUnit-Assertionen automatisch zu konvertieren

Gehen Sie zu File → Settings → Other settings → Checkstyle . Klicken Sie dort im Abschnitt Configuration file auf das + -Symbol. Dort müssen Sie definieren, woher die Checkstyle-Regeln ausgewählt werden sollen. Im Bild oben haben wir die Regeln aus dem geklonten Spring Cloud Build-Repository ausgewählt. Sie können jedoch auf das GitHub-Repository von Spring Cloud Build verweisen (z. B. für checkstyle.xml : https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle.xml ). Wir müssen die folgenden Variablen bereitstellen:

checkstyle.header.file – verweisen Sie bitte auf die Datei spring-cloud-build-tools/src/main/resources/checkstyle-header.txt von Spring Cloud Build, entweder in Ihrem geklonten Repository oder über https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt URL.
checkstyle.suppressions.file – Standardunterdrückungen. Bitte verweisen Sie auf die Datei spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml von Spring Cloud Build, entweder in Ihrem geklonten Repository oder über https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml URL.
checkstyle.additional.suppressions.file – diese Variable entspricht Unterdrückungen in Ihrem lokalen Projekt. Sie arbeiten beispielsweise an spring-cloud-contract . Zeigen Sie dann auf den Ordner project-root/src/checkstyle/checkstyle-suppressions.xml . Ein Beispiel für spring-cloud-contract wäre: /home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml .

Wichtig

Denken Sie daran, den Scan Scope auf All sources festzulegen, da wir Checkstyle-Regeln für Produktions- und Testquellen anwenden.

Duplikat-Finder

Spring Cloud Build bringt das basepom:duplicate-finder-maven-plugin mit, das die Kennzeichnung doppelter und widersprüchlicher Klassen und Ressourcen im Java-Klassenpfad ermöglicht.

Doppelte Finder-Konfiguration

Der Duplikat-Finder ist standardmäßig aktiviert und wird in der verify Ihres Maven-Builds ausgeführt. Er wird jedoch nur dann in Ihrem Projekt wirksam, wenn Sie das duplicate-finder-maven-plugin zum build Abschnitt der pom.xml des Projekts hinzufügen.

pom.xml

< build >
    < plugins >
        < plugin >
            < groupId >org.basepom.maven</ groupId >
            < artifactId >duplicate-finder-maven-plugin</ artifactId >
        </ plugin >
    </ plugins >
</ build >

Für andere Eigenschaften haben wir die in der Plugin-Dokumentation aufgeführten Standardwerte festgelegt.

Sie können sie leicht überschreiben, indem Sie den Wert der ausgewählten Eigenschaft mit dem Präfix duplicate-finder-maven-plugin festlegen. Setzen Sie beispielsweise duplicate-finder-maven-plugin.skip auf true um die Duplikatprüfung in Ihrem Build zu überspringen.

Wenn Sie ignoredClassPatterns oder ignoredResourcePatterns zu Ihrem Setup hinzufügen müssen, stellen Sie sicher, dass Sie diese im Abschnitt „Plugin-Konfiguration“ Ihres Projekts hinzufügen:

< build >
    < plugins >
        < plugin >
            < groupId >org.basepom.maven</ groupId >
            < artifactId >duplicate-finder-maven-plugin</ artifactId >
            < configuration >
                < ignoredClassPatterns >
                    < ignoredClassPattern >org.joda.time.base.BaseDateTime</ ignoredClassPattern >
                    < ignoredClassPattern >.*module-info</ ignoredClassPattern >
                </ ignoredClassPatterns >
                < ignoredResourcePatterns >
                    < ignoredResourcePattern >changelog.txt</ ignoredResourcePattern >
                </ ignoredResourcePatterns >
            </ configuration >
        </ plugin >
    </ plugins >
</ build >