Java-buildpack: Unterstützt das Deaktivieren der automatischen Neukonfiguration

Welche Rekonfiguration versuchen Sie zu vermeiden? In der Praxis wird das Spring-JAR für die automatische Neukonfiguration in den Klassenpfad eingefügt, führt jedoch möglicherweise keine automatische Neukonfiguration durch. Eine automatische Neukonfiguration findet nur statt, wenn _sowohl_ ein Service, der ein Kandidat für eine Neukonfiguration ist, _als auch_ eine Bean existiert, der ein Kandidat für eine Neukonfiguration ist. Daher können Sie die automatische Neukonfiguration vermeiden, indem Sie Dienste, mit denen Sie keine automatische Neukonfiguration durchführen möchten, nicht binden. Außerdem wird die automatische Neukonfiguration vollständig vermieden, wenn spring-cloud Beans definiert sind.

Ich möchte jede Magie vermeiden, um die ich nicht ausdrücklich gebeten habe. Ich habe keine Möglichkeit zu debuggen, was das Herumfummeln der automatischen Neukonfiguration serverseitig bewirken kann, einschließlich der Frage, ob es sich um eine genaue Analyse der vom Benutzer bereitgestellten Dienste handelt, und ich würde lieber den Droplet-Speicher für etwas mehr Cache oder was auch immer als zusätzlichen Code freigeben, den ich tue nicht brauchen und nicht wollen. Darüber hinaus ist die automatische Neukonfiguration fast vollständig undokumentiert (das habe ich zumindest gefunden) und ist daher praktisch nicht vorhersehbar.

@chrylis Der letzte Punkt, den @nebhale über die automatische Neukonfiguration erwähnt, die sich selbst abschaltet, wenn eine Bean auf Spring-Cloud- (oder sogar vcap-java-)Basis angezeigt wird, sollte sich um die Situationen kümmern, in denen eine App den Dienst sehr spezifisch konfigurieren möchte. Angenommen, Sie verwenden Spring-Cloud, wird die automatische Neukonfiguration Ihre App niemals beeinträchtigen. Ich glaube auch nicht, dass die automatische Neukonfiguration nennenswert viel Speicher verbraucht.

Trotzdem haben wir die automatische Neukonfiguration angeboten, die in v1 deaktiviert werden kann (siehe https://spring.io/blog/2011/11/04/using-cloud-foundry-services-with-spring-part-2 -automatische Neukonfiguration). Heutzutage gibt es einen großen Hammer, das Buildpack zu verzweigen und an alle Bedürfnisse anzupassen. Ob ein solcher Wechsel im Java-Buildpack selbst noch gerechtfertigt ist, werde ich @nebhale anrufen lassen.

Im Moment glaube ich, dass sich die Auto-Rekonfiguration angemessen verhält, indem sie nur unter sehr vorhersehbaren Umständen agiert. Ich begründe dies auf der Tatsache, dass dies das erste Problem ist, das nach einer Möglichkeit zur Deaktivierung verlangt. Ich bin jedoch bereit, diese Position zu überdenken, wenn wir am Ende eine Reihe ähnlicher Anfragen haben. Bis wir eine reproduzierbare Situation sehen, in der sich die automatische Neukonfiguration falsch verhält und nicht geändert werden kann, um richtig zu funktionieren, neige ich dazu, die Dinge so zu belassen, wie sie sind.

Wie bei allen Komponenten kann die automatische Neukonfiguration deaktiviert werden, indem der Eintrag aus der Komponentenliste entfernt wird. Der beste Ort für die Dokumentation zur automatischen Neukonfiguration befindet sich im GitHub-Repository und auf der Framework-Dokumentationsseite .

Wenn es spezifische Verbesserungen am Verhalten der automatischen Neukonfiguration oder an der dazugehörigen Dokumentation gibt, teilen Sie uns dies bitte mit und wir werden diese gerne vornehmen.

Darüber hinaus wird eine automatische Neukonfiguration vollständig vermieden, wenn Spring-Cloud-Beans definiert sind.

Meiner Erfahrung nach gibt es bei diesem Verhalten Timing-Probleme. Wenn die Spring-Cloud-Bean in einem Profil definiert ist, kann sie identifiziert werden, nachdem eine "frühere" deklarierte Bean (dh eine außerhalb eines bestimmten Profils definierte) bereits durch die automatische Neukonfiguration munged wurde.

Angenommen, eine Konfiguration , die zwei DataSource Beans definiert: eine eingebettete Datenquelle und eine externe Datenquelle, die je nach Umgebung/Profil variieren können. Verweise auf die eingebettete Datenquelle werden so umkonfiguriert, dass sie auf die externe Datenquelle verweisen, es sei denn, Sie ändern die Konfiguration, um die Bean-Definition der eingebetteten Datenquelle einzubinden.

Aus ähnlichen Gründen wie das Original-Poster möchte ich auch die automatische Neukonfiguration deaktivieren: Ich möchte nicht, dass Magie passiert, die ich nicht verstehe.
Hat es sich geändert? Ist es möglich, es auf andere Weise zu deaktivieren, als das Buildpack zu forken?

Hallo, ja das ist jetzt möglich.
Jede Konfiguration kann jetzt über eine Umgebungsvariable festgelegt werden, anstatt das Buildpack zu forken, um die Konfigurationsdateien direkt zu ändern. Um beispielsweise die automatische Neukonfiguration zu deaktivieren, sollten Sie eine Umgebungsvariable wie diese setzen.

cf set-env myapp JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '[enabled: false]'

Weitere Informationen finden Sie in der Dokumentation https://github.com/cloudfoundry/java-buildpack#configuration -and-extension

Ich verwende diese Technik bereits für die Einstellungen des Speicherrechners. Ich denke, ich sollte besser alle Konfigurationsdateien überprüfen und sehen, was darin enthalten ist, bevor ich erneut Fragen stelle.
Dankeschön.

Um dies in einer Manifestdatei zu tun, ist ein anderes Format erforderlich.

Versuche dies,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Beachten Sie die zusätzlichen :

Gibt es einen Plan für diese Bibliothek zur automatischen Neukonfiguration, um die teilweise Deaktivierung der Dienstverbindungen zu unterstützen? In unserem Anwendungsfall benötigen wir insbesondere eine angepasste RedisConnectionFactory (da wir eine SSL-Verbindung zum Azure Redis-Dienst verwenden), wir möchten jedoch, dass diese Auto-Rekonfigurationsbibliothek unseren RabbitMQ neu konfiguriert (da wir den von PCF bereitgestellten RabbitMQ-Dienst verwenden).