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

Locaweb com o ColdFusion MX 7

A Locaweb, que já oferecia hospedagem ColdFusion 5 e MX 6.1, está agora oferecendo hospedagem com o ColdFusion MX 7. Vale a pena conferir.

PHP 6.0

Dizem que uma das grandes novidades do PHP6 (sem data para lançamento) será o suporte à unicode e “melhorias” no seu sistema de debug nativo. Veja aqui.

Não é sempre bom saber que o ColdFusion MX está anos luz à frente nestes aspectos? Sem depender de plugg-ins, de módulos, disso e daquilo (que normalmente requerem recompilar a rebimboca da parafuseta)… Debug nativo sempre foi excelente no CF (desde a versão 4.0), e unicode é nativo desde 2002, com o lançamento do ColdFusion MX 6.0. Para quê facilitar se podemos complicar não é? 😉

Coldfusion MX 7.0.1 (Merrimack) disponível!

Já está disponível a mais nova atualização do ColdFusion MX 7, o CFMX 7.0.1, codinome Merrimack. Este provavelmente será o último milestone antes da versão 8.0 (Scorpio) sair, o que deve acontecer no final do ano que vêm. Não trata-se apenas de um atualizador, mas sim de uma nova versão do CFMX, já que além de oferecer o updater, a versão full, que você baixa do site da MM e as que serão “shipadas” em caixas, já incorporam este release.

Grandes melhorias gerais (foram atualizados drivers JDBC, componentes como o Apache Axis, FlashForms, ReportBuilder, CFDOCUMENT – que agora oferece output em RTF, etc, etc), adicionado a possibilidade de isolar acessos à CORBA nas sandboxes, e também novos recursos, em destaque a possibilidade de se invocar CFCs em classes Java (antes apenas o contrário era possível) e suporte oficial à MacOS. O upgrade é gratuíto para quem possui a versão 7.0.

Download obrigatório. E, como sempre, não deixem de ler o release-notes para saber o que foi corrigido e o que pode dar problema.

Dica importante: para aqueles que usam o CFMX sob o JRun e que já instalaram o Updater6 do JRun4, vale notar que após a instalação do 7.0.1 você deverá reinstalar o JRun4 Updater 6, pois o Merrimack não inclui componentes deste relase/updater, apenas do updater 5. Isso foi uma decisão tomada no programa beta para não atrapalhar o cronograma.