Novos drivers JDBC e ODBC para CFMX e JRun

A Macromedia acaba de colocar no ar duas novas versões de drivers JDBC e “ODBC” (SequeLink Server) para o ColdFusion Server MX 6.1 e 7.01, bem como para o JRun 4. Estes drivers são mais novos que os empacotados no JRun 4 updater 6, bem como na última atualização do CFMX, o 7.01. Portanto, a instalação é altamente recomendada (de ambos).

ColdFusion MX 7.0 and 7.0.1: Hot fix available for SequeLink 5.4 Socket server

Updated DataDirect JDBC drivers (version 3.5)

Importante notar que no CFMX 6.1, os novos drivers são dependentes um do outro, portanto ambos devem ser instalados.

Nova versão de JRun à caminho

Segundo o relato encontrado aqui, a Macromedia prepara uma nova versão do JRun (seria o Jrun 5?) para o início do ano que vêm. Obviamente espera-se que esta versão seja J2EE 1.4 ou 1.5 compliance (o JRun e por conseqüência o CF ainda é 1.3). Vale notar (adicionalmente à leitura do link acima), que esta nova versão do JRun, está bem sincronizada com a do novo CF (codinome Scorpio). O que me pergunto é se a Macromedia, err, digo Adobe, continuaria oferecendo o Jrun como um produto separado (mas que é a base para o CF) ou abandonaria de vez o modelo de “produto JRun”, para torná-lo parte integral de produtos como o ColdFusion, o Flex e afins?

Aproveitando: é importante esclarecer uma dúvida que vejo em muitos: não confunda J2EE com J2SE. J2SE é o “motor” básico, o core, do Java, usado tanto para Java Enterprise – J2EE (EJB, por exemplo), como para Java “comum” (Applets, por exemplo). J2EE corresponde a um pacote de instruções e recursos complementares (incluindo classes da API) à implementação básica do Java (standard), alguns chegam até a chamá-lo de “framework”. Usando um JVM da geração 1.5 para rodar uma aplicação Java Enterprise (como o ColdFusion) 1.3, você não está usando J2EE 1.5. São coisas distintas. Desde a versão 6.0, o ColdFusion é uma aplicação J2EE 1.3. Não 1.4, muito menos 1.5, como muitos dizem, apesar de rodar com os motores do Java, cujas versões podem ser 1.4 ou 1.5 (ou 5.0, depende de como a Sun está nomeando isso hoje).

ColdFusion e horário de verão

Entre ontem e hoje andou rolando uma discussão na CF-Brasil sobre uma repentina mudança de horário em servidores rodando ColdFusion, mesmo que o horário do servidor (Windows ou Linux) estivesse corretamente configurado. Muitas máquinas (a minha inclusive) deram um “salto” de uma hora e já estavam funcionando como se estivéssemos em horário de verão. Como eu sempre gerenciei servidores ColdFusion pré-MX, já tinha decorado que o horário do sistema operacional (incluindo time-zone) era determinante para o horário do CF. Não sei onde estava desde 2002, quando a Macromedia lançou o MX 6.0, o fato é que desde esta versão, o “horário” do CF não depende mais do sistema operacional que ele reside (apesar de inicializar-se usando como base as configurações deste), mas sim do JVM (que não deixa de ser o “sistema operacional” onde o CF reside). Por esta razão, por mais que se modificasse o horário do sistema operacional, o horário do CF mantinha-se o mesmo. Óbvio, claro, mas demorei para me tocar. Só hoje, quando vi que algumas das minhas schedule tasks estavam mandando “notícias” (eu costumo criar alertas de e-mail) cedo demais, é que percebi que algo estava errado. Mas não me lembrava bem o quê, mesmo já tendo feito um post relacionado, no passado recente.

O problema é que, da mesma maneira como acontece com o Windows, o JVM tem datas pré-determinadas para inicializar o horário de verão nos time-zones que o adotam. E no caso do time-zone de Brasília, usado pela maioria de nós, esta data era o dia 09/10. Por esta razão, recomenda-se configurar manualmente os argumentos de inicialização do JVM do CF, sobrescrevendo o time-zone que será lido do sistema operacional quando da inicialização do CF/JVM. Além de contornar o problema da data de início pré-definida de horário de verão pelo Java, que, não precisaria repetir, nunca bate com o que o nosso governo estipula (coisa típica do brasil…).

Pois aqui entra uma dica pessoal: ao invés de usar uma time-zone específica (ex America/Sao_Paulo), ou então outra qualquer (como Buenos_Aires, que é GMT+3 mas não tem horário de verão) para “burlar” o ajuste automátivo do Java, eu prefiro usar uma time-zone do tipo Etc/GMT, que não sofre esse tipo de alteração “não-avisada”, pré-programada. Para tal, basta adicionar ao campo Java Arguments do ColdFusion Administrator o seguinte (entendo-se que você queira configurá-lo para o “horário de Brasília”, que por padrão é GMT+3):

Para horário “normal”:

-Duser.timezone=Etc/GMT+3

Em horário de verão:

-Duser.timezone=Etc/GMT+2

Lembrem-se isso deve ser feito, manualmente, sempre quando houver a mudança de horário de verão (entrada ou saída). Para exemplificar, veja um print-screen de como está o Java Arguments do meu servidor neste exato momento (lembrando que ainda não estamos no horário de verão).

Note ainda que eu uso um outro argumento, o -Duser.country=BR, que fará o mesmo para o JVM, porém em termos de configurações regionais (formato de moeda, casas decimais, etc). Papo para outro dia.

Lembre-se de que, ao modificar os argumentos de inicialização, você deve ser cauteloso, caso contrário o servidor poderá não inicializar, nos casos onde você insere alguma coisa a mais ou de menos no JVM arguments. Ou ainda (na maioria das vezes) põe alguma coisa com formatação errada (comum em operações copy+paste). Para evitar isso, recomendo a leitura de um post antigo, sobre modificações que podem ser feitas para o JVM: Heap “agressivo” e mudanças nos settings de JVM.

Technote recomendado:

http://www.macromedia.com/go/tn_18310