Valeu Chester!

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.

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?

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!

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!

Imagine que em uma rede local temos uma máquina servidora que se comunica com diversos clientes. gerenciando-os. pode gerenciar por exemplo o momento em que todas estas máquinas cliente serão desligadas. Imagine também que esta máquina servidora se realiza comunicação com um outro servidor [desta vez web] já que este agendamento também pode ser feito através da internet. Imagine ainda que a rede local é uma rede mista, quanto aos sistemas operacionais utilizados. pode haver por exemplo uma rede com máquinas w2k e wxp. não me recordo de nenhuma ocorrência de rede com máquinas linux e windows, porém, não é impossível.

É (*bem*)² mais em baixo mesmo…