Tecnologia da Informação

A depuração ( debug ) de código é uma ferramenta valiosa na procura de BUGs em programas e no entendimento de como as chamadas acontecem dentro de uma aplicação complexa, principalmente se forma aplicações Java EE.

Atualmente a maneira mais eficiente e menos intrusiva de fazermos isso é usando o debug remoto baseado no JPDA ( Java Platform Debug Architecture ).

Para configurar o DEBUG ( depuração ) de código no servidor Glassfish usando o NetBeans 6 Debugger seguimos os simples passos abaixo:

1 – Na Console Administrativa do Glassfish, acessar as opções:

• Application Server – JVM Settings – General
• Habilitar o DEBUG ( veja o círculo vermelho )

2 – Clique no botão SAVE para salvar as novas configurações.

3 – Aparecerá um aviso de que é necessário reiniciar o servidor para que as alteracões tenham efeito.

4 – Durante o start-up com as novas configurações a console de log mostrará que a porta 9009 está liberada para conexões de debug remoto ( veja em vermelho )

5 – Faça o deploy dos componentes Java EE no servidor.

6 – Defina os breakpoints na visão de edição do código fonte clicando na barra cinza com a numeração de linhas.

A linha do breakpoint ficará marcada com um fundo rosa e aparecerá na lateral um quadradinho informando o breapoint criado.

7 – Anexe ( attach ) o depurador ( debug ) do NetBeans.

Em vermelho vemos as configurações do JPDA habilitado no servidor configurado anteriormente.

8 – Quando qualquer Thread de qualquer requisição ou serviço passar pelo Breakpoint o NetBeans interromperá dando um aviso do depurador

9 – A barra de botões de ações permite navegar entre as chamadas de código das classes ou até sair delas e interromper a depuração ( debug ).

Boa diversão!

Comentários fechados devido á spans!

A ComputerWorld, recentemente publicou um artigo sobre a Tecnologia Java,
mas discordo completamente de tal análise.

Vejo que o mercado se acomodará de acordo com suas necessidades,
por tipo de necessidade de “client” e capacidade de processamento “server”,
mas somente a Tecnologia Java atualmente consegue ser o “martelo certo” para
quase todos os problemas computacionais, desde o “mobile”, passando pelo “server”,
incluindo “integration” e o “desktop”.

Acreditem, temos 13 anos de Java, e acho essa tecnologia e suas plataformas evoluirão
constantemente por mais uns 20 anos em ondas associadas a Web 3.0, Federation,
RFID, Virtualização, GRID Computing, etc.

Não esqueci de SOA, é que SOA é tão antigo quanto a especificação que permitiu
a descoberta e uso do AJAX, pois é um Padrão de Arquitetura associado a ferramentas
e especificações que não são novas: WebServices, Messaging, ETL, etc.

Independente do que a Microsoft faça, e a ComputerWorld diga, a plataforma .NET
ainda é considerada pelas empresas uma solução barata, fácil de desenvolver,
que qualquer programador medíocre é capaz de aprender e fazer “aplicativos”,
mas extremamente amadora do ponto de vista de “confiabilidade” para a construção
de “sistemas” integrados e robustos, principalmente quando falamos em aplicações
com grandes volumes de dados e usuários.

Recentemente até o Banco Itaú, que declaradamente só usava a plataforma .NET
se rendeu ao Java EE, e já está “migrando” seus sistemas do Internet Banking para
Java EE rodando em WebSphere no Mainframe, pois o Itaú estava gastando muito $$$$
para administrar e provisionar recursos para os mais de 170 Servidores IIS rodando .NET.

A IBM do Brasil tem mais 4 grandes casos de sucesso de outros bancos que estão fazendo o mesmo.

Ou seja, temos espaço para todos os tipos de ferramentas para variados tipos de problemas, entretanto, existem soluções “mais adequadas” em prazo-custo-qualidade que outras, e atualmente a plataforma Java EE tem se mostrado a que melhor resolve essa equação.

