Blog do José Jr: janeiro 2013

INTRODUÇÃO

Nesse artigo vamos mostrar o isolamento de classloaders no JBoss AS 7. Esse isolamento permite eliminar erros chamados de “Classloader Hell” que pode ocorrer nas seguintes situações:

Se em tempo de compilação usarmos uma biblioteca de terceiros, como a Apache Commons na versão 1.2.7 (por exemplo), mas em tempo de execução no servidor de aplicações a biblioteca usada estiver na versão 1.2.6 e classe em questão não possuir o método que existe na versão 1.2.7 pode levar a JVM do servidor a lançar a exceção java.lang.NoSuchMethodException.
Ou então, se a biblioteca Apache Commons usada em tempo de execução for de versão diferente da versão usada em tempo de compilação, mas os métodos usados na aplicação existem nas duas versões da biblioteca, isso pode levar a comportamentos anêmicos, pois no desenvolvimento usamos uma implementação da versão da biblioteca, mas na execução, usamos outra implementação e mesmo que aparentemente não ocorra exceções como java.lang.NoSuchMethodException, java.lang.ClassNotFoundException, java.lang.NoClassDefFoundError e outras exceções semelhantes, o comportamento da aplicação será imprevisível.
Como os classloaders seguem uma hierárquia na qual, um classloader delega a chamada para resolver a classe para outro classloader, temos o problema de um determinado classloader carregar uma classe de uma biblioteca e outra classe de outra biblioteca, que possuam os nomes completos qualificados iguais. Isto é, teremos aplicações que a principio, deveriam carregar todas as classes da mesma biblioteca, mas na realidade (em tempo de execução), há um carregamento parcial de classes de um jar e outro carregamento parcial de outro jar, e assim, gerando um comportamento imprevisível.

Então, para eliminar esses problemas, a equipe de desenvolvimento do JBoss AS, resolver reescrever o servidor aplicações JBoss AS para eliminar esses erros recorrentes de classloaders na versão 7.x.

PREPARAÇÃO DO AMBIENTE

Para testar / analisar esse isolamento, vamos criar o projeto EAR de nome “TestEAR” e cujos módulos serão mostrados na figura a seguir.

Nesse figura temos o projeto “TestEAR” contendo 2 projetos EJB's que são “Test1EJB” e “Test2EJB”. E dois projetos web que são “Test1WAR” e “Test2WAR”. A seguir será mostrado o código do arquivo “application.xml” que define os módulos dentro do EAR.

<display-name>TestEAR</display-name>

<initialize-in-order>true</initialize-in-order>

</module>

</module>

<web>

<web-uri>Test1WAR.war</web-uri>

<context-root>Test1WAR</context-root>

</web>

</module>

<web>

<web-uri>Test2WAR.war</web-uri>

<context-root>Test2WAR</context-root>

</web>

</module>

</application>

E também, como estamos usando o servidor de aplicações JBoss AS 7, necessitamos usar o arquivo “jboss-deployment-structure.xml” que define as dependências entre módulos, exclusão de pacotes, uso de módulos do jboss, etc. Esse arquivo deve estar na pasta raiz do projeto EAR ou na pasta META-INF do projeto EAR junto com o arquivo “application.xml”. Esse arquivo será mostrado a seguir.

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">

<ear-subdeployments-isolated>false</ear-subdeployments-isolated>

</dependencies>

</deployment>

<sub-deployment name="Test1WAR.war">

</dependencies>

<local-last value="true"/>

</sub-deployment>

<sub-deployment name="Test2WAR.war">

</dependencies>

<local-last value="true"/>

</sub-deployment>

</jboss-deployment-structure>

Projeto “TestLib”

É um projeto Java simples que conterá uma classe utilitária para obter informações do classloader de outros projetos e também, para obter informações do seu próprio classloader. Na figura a seguir, será mostrado a estrutura do projeto “TestLib”.

Note que no projeto “TestLib”, só temos a classe TesteUtil cujo código será mostrado a seguir:

package utils;

import java.util.Collections;

import java.util.LinkedList;

import java.util.List;

