Problema com .jar

21 de setembro de 2004 5 respostas

Alex_Ronchi_Dutra 21 de setembro de 2004

Olá galera da lista.

Estou com um probleminha chato. Talvez alguem já tenha passado por isto.

Criei um .jar executavel no Jbuilder X para minha aplicação.

O meu programa além das classes de negocio usa o POI (projeto jakarta) e 4 arquivos .properties.

Quanto ao POI não tive problemas, ao executar o jar, as tarefas pertinentes a ele são executadas.

Porém meus arquivos . properties não estão sendo encontrados quando rodo meu jar fora do class-path do projeto.

Fiz esse teste porque pretendo distribuir esse jar para varios micros aqui na empresa.

Lembrando que ao criar o jar no JBuilder incluí as bibliotecas do POI e os file resources ( 4 arquivos .properties)

Meu manifest além do cabeçalho tem a cláusula

Main-Class: <classe>

Ao abrir o jar pelo winzip, notei que os properties estão lá inclusos, mas eles não são encontrados ao rodar o programa.

O programa possui varias sintaxes como esta new FileInputStream(“arquivo.properties”);
O projeto está funcional quando rodo o jar dentro do class-path ou dentro do proprio jBuilder

MORAL DA HISTORIA: Como fazer para não dar IOException quando rodo o jar de qq lugar?

Lembrando que ao copiar os arquivos .properties junto com o jar para outra maquina. Aí funciona. Mas isso eu não quero.

Obrigado a todos

5 Respostas

caiofilipini 21 de set. de 2004

“Alex Ronchi Dutra”:
O programa possui varias sintaxes como esta new FileInputStream(“arquivo.properties”);
O projeto está funcional quando rodo o jar dentro do class-path ou dentro do proprio jBuilder

Tente usar uma das formas a seguir, considerando que o arquivo está na raiz do seu JAR:

InputStream is = getClass().getClassLoader() .getResourceAsStream("arquivo.properties");

InputStream is = Thread.currentThread().getContextClassLoader() .getResourceAsStream("arquivo.properties");

Deve funcionar.

[]'s

code 21 de set. de 2004

Só uma observação: Eu tive problemas utilizando o comando acima quando fiz o deploy de um ear. Pelo que eu li, quando vc faz o deploy desse tipo o ear, os wars e os jars tem classloaders diferentes.

Usando o comando de baixo funcionou tudo.

“caiofilipini”:
InputStream is = Thread.currentThread().getContextClassLoader() .getResourceAsStream("arquivo.properties");

Luca 21 de set. de 2004

Olá

Bem lembrado, aliás fazer deployment com ear é a única maneira de carregar a mesma classe com versões diferentes em uma só aplicação justamente por usar mais de um ClassLoader.

Mas fiquei na dúvida sobre o que realmente aconteceu contigo. Explica exatamente qual o problema porque ainda acredito que mesmo havendo mais de um ClassLoader o comando poderia funcionar (não 100% das vezes). Será que estou viajando?

[]s
Luca

code 21 de set. de 2004

O problema foi mais ou menos o seguinte:
Eu tinha um jar que chamei de framework.jar e que utilizava o jar do hibernate e que utilizo em todos os projetos que desenvolvo.
Desenvolvi um sistema e a partir desse sistema criei o war e o jar especifico (sistema.war e sistema.jar).
O arquivo de configuração do hibernate que uma classe no framework.jar precisa ler está no sistema.jar.
Utilizando

InputStream is = getClass().getClassLoader() .getResourceAsStream("arquivo.properties");
o arquivo de configuração não era encontrado.
E quando usei

InputStream is = Thread.currentThread().getContextClassLoader() .getResourceAsStream("arquivo.properties");
funcionou.
Acredito que é porque ao usar o getClass().getClassLoader() ele utilizava o classpath do framework.jar (que não tem o sistema.jar) e ao usar Thread.currentThread().getContextClassLoader() ele utiliza o classpath do ear (que contem todos os jars).

Luca 21 de set. de 2004

Olá

Bela explicação, valeu! Esta é realmente uma sutileza bem avançada do Java.

[]s
Luca

Criado 21 de setembro de 2004

Ultima resposta 21 de set. de 2004

Respostas 5

Participantes 4

5 Respostas

Topicos relacionados