Comentários sobre: timefix (ou: Acertando o Horário de Verão em Java II)

Por: Chester

Chester — Fri, 08 Apr 2011 05:03:41 +0000

E o meu sistema deficiente de notificações da época me fez não responder a tempo. Sim, deve funcionar independente do caminho. Sobre o “permission denied” abaixo, tente um chmod dando direito de leitura para qualquer usuário (não deve gerar um issue de segurança, o arquivo é público mesmo).

Por: Daniel

Daniel — Thu, 16 Oct 2008 18:53:33 +0000

Permission denied
Unable to access jarfile timefix

Por: Daniel

Daniel — Thu, 16 Oct 2008 18:18:29 +0000

Olá, sei que o post é antigo, mas li e surgiu uma duvida:
meu script não está em /etc/init.d/
vai funcionar em outro caminho ?

Por: lucão

lucão — Wed, 23 Apr 2008 14:26:52 +0000

e muito legal………………..

Por: Diego

Diego — Tue, 06 Nov 2007 20:00:53 +0000

Agora funcionou.
Criei um post detalhando a peleja: http://infoessencial.blogspot.com/2007/11/acertando-o-relogio-do-tomcat.html

Valeu Chester!

Por: Chester

Chester — Tue, 06 Nov 2007 19:07:00 +0000

Hmm... pela mensagem, ele encontrou o TimeFix (ou seja, o CLASSPATH inclui ele), mas não encontrou a classe principal do Tomcat (ou seja, o CLASSPATH não inclui ela). Veja se você está realmente *adicionando* o path do timefix-1.0.jar no CLASSPATH, ou se você está *substituindo* por ele (que é o que a mensagem sugere).

O comando export CLASSPATH=$CLASSPATH:/xyz/timefix-1.0.jar deve preservar o CLASSPATH original. Testei o equivalente dele aqui (estou numa máquina Windows) e ele setou o classpath apropriadamente.

Por: Diego

Diego — Tue, 06 Nov 2007 18:44:15 +0000

Tentei setar no tomcat, mas olha o erro que deu:

Exception in thread "main" java.lang.ClassNotFoundException: org.apache.catalina.startup.Bootstrap
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at br.blog.chester.timefix.Timefix.main(Timefix.java:112)

Alguem sabe o que pode ser?

Por: Chester

Chester — Tue, 06 Nov 2007 17:56:39 +0000

Olhando no catalina.sh do Tomcat 6.0.14, vejo que todas as possibilidades de execução são do tipo:

exec "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
...
org.apache.catalina.startup.Bootstrap "$@" start

Desta forma, o passo 2 consiste em substituir todas as ocorrências de "org.apache.catalina.startup.Bootstrap" por "timefix org.apache.catalina.startup.Bootstrap" (sem as aspas).

O passo 1 você até pode fazer em algum ponto do arquivo, mas eu vi que ele chama um setclasspath.sh (que limpa o classpath antes de construí-lo). Desta forma, o mais limpinho parece ser colocar no final deste arquivo a linha

export CLASSPATH=$CLASSPATH:/xyz/timefix-1.0.jar

(/xyz é o lugar onde o jar foi colocado, altere conforme o seu caso)

Veja se rolou e dê um toque. Abraço!

Por: Duvida

Duvida — Tue, 06 Nov 2007 13:14:52 +0000

Como eu faço esta alteração no catalina.sh?!?
em qual momento eu insiro o "timefix" para que minhas aplicações web reconheçam esta alteração?!?

Por: Chester

Chester — Fri, 19 Oct 2007 11:57:03 +0000

É, bem mais embaixo mesmo... :-)

Nem sonho em dar uma solução de bate-pronto, claro. Mas no mínimo tem que agregar uma solução de sync com o horário local (o timefix rola pra máquinas Linux, teria que ter algo semelhante que lesse o zone loca para máquinas Windows) aliada a uma solução de sync do horário local com o global (e essa teria que ser nativa).

Essa solução nativa é que são elas. Talvez um policy de rede aplicado por um controlador de domínio - que eu não sei se considera zona geográfica com essa granularidade, nem se permite setar um timezone customizado. Outra alternativa seria um programa que aplique manualmente as configurações de timezone na máquina (possivelmente orientado por uma configuração geográfica local *e* info do servidor, para que as políticas locais possam ser refletidas a partir da localização central).

Uma outra alternativa (bem mais radical) seria usar sua própria implementação de Date/Calendar (que consultaria o horário GMT no servidor ou em algum time server e adaptaria à configuração geográfica local), mas aí é chamar outro caminhão de problemas.

É, nessas horas eu lembro por que cliente-servidor realmente é complicado de escalar, especialmente em ambientes geograficamente dispersos. :-(

Boa sorte!