Java-buildpack: Prise en charge de la désactivation de la reconfiguration automatique

Quelle reconfiguration essayez-vous d'éviter ? En pratique, le JAR de reconfiguration automatique Spring est placé dans le chemin de classe, mais peut ne pas effectuer de reconfiguration automatique. La reconfiguration automatique ne se produit que lorsqu' _à la fois_ un service candidat à la reconfiguration _et_ un bean candidat à la reconfiguration existent. Par conséquent, vous pouvez éviter la reconfiguration automatique en ne liant pas les services avec lesquels vous ne souhaitez pas reconfigurer automatiquement. De plus, la reconfiguration automatique est complètement évitée si des beans spring-cloud sont définis.

Je veux éviter toute magie que je n'ai pas spécifiquement demandée. Je n'ai aucun moyen de déboguer ce que la reconfiguration automatique peut faire côté serveur, y compris s'il s'agit d'analyser avec précision les services fournis par l'utilisateur, et je préfère libérer la mémoire des gouttelettes pour un peu plus de cache ou autre chose que du code supplémentaire que je ne pas besoin et ne veux pas. De plus, la reconfiguration automatique est presque totalement non documentée (que j'ai pu trouver, au moins) et donc imprévisible en pratique.

@chrylis Le dernier point mentionné par @nebhale à propos de la reconfiguration automatique qui s'éteint lorsqu'il voit un bean basé sur Spring-Cloud (ou même vcap-java) devrait prendre en charge les situations dans lesquelles une application souhaite configurer le service de manière très spécifique. En supposant que vous utilisiez Spring-Cloud, la reconfiguration automatique n'interférera jamais avec votre application. Je ne pense pas non plus que la reconfiguration automatique consommera une quantité notable de mémoire.

Cela dit, nous avons proposé de désactiver la reconfiguration automatique dans la v1 (voir https://spring.io/blog/2011/11/04/using-cloud-foundry-services-with-spring-part-2 -auto-reconfiguration). De nos jours, il est difficile de forger le pack de construction et de le modifier pour répondre à tous les besoins. Donc, si un tel commutateur est toujours justifié dans le pack de construction Java lui-même, je laisserai @nebhale passer un appel.

Pour le moment, je pense que la reconfiguration automatique se comporte de manière appropriée en agissant uniquement dans un ensemble de circonstances très prévisible. Je base cela sur le fait qu'il s'agit du premier problème demandant un moyen de le désactiver. Je suis cependant ouvert à reconsidérer cette position si nous nous retrouvons avec un certain nombre de demandes similaires à celle-ci. Jusqu'à ce que nous voyions une situation reproductible où la reconfiguration automatique se comporte mal et ne peut pas être modifiée pour fonctionner correctement, je suis enclin à garder les choses telles qu'elles sont.

Comme pour tous les composants, la reconfiguration automatique peut être désactivée en supprimant son entrée de la liste des composants. Le meilleur emplacement pour la documentation sur la reconfiguration automatique est dans son référentiel GitHub et sur la page de documentation du

S'il y a des améliorations spécifiques au comportement de la reconfiguration automatique ou à la documentation qui l'entoure, veuillez nous en informer et nous serons heureux de les apporter.

De plus, la reconfiguration automatique est complètement évitée si des beans spring-cloud sont définis.

D'après mon expérience, il y a des problèmes de synchronisation dans ce comportement. Si le bean spring-cloud est défini dans un profil, il peut alors être identifié après qu'un bean déclaré "antérieur" (c'est-à-dire défini en dehors d'un profil spécifique) a déjà été modifié par auto-reconfiguration.

Par exemple, étant donné une configuration qui définit deux beans DataSource : une source de données intégrée et une source de données externe qui peut varier en fonction de l'environnement/du profil. Les références à la source de données intégrée seront reconfigurées pour pointer vers la source de données externe, à moins que vous ne modifiiez la configuration pour incorporer la définition du bean de la source de données intégrée.

Je voudrais également désactiver la reconfiguration automatique, pour des raisons similaires à celles de l'affiche d'origine : je ne veux pas qu'une magie se produise que je ne comprends pas.
A-t-il changé ? Est-il possible de le désactiver d'une autre manière que de forker le buildpack ?

Bonjour, oui c'est désormais possible.
Toute configuration peut désormais être définie via une variable d'environnement au lieu de forker le buildpack pour modifier directement les fichiers de configuration. Par exemple, pour désactiver la reconfiguration automatique, vous devez définir une variable d'environnement comme celle-ci.

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

Plus d'informations sont dans la documentation https://github.com/cloudfoundry/java-buildpack#configuration -and-extension

J'utilise déjà cette technique pour les paramètres de la calculatrice de mémoire. Je suppose que je ferais mieux de vérifier tous les fichiers de configuration et de voir ce qu'ils contiennent avant de poser à nouveau des questions.
Merci.

Pour ce faire dans un fichier manifeste, un format différent est requis.

Essaye ça,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Remarquez les : supplémentaires

Existe-t-il un plan pour que cette bibliothèque de reconfiguration automatique prenne en charge la désactivation partielle des connexions de services ? Plus précisément, dans notre cas d'utilisation, nous avons besoin d'une RedisConnectionFactory personnalisée (car nous utilisons une connexion SSL au service Azure Redis), cependant, nous voulons que cette bibliothèque de reconfiguration automatique reconfigure notre RabbitMQ (comme nous utilisons le service RabbitMQ fourni par PCF).