Jeveaux's Weblog
Tudo certo e nada resolvido
Posts da tag Ubuntu
Trabalhando com mais de um JDK no Ubuntu
20 jul
Hoje em dia ter o Java5 e Java6 instalados na máquina de um desenvolvedor é praticamente uma obrigação. Java2 1.4 e Java7 também figuram bastante, ao menos aqui por estas bandas.
No meu macbook, que uso para trabalhar, eu controle tudo via a variável de ambiente $JAVA_HOME, é bem tranquilo. Quando quero compilar ou rodar alguma coisa com outro JDK/JVM é só mudar o $JAVA_HOME e pimba!
Quando eu usava Ubuntu sempre tive problemas para instalar mais de um JDK através do apt-get. A instalação era uma maravilha, como sempre no apt-get, mas por algum motivo o JDK e JVM padrões sempre ficavam com a versão mais alta. Eu tentava ‘corrigir’ usando a solução do $JAVA_HOME e incluindo o $JAVA_HOME/bin no $PATH, mas isso só funcionava enquanto eu estivesse no bash ou em aplicações que não fizessem referência direta ao /usr/bin/java.
Recentemente assumimos alguns servidores aqui na Giran e estamos migrando todos para Ubuntu Server. Não vou entrar no mérito dos porquês desta escolha para não criar uma guerra santa. Mas o que importa é que nestes servidores nós queríamos usar o apt-get para gerenciar todos os pacotes, afinal não temos paciência tempo para cuidar de tantos detalhes pequenos em tantos servidores.
Ao instalar um JDK, qualquer versão, através do apt-get, vários comandos estarão disponíveis no $PATH, dentre eles o java, javac, javap, jar, etc. Estes comandos estão sempre /usr/bin, mas são um link simbólico para os comandos em /etc/alternatives, que por sua vez são um link simbólico para o arquivo executável de verdade. Após instalar mais um JDK aí a coisa complica, qual deles será o padrão!? A cadeia de links simbólicos continua a mesma e mudar todos (mais de 15) manualmente não é muito indolor.
As instalações ficam sempre em /usr/lib/jvm/java-$versão, que é exatamente onde vão bater os links simbólicos de /etc/alternatives. No meu caso, por exemplo, tenho estas duas instalações: /usr/lib/jvm/java-6-sun e /usr/lib/jvm/java-1.5.0-sun. Se eu quiser alternar entre elas como padrão para todo o sistema, posso simplesmente usar o comando “update-alternatives” ao invés de sofrer reconfigurando um monte de link simbólico.
Então vamos lá:
spock@vulcan:~$ sudo update-alternatives --config java
There are 2 alternatives which provide `java'.
Selection Alternative
-----------------------------------------------
+ 1 /usr/lib/jvm/java-6-sun/jre/bin/java
* 2 /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
Press enter to keep the default[*], or type selection number: 2
Using '/usr/lib/jvm/java-1.5.0-sun/jre/bin/java' to provide 'java'.
E pronto, simples assim. O item com o sinal de + (mais) é a opção default e o item com o sinal de * (asterisco) é a opção atual.
Ativando Syntax Highlighting no VIM
11 jun
Recentemente participei de algumas discussões nas listas que participo que abordaram ambiente de desenvolvimento e, consequentemente, editores e IDEs. A escolha do editor ou da IDE é algo completamente particular e extremamente pessoal, e depois que alguém adota alguma ferramenta, não adianta alfinetar ou empalar com uma lança, as opiniões dificilmente mudarão, não importa quais ou quantos argumentos forem usados. Até mesmo por isso não quero falar sobre melhor ou pior aqui.
Numa dessas discussões, inevitavelmente começaram a falar sobre o VIM e num determinado momento alguém exclamou que o VIM era tão ruim que nem Syntax Highlighting fazia. Mas oras, é claro que faz. Uma dica rápida.
1) Ativando Syntax Highlighting manualmente
Durante a edição de um arquivo, você pode ativar ou desativar a Syntax Highlighting quando quiser. Para ativar:
:syntax on
E para desativar:
:syntax off
2) Ativando Syntax Highlighting automaticamente
Se você quiser, pode deixar que o VIM faça isso automaticamente sempre que possível. Pra isso edite o arquivo vimrc e adicione o trecho abaixo. No Linux esse arquivo geralmente fica em /etc/vim/vimrc, enquanto no Mac OS X você o encontrará em /usr/share/vim/vimrc.
if has("syntax")
syntax on
endif
E é isso. Feche e abra o próprio arquivo vimrc e veja as diferenças. No meu caso ele ficou assim:
Os arquivos de syntax ficam no diretório syntax dentro do diretório de instalação do vim, pro caso de você querer mudar alguma coisa.
Apache2 e Tomcat com mod_jk
3 mai
Nesses últimos dias trabalhei bastante na administração e configuração de servidores *nix na Giran, revivendo algumas experiências antigas e aprendendo muitas outras novas e estou aproveitando para escrever um pouco sobre elas.
Configurando um servidor de desenvolvimento da Giran as novidades não foram grandes, a maioria das aplicações, serviços e preocupações foram as mesmas de um ambiente de desenvolvimento local. Já as experiências com a configuração do servidor de produção foram bem mais legais e algumas inéditas. Oracle, MySQL, SVN, Gitorious, Ruby Enterprise Edition + Passenger e claro, Apache 2 HTPP Server e Apache Tomcat.
Por hora vou escrever apenas sobre o mod_jk, que é a integração entre o Apache 2 HTPP Server e o Apache Tomcat. Eu já tive experiências anteriores com o mod_jk em ambientes de produção, em ambientes com redudância, com tomcat, com jboss e alguns mais, mas ainda não havia passado por uma situação onde eu iniciasse do zero e todas as responsabilidades estivessem comigo, e isso foi ótimo.
Um resumo do ambiente:
- Ubuntu Server 8.04
- Apache 2 HTTP Server 2.2.8
- Apache Tomcat 6.0.18
- JDK 1.6.0_13
O Apache
O Apache e o mod_jk foram instalados usando o próprio apt-get, então esta tarefa foi realmente muito fácil:
jeveaux@baium ~ $ sudo apt-get install apache2 libapache2-mod-jk
Uma série de pacotes e dependências virão junto com os dois pacotes acima, pode confirmar que tudo vai dar certo.
Esta instalação deixará o Apache em /etc/apache2, onde nós teremos (os principais arquivos):
- httpd.conf – Configuração geral do apache.
- conf.d – Configurações diversas, todos arquivos que estiverem nesse diretório serão carregados como configuração.
- mods-available – Arquivos de configuração e ativação dos módulos.
- mods-enabled – Módulos que estão ativados no apache, são links simbólicos para os arquivos do diretório mods-available.
- sites-available – Arquivos de configuração dos sites (VirtualHost).
- sites-enabled – Sites que estão ativados, são links simbólicos para os arquivos do diretório sites-available.
No httpd.conf poucas coisas precisam de intervenção, pessoalmente eu gosto muito deste esquema de organização e divisão de configurações utilizada pelo apache. Por exemplo, tudo que estiver no diretório APACHE2_HOME/mods-enabled será carregado automaticamente, primeiro todos os arquivo .load, que geralmente contém o LoadModule, e depois todos os arquivos .conf, que contém as configurações específicas do módulo, desta forma temos vários pares load+conf, um para cada módulo.
O JDK e o Tomcat
Apesar do servidor ser Ubuntu, desta vez eu não usei o apt-get. Eu sempre preferi instalar o JDK e algumas outras ferramentas de forma manual, não sei exatamente porque tenho essa mania, mas não consigo fugir.
O que importa é que o JAVA_HOME e o PATH estejam ajustados, se isso estiver correto tanto faz se você instalar usando o apt-get ou não. De qualquer forma, se você optar por usar o apt-get, basta seguir o comando abaixo:
jeveaux@baium ~ $ sudo apt-get install sun-java6-jdk tomcat5.5
Se não, se você for paranóico como eu, certifique-se de ter configurado o JAVA_HOME e o PATH manualmente no seu .bashrc:
export JAVA_HOME=/development/jdk1.6.0_13
export PATH=$JAVA_HOME/bin:$PATH
O mod_jk
O mod_jk já foi instalado anteriormente, então só precisamos certificar de que ele esteja ativado.
Caso você queira ativar ou desativar um módulo, existem duas maneiras: 1) usar os comandos a2enmod <mod> e a2dismod <mod> ou simplesmente criar ou remover os links simbólicos em APACHE2_HOME/mods-enabled.
1) Configurar os workers
A instalação foi tão simples que somente um arquivo nos interessa por enquanto: /etc/libapache2-mod-jk/workers.properties. Abaixo apenas as configurações mais importantes e algumas que precisaremos alterar:
workers.tomcat_home=/development/apache-tomcat-6.0.18
workers.java_home=/development/jdk1.6.0_13
worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=1
No workers.properties temos o mapeamento do tomcat (workers.tomcat_home) e do JDK (workers.java_home). Há outra propriedade muito importante que é a worker.list, nela definimos todos “workers” que teremos. Para um único servidor teremos apenas um worker, mas em ambientes de cluster teremos vários. E temos para cada worker as suas configurações particulares: port, host e type, além de uma em particular, muito importante em ambiente de cluster e load balancer, a lbfactor, que indica a quantidade de trabalho do worker no conjunto, quanto menor o valor, menor o esforço do worker, ou seja, menos requisições serão despachadas para este worker.
2) Iniciar (ou montar) o JK
Mais uma vez temos dois caminhos a seguir aqui. Iniciar o JK no site principal ou em algum VirtualHost (sub-domínio) específico. O que vai mudar é onde você vai inserir o código a seguir.
Caso queira colocar o JK no seu site principal, você poderá inserir o código abaixo no seu httpd.conf – o que eu não recomendo – ou criar um arquivo jk.conf em APACHE2_HOME/mods-available, depois criar o link simbólico para este arquivo em APACHE2_HOME/mods-enabled.
Mas se você quiser ou precisar usar o JK somente em algum site e/ou sub-domínio específico, insira o código abaixo direto no arquivo do site em APACHE2_HOME/sites-enabled.
JkWorkersFile /etc/libapache2-mod-jk/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkMount /*.jsp ajp13_worker
JkMount /teste/* ajp13_worker
Com essas configurações estamos escolhendo qual arquivo de workers vamos usar (JkWorkerFile), ou seja, qual o tomcat e JDK. Também definimos o arquivo de log e qual o tipo de log será gravado e, o ponto chave, quando o JK será usado. O JkMount pode ser repetido quantas vezes for preciso e é nele que definiremos todos os padrões de URL quanto forem precisos para que o JK seja usado.
É neste momento, configurando o JkMount, que podemos dividir o processamento de recursos dinâmicos (jsp, servlet) para o Tomcat e recursos estáticos para o Apache. Não vou entrar nesse ponto neste artigo, mas fica a dica.
Com o trecho acima estamos encaminhando para o tomcat – através do JK – tudo que terminar com .jsp ou tudo que estiver após /teste.
O Deployment
Aqui tudo correrá como qualquer aplicação Java, sem nenhuma diferença. Chamaremos nossa aplicação Java de “teste”. Após o deploy podemos acessa-la como de costume em http://localhost:8080/teste, mas agora com o JK podemos acessar também através da porta 80 (apache) em http://localhost/teste.
Maven ‘mvn release:prepare’ falhando com SVN
30 dez
Um problema com a geração de releases com o maven tem incomodado muita gente nas últimas semanas. Trata-se de alguma incompatibilidade entre o maven e os clientes de SVN de versão superior a 1.5.x. O problema ocorre na preparação da release (mvn release:prepare) e diz que o pom.xml já existe no diretório da tag que nem foi criada ainda.
Existe uma solução bem simples que deverá funcionar de primeira caso seu ambiente de desenvolvimento seja *nix que é basicamente executar um update na sua working copy antes de preparar a release:
svn up -r head
mvn release:prepare
Entretanto, se você não tem vergonha na cara e desenvolve no windows o procedimento é um pouco mais chatinho, vejamos:
mvn release:prepare
## vai dar erro, continue
svn up -r head
mvn release:prepare -Dresume
E se você tiver o TortoiseSVN instalado mate o processo TSVNCache.exe antes de executar os passos acima.
Há esperanças de que a versão 1.5.5 do SVN Client dê um fim nesse problema, mas enquanto ela não chega temos que nos contentar com essa gambiarra terrível. Provavelmente este procedimento deverá ser executado no release:perform também.
Xvfb: Como usar o Selenium sem ter um X Server
11 nov
Escrever testes com Selenium geralmente é uma tarefa que, ou é amada ou é odiada com todas as forças do indivíduo que a executa. Isso acontece principalmente devido às inúmeras formas e ferramentas disponíveis para escrever os seus testes de aceitação. Por exemplo, em Rails quem usa o Cucumber com certeza deve gostar muito de escrever tais testes, já quem usa o Selenium IDE não deve ficar muito feliz depois de algumas semanas repetindo várias e várias coisas.
Executar os testes é outra tarefa muito legal e motivante, ver as coisas acontecendo de forma automática é lindo, mas com o tempo isso começa a ficar muito chato, cansativo e a levar tempo de mais, tempo que você não pode esperar toda vez que quiser fazer um commit ou um push ou até mesmo uma integração para build. Com isso vem a idéia de um servidor de integração contínua onde todos os testes serão executados automaticamente do jeito que você desejar: a cada commit/push, tantas vezes por dia, etc.
Novamente tudo fica muito bom quando o servidor de integração contínua está executando tudo e dando conta do recado, mas e se o servidor disponibilizado não tiver um ambiente gráfico? Ou melhor, e se você questionar a razão de ter um ambiente gráfico num servidor como esse? Bom, há de pensar que sem interface gráfica não é possível executar o browser (exceto o lynx, eu sei), então o que fazer? Para resolver este problema existe o Xvfb, um projeto que serve exatamente para máquinas sem display.
O Xvfb cria um buffer virtual em memória e executa o X Server a partir daí, redirecionando o que deveria ser a saída VGA para a memória, e com isso você consegue um X Server virtual rodando sem display, apenas em memória. Com isso já é possível rodar o browser (e qualquer outra coisa que precisa de um X Server), logo, é possível executar todos os seus testes do Selenium. Um detalhe interessante é a possibilidade de ter qualquer resolução disponível agora, mesmo aquelas que um monitor não poderia te proporcionar.
Vamos agora a instalação e execução do Xvfb:
Instalando o Xvfb
jeveaux@valakas ~ $ sudo apt-get install xvfb
Executando o Xvfb
jeveaux@valakas ~ $ Xvfb :1 -screen 0 1600x1200x32
Com o comando acima vamos iniciar um novo servidor X (:1), screen 0 (-screen 0), resolução de tela de 1600×1200 e 32bits de cores. Agora para abrir o firefox neste servidor:
jeveaux@valakas ~ $ DISPLAY=:1 firefox
E se você quiser acessar visualmente a saída criada pelo Xvfb pode usar algum cliente VNC como o x11vnc e conectar-se no display criado:
jeveaux@valakas ~ $ sudo apt-get install x11vnc
jeveaux@valakas ~ $ x11vnc -display :1
E pronto! Obviamente o Xvfb não deve ser usado exclusivamente para o Firefox/Selenium, este post foi apenas uma abordagem dentre as milhares de soluções que podem se beneficiar de um X Server virtual.
Últimos Comentários