Lado Servidor

Aqui no Lado Servidor, utilizamos o Git para compartilhar uma série de projetos. E buscávamos uma opção de repositório privado, e gratuito, onde pudéssemos manter um repositório remoto e central.

O GitHub oferece esse serviço, e muitos outros recursos excelentes. Entretanto nosso time é pequeno optamos por algo mais objetivo e sem incrementos. A opção escolhida foi o Dropbox. Sem mais delongas, vamos ao passo-a-passo:

Dica rápida!

1. Abra o AppleScript Editor;
2. Entre com o seguinte script (tudo numa única linha):
   

   do shell script "bash; HOME=/Users/$USER/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox"

   
   
3. File > Save As... escolha "Application" como o formato;

Ainda não utiliza o Dropbox? Clique neste link para criar sua conta!

__| Sessão de Q&E de Java EE 6, GlassFish, JavaME e Java SE 7 ao vivo |__

Na tarde da Terça-feira da próxima semana, os evangelistas da Oracle Arun Gupta e Roger Brinkley vão conversar diretamente com VOCÊ, independentemente de onde você esteja, e responderão suas duvidas sobre a plataforma Java.

Vamos transmitir ao vivo, pela Internet, uma sessão de perguntas e respostas sobre Java EE 6, GlassFish, JavaME e Java SE 7. Você envia suas dúvidas e perguntas para a lista de discussão do DFJUG, em http://www.grupos.com.br/grupos/dfjug ou pelo Twitter do DFJUG, em http://twitter.com/#!/dfjug e o Roger e o Arun responderão ao vivo suas perguntas.

Anteriormente no Apache Tomcat 5.5, existiam 3 diretórios que pudessem conter JARs de bibliotecas, para serem compartilhados entre as aplicações. Na época, era uma confusão.

À partir da versão 6, tudo ficou mais simples, com um único diretório: lib. Na versão 7 isto foi mantido. Porém pode ser o caso de se querer usar um diretório separado para bibliotecas de frameworks. Misturar isso com os JARs do Tomcat parece arriscado e insensato.

Ontem eu passei por um problema gravíssimo em ambiente de produção: pouco tempo após a aplicação entrar no ar, o diretório $JBOSS_HOME/server/${jboss.server.name}/tmp/vfs-nested.tmp/ estava estourando o espaço em disco destinado a partição em que o JBoss estava instalado e, em função disto, a aplicação começou a apresentar erros. Resultado: tivemos que retroceder num processo de migração até descobrir solução para o defeito :-( O que causou o problema?

A especificação de Java EE define algumas limitações para o desenvolvimento de aplicações dentro da plataforma, como por exemplo a abertura de server sockets, utilização do mecanismo de reflection e a criação de threads. Esse post tenta compreender melhor o porque desse último.

Atualmente é bem comum nos depararmos com um cenário onde os servidores não possuem ambiente gráfico instalado. Neste caso, saber se virar bem no shell é uma arte importante, que deve ser aperfeiçoada a cada dia que passa.

Neste post, mostrarei como fazer tarefas simples no VirtualBox através de sua interface por linhas de comando (pela falta de uma interface gráfica ou porque você só quer executar tarefas via SSH em uma VM, e nada de mais).

Uma situação que comumente vivencio ao migrar uma VM Linux Ubuntu (rodando no VirtualBox) de uma máquina para outra, é que a interface de rede eth0 fica inativa pelo fato da VM passar a ser executada em um HOST com um endereço MAC diferente. Neste caso, eth0 fica inativo e o Linux cria uma nova interface, por exemplo eth1.

Há alguns dias fiz uma cópia do HD da vm-curso-ladoservidor para modificá-la e utilizá-la em host Windows 7 com o VirtualBox 4.0 instalado (às vezes tenho que fazer isto).

O problema é que hoje eu precisei criar a vm-curso-ladoservidor na mesma máquina em que fiz a cópia de seu disco (arquivo .vdi) com um outro nome. Fui criá-la e, ao mandar adicionar seu disco, obtive a seguinte mensagem: