Java-buildpack: Admite la desactivación de la reconfiguración automática

¿Qué reconfiguración está tratando de evitar? En la práctica, el JAR de reconfiguración automática de Spring se coloca en la ruta de clases, pero es posible que en realidad no realice ninguna reconfiguración automática. La reconfiguración automática solo ocurre cuando _tanto_ un servicio que es candidato a reconfiguración _y_ un bean que es candidato a reconfiguración existen. Por lo tanto, puede evitar la reconfiguración automática al no vincular los servicios con los que no desea reconfigurarse automáticamente. Además, la reconfiguración automática se evita por completo si hay spring-cloud beans definidos.

Quiero evitar cualquier magia que no haya pedido específicamente. No tengo forma de depurar lo que puede estar haciendo la reconfiguración automática del lado del servidor, incluido si se trata de analizar con precisión los servicios proporcionados por el usuario, y prefiero liberar la memoria de gota para un poco más de caché o lo que sea que el código adicional que uso. no necesito y no quiero. Además, la reconfiguración automática está casi completamente indocumentada (que he podido encontrar, al menos) y, por lo tanto, es impredecible en la práctica.

@chrylis El último punto que mencionó @nebhale acerca de la reconfiguración automática que se apaga cuando ve un bean basado en spring-cloud (o incluso vcap-java) debe ocuparse de las situaciones en las que una aplicación quiere configurar el servicio de manera muy específica. Suponiendo que use Spring-Cloud, la reconfiguración automática nunca interferirá con su aplicación. Tampoco creo que la reconfiguración automática consuma una cantidad notable de memoria.

Con todo lo dicho, ofrecimos la reconfiguración automática para desactivarla en v1 (consulte https://spring.io/blog/2011/11/04/using-cloud-foundry-services-with-spring-part-2 -auto-reconfiguración). Hoy en día, existe un gran esfuerzo para bifurcar el paquete de compilación y modificarlo para adaptarse a cualquier necesidad. Entonces, si dicho cambio aún está justificado en el paquete de compilación de Java, dejaré que

Por el momento, creo que la autoconfiguración se comporta de manera apropiada actuando solo bajo un conjunto de circunstancias muy predecibles. Baso esto en el hecho de que este es el primer problema que solicita una forma de deshabilitarlo. Sin embargo, estoy dispuesto a reconsiderar esta posición si terminamos con una serie de solicitudes similares a esta. Hasta que veamos una situación reproducible en la que la reconfiguración automática se comporte mal y no se pueda modificar para que funcione correctamente, me inclino a mantener las cosas como están.

Al igual que con todos los componentes, la reconfiguración automática se puede desactivar eliminando su entrada de la lista de componentes. La mejor ubicación para la documentación sobre la reconfiguración automática es en su repositorio de GitHub y en la página de documentación del

Si hay mejoras específicas en el comportamiento de la reconfiguración automática o en la documentación que la rodea, háganoslo saber y estaremos encantados de realizarlas.

Además, la reconfiguración automática se evita por completo si hay definidos beans de nube de primavera.

En mi experiencia, hay problemas de sincronización en ese comportamiento. Si el bean de nube de primavera se define en un perfil, entonces se puede identificar después de que un bean declarado "anterior" (es decir, uno definido fuera de un perfil específico) ya haya sido creado por reconfiguración automática.

Por ejemplo, dada una configuración que define dos DataSource beans: una fuente de datos incrustada y una fuente de datos externa que puede variar según el entorno / perfil. Las referencias a la fuente de datos incorporada se reconfigurarán para que apunten a la fuente de datos externa a menos que modifique la configuración para incorporar la definición del bean de fuente de datos incorporada.

También me gustaría deshabilitar la reconfiguración automática, por razones similares a las del póster original: no quiero que ocurra ninguna magia que no entienda.
¿Ha cambiado? ¿Es posible deshabilitarlo de otra manera que no sea bifurcando el paquete de compilación?

Hola, sí, esto ahora es posible.
Ahora se puede establecer cualquier configuración a través de una variable de entorno en lugar de bifurcar el paquete de compilación para cambiar los archivos de configuración directamente. Por ejemplo, para deshabilitar la reconfiguración automática, debe establecer una variable de entorno como esta.

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

Más información está en la documentación https://github.com/cloudfoundry/java-buildpack#configuration -and-extension

Ya estoy usando esta técnica para la configuración de la calculadora de memoria. Supongo que será mejor que compruebe todos los archivos de configuración y vea qué hay dentro de ellos antes de volver a hacer preguntas.
Gracias.

Para hacer esto en un archivo de manifiesto, se requiere un formato diferente.

Prueba esto,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Observe el : extra

¿Existe un plan para que esta biblioteca de reconfiguración automática admita la desactivación parcial de las conexiones de servicios? Específicamente, en nuestro caso de uso, necesitamos una RedisConnectionFactory personalizada (ya que usamos la conexión SSL al servicio Azure Redis), sin embargo, queremos que esta biblioteca de reconfiguración automática reconfigure nuestro RabbitMQ (ya que usamos el servicio RabbitMQ proporcionado por PCF).