Vorwort
Bevor der Text beginnt, machen wir einen kleinen Test. Angenommen, wir kapseln einen Springboot-Starter und sein automatischer Zusammenbautyp ist wie folgt
@Configuration
@EnableConfigurationProperties({
ApolloRefreshProperties.class})
public class ApolloRefreshAutoConfiguration {
@Bean
@ConditionalOnMissingBean
@ConditionalOnClass({
ConfigService.class})
public ApolloRefreshService apolloRefreshService(ApolloRefreshProperties properties) {
return new ApolloRefreshService(properties);
}
}
Das im Starter-Pom eingeführte Apollo-Gav ist optional
<dependency>
<groupId>com.ctrip.framework.apollo</groupId>
<artifactId>apollo-client</artifactId>
<version>${apollo-client.version}</version>
<optional>true</optional>
</dependency>
meine Frage ist
Wird es Probleme geben, wenn der oben genannte Starter in der laufenden Umgebung in das jdk8-Springboot-Projekt eingeführt wird?
Wir führen es aus und stellen fest, dass es angezeigt wird.
Dann ändern wir keine Codezeile, passen das JDK auf Version 11 oder höher an und führen dann
das Projekt aus, um es erfolgreich auszuführen. Dann besteht unser erster Reparaturinstinkt darin, die Version von JDK8 zu erhöhen.
Ein Mitglied unseres Teams machte das Gleiche zum ersten Mal. Er ging mit dem technischen Leiter des Geschäftsteams in Kontakt, um zu sehen, ob er JDK8 an JDK11 anpassen könne. Dann erhielt er vom technischen Leiter des Geschäftsteams eine klare Absage Da die meisten ihrer Geschäfte auf JDK8 laufen und vorschnell auf JDK11 aktualisiert werden, weiß ich nicht, ob andere Probleme eingeführt werden, nur um ein Problem zu lösen.
Fehlerbehebung
Da der Inhalt der automatischen Montagekonfiguration dieses Starters relativ einfach ist, basierend auf dem sechsten Sinn des erfahrenen Fahrers, tritt das Problem wahrscheinlich in der Annotation @ConditionalOnClass auf. Daher habe ich auf @ConditionalOnClass geklickt und die folgende Eingabeaufforderung angezeigt zu seiner Annotation. Seine allgemeine Idee war
, dass value() sicher in @Configuration-Klassen angegeben werden kann, da die Annotationsmetadaten mithilfe von ASM analysiert werden, bevor die Klasse geladen wird. Bei der Platzierung von @Bean-Methoden ist besondere Vorsicht geboten. Erwägen Sie die Isolierung von Bedingungen in einer separaten Konfigurationsklasse, insbesondere wenn der Rückgabetyp der Methode mit dem Ziel der Bedingung übereinstimmt. Wenn Sie Methodenanmerkungen verwenden müssen, wird empfohlen, das Namensfeld in ConditionalOnClass zu verwenden.
Also haben wir auf den offiziellen Rat gehört und den Anlasser wie folgt eingestellt
@Configuration
@EnableConfigurationProperties({
ApolloRefreshProperties.class})
public class ApolloRefreshAutoConfiguration {
@Bean
@ConditionalOnMissingBean
@ConditionalOnClass(name = "com.ctrip.framework.apollo.ConfigService")
public ApolloRefreshService apolloRefreshService(ApolloRefreshProperties properties) {
return new ApolloRefreshService(properties);
}
}
Führen Sie es erneut aus und es werden keine Fehler mehr gemeldet. Ich werde die konkrete Ursache des Problems nicht erläutern. Sie können das offizielle Problem überprüfen.
https://github.com/spring-projects/spring-boot/issues/27846
https://github.com/spring-projects/spring-boot/issues/17282
Zusammenfassen
Wenn Sie die Annotation @ConditionalOnClass verwenden, wird zunächst dringend empfohlen, das Namensattribut anstelle des Wertattributs zu verwenden. Zweitens müssen Sie beim Bereitstellen von Komponenten für andere Geschäftsteams besonders auf Versionsprobleme achten und die Abwärtskompatibilität sicherstellen, da Sie sonst möglicherweise erneut stecken bleiben.