Diego Plentz

Provavelmente quem já desenvolve em java à algum tempo, já passou por esse problema: UnsupportedClassVersionError. Ele acontece basicamente quando tentamos executar um .class compilado com uma versão superior à da JVM que estamos tentando executar (exemplo: rodar um .class compilado com java 1.6 em uma jvm 1.5). Hoje pela manhã estava enfrentando esse problema e não conseguia de jeito nenhum entender o porque.

java.lang.UnsupportedClassVersionError: Bad version number in .class file

Após decompilar uma classe (aproveitando, usei o JD-GUI que funcionou bem no MacOS) que estava rodando no servidor (e *MEH* eu não tinha o fonte), alterar, recompilar na minha máquina e jogar de volta pro servidor, comecei a receber a mensagem de erro. Após revisar todas as configurações do Eclipse (Java Compiler específico no projeto, JRE System Library correto) continuei recebendo o mesmo erro.

Depois de procurar muito, descobri que mesmo alterando todas as configurações no Eclipse, na pasta do projeto ainda ficou um arquivo configurado pra java 6.0. Então se enfrentar o mesmo problema, procure pelo arquivo:

$PROJECT_ROOT/.settings/org.eclipse.jst.common.project.facet.core.prefs

E edite alterando a JRE para a correta para o seu projeto.

Popularity: 1% [?]

Essa semana vi um twitt do Pellegrino comentando da dor de cabeça pra instalar o RMagick. O Kung inclusive sugeriu usar o ImageScience, que eu nunca usei, mas deve ser uma alternativa interessante.

Mas sendo mais prático preguiçoso, sempre existe uma forma mais fácil e menos dolorosa de fazer as coisas. E foi então que achei o rmagick-osx-installer. Basta fazer download, descompactar e executar

ruby rm_install.rb

E depois de todo processo completo (com um pouco de sorte), você verá um lindo resumo como esse:

Summary: There were 0 failures
libpng 1.2.26 was already installed.
libjpeg was installed successfully
ghostscript was installed successfully
ghostscript-fonts-std was installed successfully
FreeType 9.17.3 was already installed.
libwmf was installed successfully
ImageMagick was installed successfully
RMagick was installed successfully
Removing rm_install_tmp directory...Done

Popularity: 6% [?]

Hoje resolvi fazer uma atualização do Rails e cia aqui e dei de cara com um problema chato de resolver. Além de instalar as versões novas dos gems, queria me livrar as antigas. Mas sempre que tentava fazer o gem cleanup, recebia o seguinte erro:

~ plentz$ sudo gem cleanup
Cleaning up installed gems...
Attempting to uninstall mongrel-1.0.1
ERROR: While executing gem ... (Gem::InstallError)
Unknown gem mongrel = 1.0.1

Depois de fazer um find (find . -iname mongrel* mesmo) no / inteiro, descobri um diretório com vários gems antigos. Ele fica em:

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Entrei nele e fiz literalmente um limpa. Apaguei todos arquivos dentro das pastas specifications, doc, cache e gems. Então se quizer deixar sua instalação 100% fresh, rode os comandos abaixo, e caso encontre algum problema, siga a dica acima:

sudo gem update --system
sudo gem update
sudo gem cleanup

Depois confira que você ficou só com as últimas versões rodando: gem list.

Popularity: 4% [?]

Tomcat is deprecated. Use Jetty instead.

É exatamente esse a impressão que eu tenho depois de migrar os nossos servidores para o Jetty. Depois de ver muita gente reclamando de OutOfMemory no Tomcat, inclusive aqui da empresa, resolvemos tentar o Jetty.

A tempo que escutava o pessoal da Caelum (e principalmente o Kung) falando bem do Jetty, mas só quando se começa a usar que se percebe as vantagens. Como temos várias aplicações rodando (diferente do GUJ, que era só o JForum, acredito), imaginei que a troca não seria tão smooth assim.

Claro que antes de sair trocando tudo, fizemos alguns testes pra ter certeza que tudo ia ocorrer bem. Por sinal, a troca foi bem tranquila do ponto de vista da aplicação, só tivemos que fazer alguns ajustes:

• o Jetty lança java.util.Collections$UnmodifiableMap ao tentar modificar diretamente o (Hash)Map devolvido com request.getParameterMap() ao invés de usar o método setAttribute() do request - coisa que o Tomcat deixa;
• Diferenças ao tentar recuperar um resource do sistema utilizando como pasta base “.”, ou usar “..” pra navegar na estrutura de pastas. Para resolver, basta usar como pasta base “/” (ex: “/com/foo/resources/xpto.xml”) e colocar dentro do WEB-INF/classes;
• E a última, mas simples de resolver, é que o Jetty deixa habilitado listagem de diretórios. Você pode alterar isso no etc/webdefault.xml, trocando o atributo dirAllowed para false;

