Configuração do projeto com o Spring

A configuração deve ser específica do ambiente - isso é apenas um fato da vida. Se esse não fosse o caso, então não seria configuração e nós apenas codificaríamos os valores no código.

For a Spring application there are several solutions you can use - desde soluções simples até alternativas super flexíveis e altamente complexas.

Uma das soluções mais comuns e diretas é um uso flexível deproperties filesefirst class property support provided by Spring.

Como prova de conceito, para os fins deste artigo, vamos dar uma olhada em um tipo específico de propriedade - a configuração do banco de dados. Faz todo o sentido usar um tipo de configuração de banco de dados para produção, outro para teste e outro para um ambiente de desenvolvimento.

Vamos começar nossa Prova de Conceito - definindo os ambientes que queremos atingir:

A seguir - vamos criar 3 arquivos de propriedades - um para cada um desses ambientes:

Em um aplicativo Maven típico, eles podem residir emsrc/main/resources, mas onde quer que estejam, precisarão seravailable on the classpath quando o aplicativo for implementado.

Uma nota importante -having all properties files under version control makes configuration much more transparente reproduzível. Isso é contrário a ter as configurações em disco em algum lugar e simplesmente apontar o Spring para elas.

No Spring, incluiremos o arquivo correto com base no ambiente:

Obviamente, o mesmo pode ser feito com a configuração Java:

Essa abordagem permite a flexibilidade de ter vários arquivos*.properties paraspecific, focused purposes. Por exemplo - no nosso caso, a configuração de persistência do Spring importa as propriedades de persistência - o que faz todo o sentido. A configuração de segurança importaria propriedades relacionadas à segurança e assim por diante.

O warwill contain all properties files final, implantável - para persistência, as três variantes depersistence-.properties. Como os arquivos são nomeados de maneira diferente, não há medo de incluir acidentalmente o errado. Iremos definir * a variávelenvTarget e, assim, selecionar a instância que queremos das múltiplas variantes existentes.

A variávelenvTarget pode ser definida no sistema operacional / ambiente ou como um parâmetro para a linha de comando da JVM:

Para testes de integração que precisam de persistência ativada - vamos simplesmente definir a propriedadeenvTarget no pom.xml:

O arquivopersistence-h2_test.properties correspondente pode ser colocado emsrc/test/resources para que sejaonly be used for testing e não desnecessariamente incluído e implantado com o war em tempo de execução.

Existem várias maneiras de criar flexibilidade adicional nessa solução, se necessário.

Uma delas é usarmore complex encoding for the names dos arquivos de propriedades, especificando não apenas o ambiente em que serão usados, mas também mais informações (como o provedor de persistência). Por exemplo, podemos usar os seguintes tipos de propriedades:persistence-h2.properties,persistence-mysql.properties ou, ainda mais específico:persistence-dev_h2.properties,persistence-staging_mysql.properties,persistence-production_amazonRDS.properties.

A vantagem de tal convenção de nomenclatura - e éjust a convention, pois nada muda na abordagem geral - é simplesmente transparência. Agora fica muito mais claro o que a configuração faz apenas observando os nomes:

Este artigo discute uma solução flexível para fazer configurações específicas do ambiente no Spring. Uma solução alternativa usando perfiscan be found here.

A implementação da solução pode ser encontrada emthe GitHub project - este é um projeto baseado em Maven, portanto, deve ser fácil de importar e executar como está.