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.

Trimando variáveis para sempre

Uma dica óbvia e simples (por isso mesmo bastante elegante) que encontrei hoje no blog de Tjarko Rikkerink . É muito comum utilizarmos a função Trim() para “limparmos” espaços vazios antes e depois das strings toda vez que precisamos manipulá-las com mais precisão ou então para inserí-la num banco de dados com informações provenientes de um formulário. Eis que ao invés de usar Trim() em todos estes lugares (ex: #Trim(form.campo)#) correndo o risco de esquecer em alguns, você pode configurar um “motor” geral para executar isso no seu Application.cfm (por exemplo). Ele faz uso de looping sobre a estrutura/escopo que você desejar (form, attributes, url, etc – lembrando-se de manipular somente escopos que permitem isso) e faz todo o trabalho automaticamente. É menos performático que fazer ponto-a-ponto, mas ainda sim muito prático:

<cfif isDefined("form.fieldnames")>
<cfloop collection="#form#" item="formfield">
<cfset form[formfield] = trim(form[formfield])>
</cfloop>
</cfif>

Problemas na instalação do ColdFusion MX 7

O problema com a instalação do CF MX 7 de que o arquivo que você faz download pode estar corrompido já é conhecido da maioria dos programadores e desenvolvedores. Segui todos os passos e verifiquei tudo que tinha explicado no site da Macromedia e nada! Simplesmente não conseguia instalar o ColdFusion. Foi então que decidi instalar o Firefox no servidor e baixar mais uma vez o arquivo de instalação do servidor CF. Foi então que maravilhosamente tudo funcionou normalmente. Ai fica a dúvida. O problema é realmente da Macromedia? Do Instalanywhere? Do Internet Explorer? Ou de todos juntos? Só sei que perdi duas horas hoje tentando resolver o problema. Espero que alguem mais que tenha o mesmo problema possa tirar proveito dessa postagem.

Web service operation “MethodName” with parameters {…} could not be found

Hoje, ajudei um amigo a debugar um problema muito esquesito usando web services com o ColdFusion MX 6.1.

Não importava como chamavamos o web services e o tipo de dados que retornavamos. A página que invocava o serviço sempre retornava uma mensagem de erro do tipo:

Web service operation “MethodName” with parameters {…} could not be found

O componente que ele havia programado retornava uma query que era filtrada a partir de alguns argumentos passados para o web service do tipo http://www.meuservidor.com.br/ws/meucomponente.cfc?wsdl (sendo o ws um mapeamento feito no ColdFusion).

A primeira coisa que resolvemos fazer foi simplicar o componente para retornar apenas uma string. E então ele continuou recebendo o mesmo erro.

Depois de muitas tentativas, resolvi chamar o web service de um outro servidor CF. E então, como um passe de mágica, o web service retornou exatamente o que queriamos.

A única conclusão que posso chegar é que existe algum problema de gerenciamento de cache para web services. No caso do meu amigo, ele não podia reiniciar o serviço do ColdFusion. Então a única forma de “limpar o cache” desse web services foi fazendo uma requisão a partir de uma outra maquina rodando o ColdFusion.

Obviamente, antes de tentar resolver o problema por esse método de tentativa/erro pesquisamos muito no Google e nada de respostas concretas e claras…

Enfim, algumas vezes temos que agir quase que por instinto para resolver os problemas que nos ocorrem. Se algum dia alguem tiver uma explicação técnica/racional/lógica para isso favor comentar!

Cordiais Saudações

CFEclipse 1.2

Nesse final de semana foi lançada a versão 1.2 do CFEclipse, um plug-in para facilitar o desenvolvimento em ColdFusion no Eclipse, uma já consagrada IDE de desenvolvimento.

Tão consagrada, aliás, que a Macromedia está apoiando o projeto em duas frentes: visando colaborar com o CFEclipse e com seu projeto Zorn, uma IDE para Flex.

Muitas pessoas reclamaram que ao contrário do Dreamweaver, o editor de códigos ActionScript do Flash 8 sofreu poucas mudanças e melhorias significativas. Um dos motivos que levou a Macromedia a investir menos tempo no editor de código do Flash 8 é que a mioria dos programadores estão utilizando outra IDE para escrever seus códigos.

500 null em Custom Tags CFX com Sandbox Security

A Macromedia acaba de lançar um technote sobre um bug que afeta o ColdFusion MX 7 e que estava deixando muita gente de cabelo em pé (principalmente provedores de hospedagem que oferecem CF7 em ambiente compartilhado-sandboxeado). O bug foi levado ao conhecimento da equipe de engenheiros da MM dentro do beta-program do novo updater (para CF7), codinome Merrimack e resolveu-se publicar um workaround (veja o technote) dado que o número de usuários com problemas é bastante grande. Trata-se de uma mensagem de erro “500 null” que é retornada ao browser (em tela toda ou no pedaço onde se invoca-a) ao se utilizar uma custom tag CFX (feitas em C++ em sua maioria)

Não deixe de conferir (e aplicar o workaround proposto – seguro para ambiente compartilhado):

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