Java-buildpack: Suporta a desativação da reconfiguração automática

Que reconfiguração você está tentando evitar? Na prática, o JAR de reconfiguração automática do Spring é colocado no caminho da classe, mas pode não fazer nenhuma reconfiguração automática. A reconfiguração automática só acontece quando existe _both_ um serviço candidato à reconfiguração _e_ um bean candidato à reconfiguração. Portanto, você pode evitar a reconfiguração automática, não vinculando os serviços com os quais não deseja reconfigurar automaticamente. Além disso, a reconfiguração automática é evitada completamente se houver quaisquer spring-cloud beans definidos.

Quero evitar qualquer magia que não tenha pedido especificamente. Não tenho como depurar o que a reconfiguração automática pode estar fazendo no lado do servidor, incluindo se está analisando com precisão os serviços fornecidos pelo usuário, e prefiro liberar a memória do droplet para um pouco mais de cache ou qualquer outra coisa do que código extra que eu não preciso e não quero. Além disso, a reconfiguração automática é quase completamente não documentada (que eu consegui encontrar, pelo menos) e, portanto, imprevisível do ponto de vista prático.

@chrylis O último ponto que @nebhale mencionou sobre o auto-reconfig desligar-se quando vê um bean baseado em spring-cloud (ou mesmo vcap-java) deve cuidar das situações em que um aplicativo deseja configurar o serviço de forma muito específica. Supondo que você use a nuvem da mola, a reconfiguração automática nunca interferirá no seu aplicativo. Também não acho que a reconfiguração automática consumirá qualquer quantidade perceptível de memória.

Com tudo isso dito, oferecemos a reconfiguração automática para ser desativada na v1 (consulte https://spring.io/blog/2011/11/04/using-cloud-foundry-services-with-spring-part-2 -auto-reconfiguração). Hoje em dia, há um grande problema em bifurcar o buildpack e modificá-lo para se adequar a todas as necessidades. Portanto, se essa opção ainda é garantida no próprio buildpack java, vou deixar @nebhale fazer uma chamada.

No momento, acredito que a autoconfiguração se comporta de forma adequada, agindo apenas sob um conjunto de circunstâncias muito previsíveis. Baseio isso no fato de que este é o primeiro problema solicitando uma forma de desativá-lo. No entanto, estou aberto a reconsiderar esta posição se terminarmos com uma série de pedidos semelhantes a este. Até vermos uma situação reproduzível em que a reconfiguração automática se comporta mal e não pode ser modificada para funcionar corretamente, estou inclinado a manter as coisas como estão.

Como acontece com todos os componentes, a reconfiguração automática pode ser desabilitada removendo sua entrada da lista de componentes. O melhor local para documentação sobre reconfiguração automática é em seu repositório GitHub e na página de documentação do

Se houver melhorias específicas no comportamento da reconfiguração automática ou na documentação relacionada a ela, informe-nos e ficaremos felizes em fazê-las.

Além disso, a reconfiguração automática é evitada completamente se houver qualquer bean de nuvem da mola definido.

Na minha experiência, há problemas de tempo nesse comportamento. Se o bean spring-cloud for definido em um perfil, ele pode ser identificado depois que um bean declarado "anterior" (ou seja, um definido fora de um perfil específico) já foi removido por reconfiguração automática.

Por exemplo, dada uma configuração que define dois DataSource beans: uma fonte de dados incorporada e uma fonte de dados externa que pode variar com base no ambiente / perfil. As referências à fonte de dados incorporada serão reconfiguradas para apontar para a fonte de dados externa, a menos que você modifique a configuração para embutir a definição do bean da fonte de dados incorporada.

Também gostaria de desativar a reconfiguração automática, por motivos semelhantes aos do autor do pôster: Não quero que aconteça nenhuma mágica que eu não entenda.
Isso mudou? É possível desativá-lo de qualquer outra forma que não seja o buildpack?

Olá, sim, agora é possível.
Qualquer configuração agora pode ser definida por meio de uma variável de ambiente em vez de bifurcar o buildpack para alterar os arquivos de configuração diretamente. Por exemplo, para desativar a reconfiguração automática, você deve definir uma variável de ambiente como esta.

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

Mais informações estão na documentação https://github.com/cloudfoundry/java-buildpack#configuration -and-extension

Já estou usando essa técnica para as configurações da calculadora de memória. Acho melhor verificar todos os arquivos de configuração e ver o que há dentro deles antes de fazer perguntas novamente.
Obrigada.

Para fazer isso em um arquivo de manifesto, é necessário um formato diferente.

Tente isto,

JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'

Observe o : extra

Existe um plano para esta biblioteca de reconfiguração automática para suportar a desativação parcial das conexões de serviços? Especificamente, em nosso caso de uso, precisamos de uma RedisConnectionFactory personalizada (já que usamos conexão SSL para o serviço Azure Redis), no entanto, queremos que essa lib de reconfiguração automática reconfigure nosso RabbitMQ (já que usamos o serviço RabbitMQ fornecido pelo PCF).