Galera é o seguinte, sempre utilizei o famoso ‘.properties’ em minhas apps. sem problemas até então, mas, me deparei com alguns problemas quando a app. é atualizada.
Pensando em mais de um ambiente (desenvolvimento, produção, homologação, até varios destes) e ainda mais, a aplicação utiliza 4 servidores diferentes ficando a localização destes armazenadas no arquivo, então a cada alteração teria que me atentar aos parâmetros pesonalizados para não sobrescreve-los quando atualizar a app. no servidor.
Então me coloquei a pensar… seria válido colocar este arquivo de configuração fora da app. em um diretório local ? (Porque assim eu faria a configuração uma vez, e a atualização da app. naõ alteraria as conf.)
Banco… TXT… XML… seilá ! ?
Valeu !
Veja a viabilidade de, se colocar essas configurações como variáveis no servidor!
O impacto no projeto é pequeno, mas essa é uma pratica comum ?
Não saberia dizer se é comum, ou não, mas é viável, alguns colocam em BDs, outros em arquivos .properties, eu nesse caso colocaria no servidor!
[quote=wellington.nogueira]Crie identificadores de ambiente, se possível:
desenvolvimento.propriedade=valordesenvolvimento
homologacao.propriedade=valor homologação
producao.propriedade=valor produção
Na hora de usar a chave, concatene a chave atual ao ambiente (lembrando, deverá ser possível identificar o ambiente, talvez como váriável no projeto).[/quote]
Mas daí toda vez teria que tomar cuidado para usar o valor certo antes de enviar para homologação/produção. Em uma empresa onde trabalhei, fisicamente falando, era sempre o mesmo pacote testado, o que ia para homologação era exatamente igual ao de produção, sem intervenção nenhuma, assim você assegura a integridade do teu pacote.
[quote=thiago.correa][quote=wellington.nogueira]Crie identificadores de ambiente, se possível:
desenvolvimento.propriedade=valordesenvolvimento
homologacao.propriedade=valor homologação
producao.propriedade=valor produção
Na hora de usar a chave, concatene a chave atual ao ambiente (lembrando, deverá ser possível identificar o ambiente, talvez como váriável no projeto).[/quote]
Mas daí toda vez teria que tomar cuidado para usar o valor certo antes de enviar para homologação/produção. Em uma empresa onde trabalhei, fisicamente falando, era sempre o mesmo pacote testado, o que ia para homologação era exatamente igual ao de produção, sem intervenção nenhuma, assim você assegura a integridade do teu pacote.[/quote]
Entendi wellington, mas como o thiago disse, o cenário seria o mesmo. Imagine que você tenha 5 servidores de produção, com uma variavél no arquivo de propriedades que tem um valor específico para cada um (ajustado conforme necessidade do cliente), então tenho uma unica app. com 5 possíveis valores para uma uníca variavel. Quando for atualizar alguma das aplicações teria que rever todos os ajustes feitos para o cliente antes de atualizar a app, para não sobrescrever as configurações personalizadas pelas padrão.
to aceitando opiniões … hehe…
[quote=wellington.nogueira]
Outra opção seria um Ant com métodos para cada ambiente que gerassem o war e escolhesse para o ambiente específico o .properties relacionado ao ambiente.[/quote]
Essa opção é também uma ótima
Crie identificadores de ambiente, se possível:
desenvolvimento.propriedade=valordesenvolvimento
homologacao.propriedade=valor homologação
producao.propriedade=valor produção
Na hora de usar a chave, concatene a chave atual ao ambiente (lembrando, deverá ser possível identificar o ambiente, talvez como váriável no projeto).
Não sei se ficou claro ou não…
No servidor haveria uma única propriedade:
AMBIENTE=producao ou
AMBIENTE=homologacao etc.
Ao usar o properties, vc usaria bundle.get(getAmbiente() + “propriedade”);
E o mesmo arquivo properties ficaria com todas as opções de ambiente.
Outra opção seria um Ant com métodos para cada ambiente que gerassem o war e escolhesse para o ambiente específico o .properties relacionado ao ambiente.