public class TesteUtil {

static {

StringBuilder str = new StringBuilder();

str.append("\nTesteUtil - Carregamento da classe - INICIO\n");

str.append(getInfoClassLoader());

str.append("\nTesteUtil - Carregamento da classe - FIM");

System.out.println(str.toString());

}

public static void main(String... strings) {

System.out.println("Classloader: ");

System.out.println(getInfoClassLoader());

}

public static String getInfoClassLoader(ClassLoader cl) {

Class<?> cls = cl.getClass();

StringBuilder str = new StringBuilder();

// Nome da classe e hashcode do objeto ClassLoader

str.append("\nClasse: " + cls.getName() + " - " + cl.hashCode() + "\n");

return str.toString();

}

public static String getInfoClassLoader() {

ClassLoader cl = TesteUtil.class.getClassLoader();

return getInfoClassLoader(cl);

}

Note que nessa classe “TesteUtil” temos um bloco anônimo estático justamente para que possamos obter informações do classloader do projeto “TestUtil” que será o mesmo do projeto EAR, pois esse projeto Java será mais um “jar” dentro da pasta “EAR/lib” do projeto EAR.

Projetos “Test1EJB” e “Test2EJB”

A estrutura do projeto “Test1EJB” será mostrado na figura a seguir, lembrando que o projeto “Test2EJB” é análogo (semelhante) ao projeto “Test1EJB” com a diferença nos nomes, ao invés de usar “Test1”, usa-se “Test2”, de outra maneira, só trocarmos o número “1” pelo número “2”.

Note que o projeto “Test1EJB” possui uma interface de nome “Teste1” que define um método para obter informações do classloader do projeto EJB. A seguir será mostrado o código dessa interface (arquivo “Teste1.java”).

package ejb;

import javax.ejb.Remote;

@Remote

public interface Teste1 {

public String getInfoClassLoader();

}

E para o EJB “Teste1Bean” que implementa a interface “Teste1” cujo código será mostrado a seguir:

package ejb;

import javax.annotation.PostConstruct;

import javax.ejb.Startup;

import javax.ejb.Stateless;

import utils.TesteUtil;

@Startup

@Stateless

public class Teste1Bean implements Teste1 {

@Override

public String getInfoClassLoader() {

return TesteUtil.getInfoClassLoader(this.getClass().getClassLoader());

}

@PostConstruct

public void printClassloader() {

StringBuilder str = new StringBuilder();

str.append("\nClassloader - PostConstruct1 - INICIO\n");

str.append(getInfoClassLoader());

str.append("Classloader - PostConstruct1 - FIM\n");

System.out.println(str.toString());

}

Projetos “Test1WAR” e “Test2WAR”

Esses são dois projetos web que usaram os projetos EJB's e o projeto Java “TestLib”. A estrutura do projeto “Test1WAR” será mostrado a seguir. Lembrando que o projeto “Test2WAR” é análogo (semelhante) ao projeto “Test1WAR”, portanto, toda configuração do “Test1WAR” vale para o projeto “Test2WAR” com a diferença nos nomes, basta trocar o número “1” por “2”.

Note que nesse projeto web, precisamos criar um ServiceLocator para facilitar a localização de EJB's dos outros projetos e também, criamos um Servlet para poder ser chamado via url no browser e cujo código fará chamadas nos projetos EJB's, Java e no próprio projeto web para obter informações a respeitos do classloaders dos projetos. A seguir será mostrado o código do ServiceLocator e depois, do Servlet “Test1WARServlet”.

package test.web.base;

import javax.naming.InitialContext;

public class ServiceLocator {

private InitialContext jndiContext;

private static ServiceLocator instance;

private static final String PREFIX_GLOBAL = "java:global/";

// private static final String PREFIX_APP = "java:app/";

private String earJndiName = "";

private ServiceLocator() {

try {

jndiContext = new InitialContext();

} catch (Exception e) {

e.printStackTrace();

}

public static ServiceLocator getInstance() {

if (instance == null) {

instance = new ServiceLocator();

}

return instance;

}

public String getEarJndiName() {

return earJndiName;

}

public void setEarJndiName(String earJndiName) {

this.earJndiName = earJndiName;

}

public Object get(final String jndiName) {

Object localHome = null;

try {

localHome = jndiContext.lookup(PREFIX_GLOBAL + earJndiName

+ jndiName);

} catch (Exception e) {

e.printStackTrace();

}

return localHome;

}

package test.web.servlet;

import java.io.IOException;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import test.web.base.ServiceLocator;

import utils.TesteUtil;

import ejb.Teste1;

import ejb.Teste2;

/**

* Servlet implementation class Test1WARServlet

public class Test1WARServlet extends HttpServlet {

private static final long serialVersionUID = 1L;

/**

* @see HttpServlet#HttpServlet()

public Test1WARServlet() {

super();

}

/**

* @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse

* response)

protected void doGet(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException {

StringBuilder str = new StringBuilder();

str.append("\nTest1WARServlet - INICIO\n");

str.append("\nClassloader - Lib\n");

str.append(TesteUtil.getInfoClassLoader());

str.append("\nClassloader - WAR\n");

str.append(TesteUtil.getInfoClassLoader(this.getClass()

.getClassLoader()));

ServiceLocator serviceLocator = ServiceLocator.getInstance();

serviceLocator.setEarJndiName("TestEAR/Test1EJB/");

Teste1 serviceTeste1 = (Teste1) serviceLocator.get("Teste1Bean");

str.append("\nClassloader - Teste1EJB\n");

str.append(serviceTeste1.getInfoClassLoader());

serviceLocator.setEarJndiName("TestEAR/Test2EJB/");

Teste2 serviceTeste2 = (Teste2) serviceLocator.get("Teste2Bean");

str.append("\nClassloader - Teste2EJB\n");

str.append(serviceTeste2.getInfoClassLoader());

str.append("\nTest1WARServlet - FIM");

System.out.println(str.toString());

}

/**

* @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse

* response)

protected void doPost(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException {

}

A seguir, mostraremos o código do arquivo “web.xml”do projeto web. Nesse arquivo definimos o Servlet criado para que possa estar disponível para receber requisições HTTP.

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">

<display-name>Test1WAR</display-name>

<display-name>Test1WARServlet</display-name>

<servlet-name>Test1WARServlet</servlet-name>

<servlet-class>test.web.servlet.Test1WARServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>Test1WARServlet</servlet-name>

<url-pattern>/teste1</url-pattern>

</servlet-mapping>

</web-app>

Com isso, para acessar o servlet, só clicar nesses links:

http://127.0.0.1:8080/Test1WAR/teste1

http://127.0.0.1:8080/Test2WAR/teste2

Lembrando que o IP do servidor é 127.0.0.1 e porta 8080. Caso esteja rodando servidor JBoss AS 7 em outra máquina, usar o IP dessa máquina para acessar o Servlet.

RESULTADOS

Ao executarmos o mesmo projeto EAR com ou sem isolação (tag ear-subdeployments-isolated do arquivo jboss-deployment-structure.xml), o JBoss AS 7 coloca uma instância de classloader (classe org.jboss.modules.ModuleClassLoader) para cada unidade de deploy dentro do EAR. Isto significa que o projeto EJB terá suas classes carregadas por uma instância de classloader, o projeto WAR terá suas classes carregadas por outra instância de classloader, pasta EAR/lib por outra instância e assim por diante para outros projetos EJB / WAR existentes dentro do EAR. Então, para melhor ilustração desse fato, veja na figura a seguir:

Consequentemente, essa tag (ear-subdeployments-isolated) apenas isola o uso das classes carregadas por cada unidade de deploy. Se essa tag estiver configurada como “true” teremos que definir as dependências entre unidades de deploy explicitamente no arquivo “jboss-deployment-structure.xml”, caso contrário, o servidor JBoss AS 7 lançará a exceção java.lang.ClassNotFoundException. Veja na figura a seguir como que as unidades de deploy se relacionam quando essa tag está com valor “true”.

Note que os projetos web “WAR1” e “WAR2” depende (pode acessar) os projetos EJB1, EJB2 e pasta EAR/Lib. Somente esse acesso é possível, se o EJB1 precisar acessar o EJB2, essa configuração precisa ser declarada explicitamente no arquivo “jboss-deployment-structure.xml”.

Se configurar essa tag (ear-subdeployments-isolated) como “false”, todas as unidades de deploy poderão usar as classes carregadas em outras unidades de deploy, sem restrição. Mas nessa configuração teremos que tomar cuidado para uma unidade de deploy não chamar classes de outras unidades de deploy que serão implantadas depois da unidade de deploy atual. Por exemplo se um projeto WAR chama uma classe do projeto EJB sendo que esse último projeto (unidade de deploy) não foi implantado ou será implantado depois do projeto WAR, então poderá ocorrer exceções como java.lang.ClassNotFoundException. Veja na figura a seguir como as unidades de deploy se relacionam quando essa tag possui o valor “false”.

Note que nessa configuração, todas as unidades de deploy (EJB1, EJB2, WAR1, WAR2 e EAR/Lib) podem acessar qualquer unidade de deploy no EAR.

Para evitar esse tipo de problema para o atributo configurado como “false”, deve-se configurar a tag “initialize-in-order” no arquivo application.xml com o valor “true”. Lembre-se que essa tag só está definida na versão 6 do JavaEE. Com essa configuração, forçaremos a implantação das unidades de deploy definidas no arquivo application.xml na ordem descrita nesse arquivo. Se não configurar essa tag com o valor “true”, o servidor JBoss AS 7 carregará as unidades de deploy na ordem que achar conveniente (digo, políticas implementadas dentro do JBoss AS 7, como por exemplo, tamanho dos módulos, tipo, prioridade de implantação entre módulos, etc) e não a ordem no documento xml.

REFERÊNCIAS

http://www.javacodegeeks.com/2012/09/jboss-as-7-classloading-explained.html

http://blog.caelum.com.br/java-6-as-apis-de-xml-webservices-e-classloaders/

http://www.kumpera.net/blog/index.php/2007/05/09/classloader-hell/