Bom trabalho a todos.

Comentários fechados devido á spans!

Muitas aplicações usam o Log4J e seu empacotamento/inicialização
podem se tornar um problema em servidores que tem múltiplos classloaders
para separar componentes do servidor dos módulos e aplicações.

Dessa forma descobri uma maneira muito simples de configurar o Log4J
na inicialização do Glassfish ou do Sun Java System App Server nas versões 7, 8 e 9
que elimina a necessidade de ter um listener para inicializá-lo e configurar as categorias
bem como empacotar o Log4J em cada módulo ou aplicação.

1 – Faça o Download do Log4J

2 – Copie o log4j-x.jar no diretório $APP_SERVER_HOME/domains/domain1/lib/ext

3 – Insira as propriedades abaixo alterando a seção do domain.xml ou via a console
administrativa as propriedades da JVM


<jvm-options>

-Dlog4j.configuration=file:${com.sun.aas.instanceRoot}/config/log4j.xml

</jvm-options>
<jvm-options>

-Dlog4j.configuratorClass=org.apache.log4j.xml.DOMConfigurator

</jvm-options>


4 – Crie um arquivo log4j.xml no diretório $APP_SERVER_HOME/domains/domain1/config
com os appenders e as categorias configuradas baseado no modelo abaixo:

5 – Em cada uma das classes que se deseja ter o uso do Log4J,
defina o Logger assim:


package app.package;
public class MyClass {
private static Logger logger;
static {
try {
logger = Logger.getLogger( MyClass.class );
} catch (Exception e) {
e.printStackTrace( System.err );
}
}
}

Boa sorte!

Comentários fechados devido á spans!

Panomara do mercado de servidores de aplicação Java Enterprise.

Tenho certeza que muitos se perguntam: Qual o melhor servidor de aplicações do mercado?

Esta resposta não é tão simples, pois atualmente temos:

1. Java2 EE 1.4: 17 fornecedores certificados
2. Java EE 5: 9 fornecedores certificados

De fato, não temos como saber qual o melhor servidor,
mas temos como identificar qual o fornecedor e produto que melhor se enquadra para cada organização.

Sugiro um método símples para adoção do servidor de aplicações:

1. Verifique se o servidor é certificado pela Sun/JCP/Padrões ( lista de compatibilidade ).
2. Verifique se o fornecedor tem suporte nível 1, 2 e 3 no país.
3. Verifique se o produto além de estar certificado, oferece ferramentas web de monitoração,
   gerenciamento de configuração e publicação.
4. Verifique as formas de licensiamento e custo, pois geralmente variam por tipo de contrato,
   empresa, número de servidores, etc ( ambientes complexos tem contratos complexos ).
5. Verifique a lista de BUGs documentados do produto, pois muitas vezes esses BUGs podem
   ser eliminados com dicas/configurações fornecidas pelo fabricante.
6. Verifique se o produto usa partes de produtos OpenSource, pois dessa forma
   temos certeza que a empresa aposta na evolução do mesmo.

Se o servidor se enquadra em todos o itens acima e o preço cabe no budget do projeto,
então pode-se criar uma tabela como abaixo pontuando o itens e ter-se a média.

Fórmula NOTA: = ( ( C + S + P + F + B + O ) / 53 ) * 10

Sempre devemos dar preferência por produtos certificados pela SUN,
e aquele que tiver a melhor nota, fica com a preferência de escolha.

Atualmente o mercado de Servidores de Aplicações Java tem grande concorrência
entre Oracle, IBM, SAP e SUN, e o market share maior de instalações “pagas” é da IBM,
devido á sua agressividade comercial. Nos ambiente de desenvolvimento, e instalações “open”
baseadas em produtos Free, o líder é o JBoss AS.

O site TheServerSide.com tem um artigo interessante sobre servidores de aplicação e uma matriz de compatilidade

Bom trabalho a todos.

Comentários fechados devido á spans!