Feitos esses ajustes, chegou a vez de configurar o Jetty para atender aos diferentes domínios. E é aqui que vi uma das grandes vantagens do Jetty. A parte de configuração dele fica muito organizada. Fizemos da seguinte forma:

• Para cada aplicação (pra cada .war na pasta /webapps do Jetty), criamos um arquivo de contexto no /contexts (não é necessário, mas como temos urls diferentes e contextos diferentes, tivemos que customizar - e acabamos ganhando um brinde que conto depois)
• Cada arquivo de context tem uma estrutura estupidamente simples:

  
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/</Set>
  <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/demo_foo.war</Set>
  <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>

  <Set name=”virtualHosts”>
    <Array type=”String”>
      <Item>demo.foo.com</Item>
    </Array>
  </Set>

</Configure>


Explicando por partes:

• WebAppContext é o tipo de contexto que você vai usar, estamos usando esse pois permite o hotdeploy
• contextPath serve para dizer (óbvio) o contexto que quer que a aplicação fique disponível. Aqui prefirimos colocar todas no contexto / e configurar diferentes Virtual Hosts pra cada aplicação.
• a propriedade war só diz qual .war (que pode ser um exploded war também) que vai ser deployado naquele contexto
• na seção que diz virtualHosts, você pode configurar todos os endereços que quer que sua aplicacão responda. Para ela aceitar mais de um endereço, basta ir adicionando Item’s com as outras URLs. Aproveitando, no Jetty 7 será possível usar wildcards!

Com isso feito, ficou muito fácil configurar o deploy automático de todas nossas aplicações, pois basta substituir o arquivo .war e dar um touch no arquivo de contexts que o Jetty faz reload do contexto (e esse é o brinde! )! Agora, com o Jetty combinado ao Hudson, com um clique podemos fazer deploy de qualquer uma das nossas aplicações em um ambiente específico ou mesmo em todos, automaticamente. Mas isso já é assunto para um outro post.

Links Relacionados

• Melhorando o GUJ: Jetty, NIO e load balancing
• Jetty Documentation

Popularity: 5% [?]

Faz dois meses que tento cancelar o BrTurbo. Após me dar conta que eu estava pagando 25 reais por mês para ter um login e poder logar na internet. Procurando um pouco, acabei achando 2 alternativas. O PS5 e o ADSLResidencial. Como o ADSLResidencial era mais barato, optei por ele. Dois minutos para criar um usuário e já sair funcionando. Troquei o login no modem e funcionou de imediato. O boleto paguei 2 dias depois (criei o login no final de semana). Perfeito. Agora “basta” cancelar o BrTurbo. Depois de uma novela de 2 meses, continuo sem conseguir cancelar. Como não teve jeito de fazer pelos meios tradicionais, resolvi abrir um chamado na Anatel. A novela toda pode ser acompanhada aqui.

Mas perai. Qualquer um consegue acessar o meu chamado na Anatel? E se eu trocar o número do chamado? Vamos ver. http://sistemas.anatel.gov.br/focus/FaleConosco/MostrarDetalheSolicitacao.asp?idtSolicitacao=7094111. Excelente. Chamados públicos e com id sequencial. Parabéns equipe Anatel. Muito bom.

Ou seja, qualquer pessoa pode acessar qualquer chamado, pois os mesmos são abertos a público. E pior, com dados que não poderiam ser publicados, como CPF, email, telefone…ótimo não? Mas fica ainda pior. Sempre pode ficar pior. Me dei conta que o login do site da Anatel é a combinação CPF+email. E esses dados são exibidos publicamente. Já entenderam o tamanho do problema, né?

Então já que após 3 dias até agora não escutei um “ah” da Anatel, resolvi fazer uma certa publicidade, pra ver se as coisas andam mais rápido. Por sinal, meu chamado do BrTurbo parece estar andando mais rápido que o chamado deles.

Só fica a dúvida: e a privacidade, Anatel?

update: pra quem não viu, tirei uma screenshot reproduzindo o problema, Anatel tentando corrigir o problema e do site da Anatel “em Manutenção”.
update 2: recebi agora pela manhã uma ligação da responsável pelo sistema da Anatel, agradecendo sobre o alerta e se comprometendo a só colocar o sistema no ar novamente quando tudo estiver resolvido - e me deixou o número para ligar diretamente, caso encontre outro problema. A publicidade funcionou.

Links:

• Baguete - Furo: Anatel retira dados do ar
• Baguete - Furo: Anatel expõe dados pessoais
• iMasters - Anatel exibe dados de usuários na web

Popularity: 12% [?]