BlogCFC e “fully qualified names”

No blog da DClick estamos utilizando o sistemas de blog BlogCFC, escrito em ColdFusion por Raymond Camden, programador ColdFusion provavelmente bem conhecido do pessoal – ele mantém alguns projetos interessantes, como a lista CFCDev, CFLib e afins.

A idéia de utilizar o BlogCFC foi que justamente ele era em ColdFusion, de modo que seria fácil customizá-lo e utilizarmos em nosso servidor de hospedagem (que já tinha o CF instalado). Um das primeiras coisas que notei quando baixei o sistema de blog foi a grande quantidade de funções createObject() em objetos Java, e o nosso servidor de hospedagem usa sandbox security e por razões óbvias, bloqueia o uso de objetos Java no servidor, algo que aprovo e sempre sugerimos aqui no blog.

Então eu fiz algumas modificações no BlogCFC para utilizar funções nativas do ColdFusion (como LSDateFormat()) ao invés de um componente customizado que era utilizado para fazer a internacionalização do sistema, e que usava extensivamente objetos Java para tal. Aliás, embora o componente de internacionalização era muito bom e completo, não via necessidade de utilizá-lo nesse sistema, ainda mais tratando-se de um sistema que a maioria dos deploys seria em um ambiente compartilhado! Essa foi uma coisa que definitivamente não gostei no BlogCFC: utilizar funções Java para fazer algo que já existem funções nativas do ColdFusion para lidar.

Feita as alterações o blog foi para o ar e funcionou perfeitamente. Porém, quando o nosso provedor de hospedagem instalou o ColdFusion Cumulative HotFix 2 (sim, um provedor preocupado com as atualizações!), nós começamos a ter problemas com o blog, o pior deles: o blog simplesmente parou de funcionar, enquanto o site da DClick, que também é feito em ColdFusion, continuava a rodar normalmente.

O erro que estava dando era de “NullPointerException”, que além de não apresentar nenhum motivo aparente, ainda poderia significar uma porção de coisas, e sem pistas esclarecedoras em nenhum log e debug do ColdFusion. Com debugs à mão e ajuda do provedor, nós concluímos que o HotFix 2 com sandbox estava causando o problema! E na documentação do HotFix, nada havia sobre sandbox. Foi feito o rollback para o HF1, prevalecendo o sandbox. O HF2 pode ser retirado sem problemas, já que ele corrigia problemas específicos que não eram presentes nas aplicações daquele servidor.

Com mais algum tempo e mais debug na mão, fiz duas simples modificações no arquivo blog.cfc, alterando utilizando o “fully qualified name” (o caminho completo do arquivo, incluindo o pacote em que ele se encontra no servidor) do componente, ao invés de apenas o nome de arquivo.

De:
<cfset variables.utils = createObject(“component”, “utils”)>
e
<cfset variables.ping = createObject(“component”, “ping”)>

Para:
<cfset variables.utils = createObject(“component”, “org.camden.blog.utils”)>
e
<cfset variables.ping = createObject(“component”, “org.camden.blog.ping”)>

Nota: a versão utilizada era a 4.0.2.

Feito isso, o blog voltou a funcionar normalmente no servidor, inclusive com o HotFix 2 instalado, ainda sob sandbox security. Esse problema só afetou portanto, quem alterou o BlogCFC para não utilizar mais objetos Java (para rodar em um servidor com sandbox) e o rodou sob um CF 7.0.1 com o HF 2. Pelo visto, só eu… Não sei exatamente qual a relação do sandbox com os nomes completos dos componentes, mas parece coerente, já que o nome completo indica justamente o diretório em que os componentes estão.

Aliás, é até uma boa prática sempre utilizar o nome completo dos componentes. Facilita a leitura, evita duplicidade e em alguns casos e linguagens orientadas a objeto, é obrigatório. No Flex por exemplo, se você declarar uma classe sem o package e você precisar instancia-la de outro pacote (portanto terá de usar o fully qualified name para tal), o Flex acusará um erro. Afinal, o nome da classe é apenas “MyClass” ou “com.projeto.MyClass”?

Hoje o BlogCFC está na versão 5 mas aparentemente esses dois mesmos problemas continuam (objetos Java desnecessário e instanciando componentes somente pelo seu nome).