Como posso armazenar Java EE parâmetros de configuração fora de uma EAR ou WAR?

Question

Eu quero armazenar configuração para um fora projeto web do projeto web (ouvido arquivo / war). A aplicação não deve saber em qual recipiente que está sendo executado (WebSphere / JBoss etc.).

O que é a melhor maneira de lidar com isso?

JNDI é uma forma limpa? Se JNDI pode resolver meus problemas, como devo configurá-lo? (Objetos personalizados?)

No meu caso existem apenas simples Key => Valor pares (String, String) para SOAP / WS endpoints.

Answer 1

Veja este questão para a leitura de propriedades fora do arquivo WAR.

Veja este questão para a leitura de valores de variáveis de JNDI. Creio que esta é a melhor solução. Você pode ler uma variável String com este código:

Context initialContext = new InitialContext();
String myvar = (String) initialContext.lookup("java:comp/env/myvar");

O código acima irá funcionar em todos os recipientes. No Tomcat você declarar o seguinte em conf / server.xml:

<GlobalNamingResources ...>
  <Environment name="myvar" value="..."
         type="java.lang.String" override="false"/>
</GlobalNamingResources>

O código acima irá criar um recurso global. Também é possível definir um recurso no contexto de aplicação. Na maioria dos recipientes dos recursos JNDI estão disponíveis através de uma consola de gestão MBeans. Alguns deles oferecem uma interface gráfica para editá-los. No máximo, é necessária uma reinicialização do aplicativo, quando é feita uma alteração.

Como recursos JNDI são definidos e editado é recipiente específico. É o trabalho do configurador / administrador para aplicar as configurações adequadas.

Estes são os benefícios oferecidos pela JNDI:

• Você pode definir valores padrão dos parâmetros no arquivo WAR / EAR.
• Os parâmetros são facilmente configurável no recipiente.
• Você não precisa reiniciar o recipiente quando você modificar o valor de um parâmetro.

Answer 2

Nós tivemos um requisito de configuração semelhante ao implantar um webapp para diferentes desenvolvedores, e no EC2 da Amazon: como é que vamos configuração separado do código binário? Na minha experiência, JNDI é muito complexo, e varia muito entre os recipientes a ser utilizado. Além disso, XML de edição de mão é muito suscetível a erros de sintaxe, assim era a idéia foi jogado fora. Resolvemos isso com um design baseado em algumas regras:

1) único nome simples = entradas de valor deve ser usado

2) novas configurações deve ser carregável, alterando apenas um parâmetro

3) nosso binário guerra deve ser reconfigurável w / o reacondicionamento-lo

4) parâmetros sensíveis (senhas) nunca vai ser embalado no binário

Usando arquivos .properties para todas as configurações, e usando System.getProperty("domain"); para carregar os arquivos de propriedades apropriadas, fomos capazes de cumprir os requisitos. No entanto, a propriedade do sistema não aponta para uma URL do arquivo, em vez disso, criou um conceito que chamamos de "domínio" para especificar a configuração para uso. A localização da configuração é sempre:
$HOME/appName/config/$DOMAIN.properties.

Então, se eu quero correr meu aplicativo usando minha própria configuração, eu iniciar o aplicativo, definindo o domínio para o meu nome:
-Ddomain=jason
no arranque, e as cargas de aplicativos do arquivo:
/home/jason/appName/config/jason.properties
Isso permite configurações desenvolvedores de acções para que possamos recriar o mesmo estado do aplicativo para teste e implementação sem recompilar ou reembalagem. O valor de domínio é então utilizado para .properties de carga a partir de um local padrão, fora da TMP empacotado.

eu posso recriar completamente o ambiente de produção na minha estação de trabalho usando a configuração de produção como:
-Ddomain=ec2 que iria carregar:
/home/jason/appName/config/ec2.properties

Esta configuração nos permite fazer ciclos têm dev / QA / liberação com o conjunto exatamente -one- de binários compilados, usando diferentes configurações em cada ambiente. Não há nenhum risco de ter senhas / etc empacotados nos binários, e as pessoas podem partilhar as suas configurações para questões recriar esse que estamos vendo.

Answer 3

Eu uso uma variável de ambiente para apontar para um URL (que provavelmente é um file: // URL) que tem a minha configuração nele. Isto é muito simples de configurar e não requer a infra-estrutura JNDI.

Aqui está um código de exemplo (digitado da memória - Eu não compilado / testou este):

public void loadConfiguration() {
   String configUrlStr = System.getenv("CONFIG_URL"); // You'd want to use a more
                                                      // Specific variable name.
   if(configUrlStr == null || configUrlStr.equals("") {
       // You would probably want better exception handling, too.
       throw new RuntimeException("CONFIG_URL is not set in the environment."); 
   }


   try {
       URI uri = new URI(configUrlStr);
       File configFile = new File(uri);
       if(!configFile.exists()) {
          throw new RuntimeException("CONFIG_URL points to non-existant file");
       }
       if(!configFile.canRead()) {
          throw new RuntimeException("CONFIG_URL points to a file that cannot be read.");
       }
       this.readConfiguration(configFile);
   } catch (URISyntaxException e) {
       throw new RuntimeException("Malformed URL/URI in CONFIG_URL");
   }



}

Answer 4

você pode apenas armazenar, então, é um arquivo normal propriedades Java que está no caminho de classe e apenas carregar as propriedades?

é simples simples e bonita .. a menos que eu estou faltando alguma coisa

Answer 5

Os meus lugares favoritos são: variáveis ??de ambiente e arquivos de Propriedades (. Como sugerido por Jared e kgiannakakis acima)

Propriedades ambiente Tabela de banco de dados armazenar

No entanto, uma outras soluções mais simples é ter tabela de banco propriedades do ambiente de armazenamento.

Se seu aplicativo usa banco de dados

• isso é relativamente fácil de configurar
• Dá maneira muito fácil de valores controle / mudança
• Pode ser integrado no processo de bem, tornando-a parte de roteiros DB