Parâmetro de inicialização

Algumas solucoes possiveis:

:arrow: Usar um arquivo de properties:

:arrow: Usar um XML de configuracao

:arrow: Passar os parametros no web.xml ou na linha de comando (-Dfoo.bar=baz)

Então Carlos,

As duas primeiras tentativas eu irei descartar, pois o parâmetro que eu irei passar para a aplicação é o path dos respectivos arquivos de configuração. Deste modo sobra a última.
Estive pensando que tanto na inicialização WEB qto application eu poderia verificar se existe alguém já setado em uma propertie do System.
Ex. if(System.getProperties(“minhaPath”) != null) … algo assim.

Se não tiver ninguém, eu seto. Assim eu posso ter ambos os modos da aplicação satisfeitos.
O que vc acha ?

Obrigado pelo help.

JSnake

Fica melhor ainda se, ao inves de vc passar um caminho pros arquivos de configuracao, vc procurar os arquivos de configuracao no CLASSPATH logo de uma vez:

this.getClass().getClassLoader().getResourceAsStream("arquivo-de-configuracao");

Que tal?

java -Dmeuparametro=valordomeuparametro MainClass

Dentro da MainClass:

private static String meuparametro;

static {

meuparametro = System.getProperties().getProperty("meuparametro", "valordefaultdomeuparametro");

}

[]'s

Pessoas,

Vou responder a vocês, primeiramente, de maneira separada e depois coletivamente.

Carlos,

this.getClass().get… … …
Hoje eu já faço isso. O problema é que se o cliente quiser alterar algum parâmetro nos arquivos de configuração, ele deverá abrir o EAR file que está no app server, alterar o arquivo e novamente remontar o EAR.
Fica muito complexo para ele.
Por isso eu pensei em passar para a aplicação a localização, que será então lida como vc anteriormente sugeriu.

Oziel,

Estou querendo evitar o uso de parâmetros na VM. A idéia é que o deploy no cliente fique o mais limpo possível, entende ?
Isso envolve a modificação na inicialização da VM no app server.

For all,

Estou pesquisando na especificação da J2EE, se existe uma maneira mais bela de se passar parâmetros para a inicialização.
Porém, continuo agradecido pelos vosssos contatos, e aberto a novas críticas e sugestões.
E desculpem-me, se pareço chato.

Abraços,

JSnake.

Voce pode expor a configuração da sua aplicação via JMX.
Ai com qualquer console chulé o cliente vai poder configurar sua aplicação.

louds,

Vc tem algum exemplo disso ?
Não conheço muito sobre JMX.

[]'s

JSnake

Agora você me pegou.
Essa URL deve te ajudar bastante:
http://java.sun.com/products/JavaManagement/

Escreva entao um engine que utilize a JNDI como persistencia desses parametros…

E procure um AppServer J2EE que tenha a persistencia da JNDI.

[]'s

Ok, thks…

Vou dar uma olhada e tbém continuar pesquisando/avaliando outras maneiras.

[]'s

JSnake

Wow… de parametros passados pela linha de comando a JNDI e JMX em menos de 20 mensagens…

Over-engineering total :lol: - se bem que eu nao tenho nenhuma ideia melhor…

O pessoal que trabalha comigo bem que gostou de JNDI e JMX

Mas, logo em seguida, levantaram a hipótese de ter mais coisas a se configurar.
Eu estava testando a possibilidade de se colocar estes arquivos na raiz do EAR file, seguindo sugestões do pessoal aqui do trampo.
Mas nem rola…lembro-me de ter lido em algum lugar que tudo que vai na raiz do EAR deve ir como um módulo (JAR e tal). Alguém por aí já conseguiu esta façanha. Lembre-se que estamos jogando a especificação J2EE em algum lugar esquisito que nem vale a pena falar.

Acho que o esquema bom mesmo será setar um parâmetro de initialização no servlet que aponte a path que eu quero e setar um parâmetro de VM qdo o uso for fora do Web Container.

Caramba, não sabia que esta Thread iria ser tão discutida. Mas é isso aí, BEST PRACTICES através de BRAIN-STORM.

[]'s a todos que estão colaborando…

JSnake

Não foi dito exatamente quao configuravel a aplicação precisa ser.

Configurar + instalar? Muito dos parametros podem ser passados no deployment descriptor do container que fica fora do arquivo ear.

Configurar em runtime? Ai tem várias opções: Sendo JMX e J2EE management (novidade da 1.4) as ferramentas ideiais, porem usar JNDI com persistencia, como o oziel sugeriu, ou alguma coisa usando Entity Beans podem ser uma solução mais prática e simples.

Sem j2ee? Use a API de preferencias da J2SE 1.4.

Foi mal louds,

No meu caso, especificamente, CONFIGURAR + INSTALAR.

Deployment descriptor do container que fica fora do arquivo ear ?

Como faço para que a minha aplicação inteira, módulos jar, war e ejb leiam o mesmo deployment descriptor. Pelo que eu li, existem vários deployment descriptors em um EAR file, um para cada módulo.
Tem como eu especificar um que toda a aplicação consiga ler ?

O deployment descriptor do teu container é inacessivel a tua aplicação diretamente.

Já tentou usar resources?

Cria 1 jar chamado config, que tem apenas 1 arquivo:

/com/exemplo/configuracao.xml

Ai vc pode ler esse arquivo usando a API de resources, ClassLoader:getResourceAsStream()

Po, tai… uma coisa bem chata na especificacao da J2EE: nao tem uma API de “reflection” pra deployment descriptors

louds,

Esta sua última sugestão não pode ser acatada, pois o intuito é manter os arquivos de configuração em um PATH, fora de jar file.
Pelo que eu estou analisando, a solução será mesmo init-parameter no servlet e parâmetro de VM no caso de uma aplicação comum.

Obrigado pela ajuda.

JSnake.

Cara, não tenta deixar sua aplcação tão boa tão boa que ninguém usa tudo o que ela faz.

Bota um arquivinho properties ridículo com os parâmetros que vc quer passar (tipo, o caminho dos arquivos de configuração). Vc fixa um ponto, lógico. O arquivo properties vc acessa como o cv falou (via getResource()).
Se o cara quiser mudar o nome dos arquivos de configuração, ele vai ter que abrir o EAR.

Mas duvido que num mesmo deployment alguém queira ficar mudando isso…

boa sorte!!
[]s