Integrando com Adobe Flex via Blazeds

Da mesma forma como foi apresentada no post referente a a integração com JSF (link), é possível integrar o contexto de beans com o Adobe Flex a partir do BlazeDS. Para tal, basta declarar a implementação de flex.messaging.FlexFactory do lindbergframework, que promove a integração, no arquivo servicesconfig.xm como a seguir. A partir daí os beans contidos no contexto estão acessíveis de forma transparente para a camada de visão/front-end Flex. Da mesma forma como foi apresentada a integração do contexto com o JSF, os beans são acessados via seus respectivos ID´s.

<?xml version="1.0" encoding="UTF-8"?>
<services-config>
     <factories>
          <factory id="lindbergFactory" class="org.lindbergframework.integration.web.flex.LindbergFlexBeanFactory" />
     </factories>
</services-config>

Integrando o contexto de Beans do lindbergframework com JSF (Java Server Faces)

A integração do JSF com o contexto de Beans do lindbergframework possibilita o uso de qualquer Bean declarado com annotation @Bean e que faça parte do contexto nas páginas JSF, diretamente via o ID do Bean.

Exemplo: Considere que temos um managedBean chamado ManterPessoaMB cujo ID do mesmo, declarado via annotation @Bean seja manterPessoaMB.

@Bean("manterPessoaMB")
public class ManterPessoaMB {

   public String cadastrar(){
      //... implementação da ação de cadastrar
      return null;
   }

}

ATENÇÃO: Para que o bean acima faça parte do contexto de beans o mesmo deve estar direta ou indiretamente abaixo do pacote base, definido na configuração de CORE.


Para efetuar a integração e possibilitar que usemos o bean manterPessoaMB diretamente em páginas JSF a partir do seu ID, é necessário declarar apenas o ELResolver do lindbergframework, org.lindbergframework.integration.web.jsf.beans.LindbergBeanJsfResolver no faces-config.xml da aplicação como abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0">
     <application>
         <el-resolver>org.lindbergframework.integration.web.jsf.beans.LindbergBeanJsfResolver</el-resolver>
     </application>
</faces-config>

Basta isso para que o contexto de beans do lindbergframework esteja acessível nas páginas JSF.

Abaixo é mostrado um exemplo de um botão que acessa o bean ManterPessoaMB a partir do seu ID definido via annotation @Bean, manterPessoaMB, e chama o action 'cadastrar' declarado no mesmo.

<h:commandButton action="#{manterPessoaMB.cadastrar}" value="Cadastrar" />

Injeção de Dependência e Inversão de Controle com o lindbergframework.

Um conceito importante abordado por muitos frameworks consolidados na comunidade java, como o spring, é o de inversão de controle para o tratamento de injeção de dependências. Esse conceito propõe a transferência de responsabilidade para a criação de beans no projeto fazendo com que o controle sobre a criação, gerenciamento e injeção de dependências destes beans não fique a cargo do programador e seja invertido para um container ou qualquer outro componente que possa tomar controle sobre a execução.

O lindbergframework precisa em muitos casos intervir e customizar a criação de beans para aplicar correta e eficientemente injeção de dependência nos mesmos. Uma outra necessidade de intervenção na criação de beans é para usar diversos tipos de proxies de aspecto para vários fins, como por exemplo no gerenciamento de transações via annotation. Para fazer isso, o lindbergframework aplica um proxy sobre o bean que gerenciará todo o processo de transação de forma transparente. Mas para tal, é necessário que o controle de criação dos beans seja invertido para o LDIC (Lindberg Dependency Injection Container). Toda a parte do gerenciamento de transações do framework será detalhada mais a frente quando a parte de persistência for abordada.

Um framework já consolidado que poderia ter sido adotado é o spring por exemplo, mas isso obrigaria que todo projeto que usasse o lindbergframework também tivesse que usar o spring. Para solucionar o problema um mecanismo de inversão de controle foi criado de forma independente e exclusiva para o lindbergframework. Caso você deseje mesmo assim usar spring em seu projeto o lindbergframework no módulo integration fornece integração com este framework. Isto será demonstrado mais a frente.

NOTA: Observe que ao se usar o lindbergframework, principalmente os recursos de persistência, é necessária a dependência para o Spring. Isso não é necessário para efetuar injeção de dependências. O mecanismo de injeção do lindbergframework é independente e implementa outra solução para o problema. A dependência do Spring é requerida pois o lindbergframework usa recursos do SpringDAO.

Inversão de Controle na Prática

O mecanismo de inversão de controle do lindbergframework é simples e baseia-se inicialmente no pacote base onde o Lindberg Dependency Injection Container (LDIC - Contêiner Lindberg de Injeção de Dependência), responsável por resolver todas as dependências de cada bean, deve procurar os beans. No exemplo anteriormente mostrado o pacote org.lindbergframework.exemplo.* foi definido e isso fará com que o LDIC crie seu contexto de beans visualizando apenas beans que estão dentro do escopo do pacote org.lindbergframework.exemplo ou sub pacotes deste já que o “.*” foi definido. Abaixo vão algumas regras para a definição do pacote base:

1 – O pacote deve ser definido usando o carácter “.”;

2 – Pacotes usando o carácter “/” como por exemplo “org/lindbergframework/xxx” são inválidos;

3 – Para informar que o escopo se restrinja a um pacote único e específico e somente este basta definir o pacote sem “.*”. Por exemplo: br.empresa.beans define que apenas os beans dentro deste pacote serão visualizados. Qualquer bean dentro de um sub pacote deste não será encontrado como por exemplo um bean dentro de br.empresa.beans.exemplo não será visualizado;

4 – Para definir que o escopo é um pacote e incluir no escopo todo e qualquer bean que esteja em algum sub pacote do pacote base, como no exemplo anterior br.empresa.beans como pacote base. Para que um bean dentro de br.empresa.beans.exemplo também sejá visualizado e incluído no contexto o pacote base
deve ser definido usando ”.*” como a seguir:

br.empresa.beans.*

5 – Também é possível definir um pacote base usando seus sub pacotes mas excluindo do contexto alguns sub pacotes que não se deseje que façam parte do contexto de beans. Por exemplo, vamos levar em consideração a seguinte estrutura de pacotes:

br
br.empresa
br.empresa.beans
br.empresa.beans.exemplo
br.empresa.beans.schemas

Se fosse desejável criar um contexto de beans onde o LDIC visualizasse beans dentro do pacote br.empresa.beans e seus sub pacotes mas que o pacote br.empresa.beans.schemas não fizesse parte do contexto. Para tal, é necessário definir o pacote ou pacotes que se deseja excluir do contexto usando o caráter “:”. Para este exemplo a string do pacote básico seria da seguinte forma:

br.empresa.beans:schemas.*

O pacote definido dessa forma diz que o LDIC deve buscar beans no pacote br.empresa.beans e todos os seus sub pacotes menos o sub pacote schemas. Todo e qualquer bean que estiver dentro de br.empresa.beans.schemas os sub pacotes deste não será visualizado pelo LDIC.

Fábrica de Beans (BeanFactory)

A interface BeanFactory é fornecida pelo framework para definir as fábricas de beans que poderão trabalhar em conjunto com o LDIC. Uma classe que implementa essa interface deve fornecer instâncias de beans solicitados de acordo com um ID específico entre outras operações. Cada fábrica implementa a sua forma como cada instância de bean é obtida bem como cada dependência desses beans é resolvida e injetada no bean.

Uma outra interface importante mas que não será abordada mais a fundo neste momento e que trabalha em conjunto com as fábricas de beans é a BeanMapper. Essa interface define um mapeador de beans de modo a fornecer meta dados a uma BeanFactory para a correta criação e resolução de dependências de um bean com base em um ID específico solicitado.

A classe abstrata AbstractBeanFactory que fornece a base para fábricas de beans já contém um atributo BeanMapper de modo a fornecer um mapeador de bean para as fábricas concretas.

Injeção de Dependências

Fornecer um mecanismo para obtenção de instâncias de beans é um recurso importante. Imagine que temos uma classe chamada “A” que possui um dependência para uma classe “B” e esta última por sua vez possui uma dependência para “C”. Se solicitarmos uma instância de “A” é necessário que a instância de “A” venha preenchida com uma instância de “B” e “B” com uma instância de “C” de modo que todas as dependências diretas e indiretas de “A” estejam resolvidas e dessa forma “A” esteja pronto para ser usado.

Isso deve ser feito de forma transparente pelo mecanismo de inversão de controle de modo a fornecer recursos para diminuir o acoplamento entre as classes permitindo, por exemplo, que “A” se refira a “B” e “B” se refira a “C” através de uma interface tornando o código independente da implementação final.

Toda e qualquer interação entre “A”, “B” e “C”, poderia ocorrer através de interfaces onde o desenvolvedor não se preocupe com a implementação que em tempo de execução será utilizada. A instância do bean que contém a implementação a ser usada é responsabilidade do mecanismo de injeção de dependência que deve obter a correta instância e injetá-la onde necessário.


NOTA: Injeção de dependências não está ligado ao uso de interfaces ou não. Mesmo que não se use interfaces nem classes abstratas para prover o baico acoplamento entra as camadas o uso de inversão de controle para injeção de dependências é algo independente e importante.

O lindbergframework provê a interface DependencyManager que define um gerenciador de
dependências que tem como responsabilidade auxiliar uma BeanFactory resolvendo as dependências dos beans solicitados. A implementação padrão desta interface é um gerenciador de dependências baseado nas annotations @Bean e @Inject – AnnotationDependencyManager.

Para exemplificar considere o código abaixo que não usa a injeção automática de dependência:

public interface ISistemaFacade {
    public void cadastrarPessoa(Pessoa pessoa);
}

public class SistemaFacade implements ISistemaFacade{

    private IPessoaBC pessoaBC = new PessoaBC();

    public void cadastrarPessoa(Pessoa pessoa){
        pessoaBC.cadastrar(pessoa);
    }
}

public interface IPessoaBC {
    public void cadastrar(Pessoa pessoa);
}

public class PessoaBC implements IPessoaBC{

    private IPessoaDAO pessoaDAO = new PessoaDAO();

    public void cadastrar(Pessoa pessoa) {
        pessoaDAO.cadastrar(pessoa);
    }
}

public interface IPessoaDAO {
    public void cadastrar(Pessoa pessoa);
}

public class PessoaDAO implements IPessoaDAO{
    public void cadastrar(Pessoa pessoa){
        System.out.println("Pessoa cadastrada: "+pessoa.getNome());
    }
}


Código de teste:
Pessoa pessoa = new Pessoa("joão");
ISistemaFacade sistemaFacade = new SistemaFacade();
sistemaFacade.cadastrarPessoa(pessoa);

Observe que as classes demonstradas acima não usam recurso de inversão de controle para provimento de injeção de dependências e referem-se diretamente as implementações finais das classes ao qual dependem.

Neste caso observe que a fachada do nosso sistema depende de um BusinessController que implementa a interface IPessoaBC e a instância é criada diretamente via operador new no código tornando a fachada do nosso sistema extremamente dependente da implementação PessoaBC da interface IPessoaBC.

Da mesma forma a implementação PessoaBC dependente de uma implementação de IPessoaDAO e como foi feito na fachada a implementação PessoaDAO está diretamente referenciada no código e a instância criada diretamente no código. Neste exemplo os três níveis estão extremamente interdependentes, dificultando qualquer evolução ou manutenção no código pois o código está extremamente amarrado a implementações e não a interfaces mesmo que estejamos usando interfaces pois a implementação final é referida diretamente no código.

Qual o problema nisto? Um exemplo simples seria: Atualmente a maioria das aplicações trabalham com testes (JUnit ou algo similar). Uma pratica comum na implementação de testes é a criação de Mocks e Fakes. Que a grosso modo são objetos que simulam o real comportamento de objetos provendo para tal o comportamento desejado/esperado para um determinado teste. É comum o uso desse tipo de objetos para a criação de testes desconectados do banco. De modo que um mock seria uma implementação, por exemplo, de um DAO real só que simulando as reais operações de persistência bem como o comportamento desejado para um ou mais testes. Dito isto, no exemplo acima não seria possível normalmente (seria caso usássemos Aspecto) fornecer um Mock de IPessoaDAO para fins de testes pois o BC PessoaBC acessa diretamente a implementação real de IPessoaDAO (new PessoaDAO) e isso impossibilita a mudança da implementação do DAO a ser usada pois o BC está diretamente acoplado a implementação do DAO. Se o BC se referisse ao DAO apenas via interface e ao invés de obter a instância da implementação diretamente via operador new usasse um mecanismo de inversão de controle para injetar a implementação de IPessoaDAO desejada, poderíamos para os testes usar a implementação Mock e para aplicação real a implementação real.

Um mecanismo de inversão de controle faz todo esse trabalho deixando o desenvolvedor livre para tratar do que realmente interessa de modo que a criação e injeção dessas dependências são responsabilidades desse mecanismo, que no lindbergframework é chamado de LDIC (Lindberg Dependency Injection Container).

O lindbergframework fornece uma implementação padrão de BeanFacotry que é a classe
AnnotationBeanFactory. Essa fábrica de beans trabalha com as annotations @Bean e @Inject que são utilizadas para a definição de beans e suas dependências. Essa BeanFactory é a padrão e caso uma não seja definida o framework utilizará esta como padrão.

- @Bean: Annotation utilizada para a definir um bean. Os únicos parâmetros que ela tem é o value e singleton. O value é uma String que define o ID do bean. Esse ID deve ser único no contexto e esse ID é o que será usado para referenciar o bean. O ID é requerido nesta annotation. O parâmetro singleton é um boolean que recebe “true” quando o bean deve ser um singleton, ou seja ter apenas uma instância dentro do contexto retornando sempre a mesma instância deste e “false” caso contrário.

- @Inject: Annotation que define um ponto de injeção de dependência em um bean. O único parâmetro que esta annotation contém é o value que é o ID do bean que deve ser injetado no atributo de classe onde esta annotation foi declarada.

Abaixo é mostrado o mesmo exemplo só que fazendo uso dos recursos de inversão de controle do lindbergframework. No exemplo a seguir considere que no ponto de obtenção da instância do bean o Core do framework já foi configurado como mostrado nas sessões anteriores. Como só as implementações foram alteradas as interfaces são omitidas neste exemplo:

import org.lindbergframework.beans.di.annotation.Bean;
import org.lindbergframework.beans.di.annotation.Inject;
@Bean("sistemaFacade")
public class SistemaFacade implements ISistemaFacade{
    @Inject("pessoaBC")
    private IPessoaBC pessoaBC;

    public void cadastrarPessoa(Pessoa pessoa){
        pessoaBC.cadastrar(pessoa);
        }
}



import org.lindbergframework.beans.di.annotation.Bean;
import org.lindbergframework.beans.di.annotation.Inject;
@Bean("pessoaBC")
public class PessoaBC implements IPessoaBC{

    @Inject("pessoaDAO")
    private IPessoaDAO pessoaDAO;

    public void cadastrar(Pessoa pessoa) {
        pessoaDAO.cadastrar(pessoa);
    }
}


import org.lindbergframework.beans.di.annotation.Bean;
@Bean("pessoaDAO")
public class PessoaDAO implements IPessoaDAO{

    public void cadastrar(Pessoa pessoa){
        System.out.println("Pessoa cadastrada: "+pessoa.getNome());
    }
}

Código de teste:
Pessoa pessoa = new Pessoa("joão");
ISistemaFacade sistemaFacade = UserBeanContext.getInstance().getBean("sistemaFacade");
sistemaFacade.cadastrarPessoa(pessoa);


Observe que neste segundo exemplo as classes não referenciam como dependência nenhum implementação específica. SistemaFacade referencia apenas a interface IPessoaBC e não é afetada quanto a implementação que será usada. Da mesma forma PessoaBC referencia apenas a interface IPessoaDAO e seu funcionamento não depende e nem está acoplado a nenhuma implementação desta.

Neste último exemplo a classe SistemaFacade é anotada com a annotation @Bean onde o ID deste bean é definido como sistemaFacade. Este bean possui uma dependência com um IPessoaBC e para definir e instruir ao LDIC que faça a injeção da implementação que deve ser usada, este atributo foi anotado com a annotation @Inject definindo como parâmetro o ID do bean que deve ser injetado neste ponto. Observe que não há necessidade de definição de um setter para pessoaBC.

Da mesma forma a nossa implementação de IPessoaBC a classe PessoaBC é anotada da mesma forma, uma annotation @Bean definindo o ID desta e como temos apenas uma dependência, apenas uma annotation @Inject foi usada, neste caso para a dependência para IPessoaDAO.

Obtendo beans a partir do Contexto

Com as classes devidamente anotadas precisamos obter uma instância de nossa fachada e utilizá-la. É aí que entram as configurações feitas no core e a nossa bean factory. No trecho abaixo obtemos do CoreContext a instância da BeanFacotry e a partir desta fábrica obtemos a instância do bean da fachada do sistema e para isso passamos o ID do bean da fachada que neste caso é “sistemaFacade” para o método getBean da BeanFactory. A instância do bean da fachada retornada por este método já virá pronta com suas dependências injetadas e prontas para uso.

Para este caso a instância de sistemaFacade já virá preenchida com a instância correta de pessoaBC e este por sua vez já estará preenchido com a instância correta de pessoaDAO tudo de forma automática e transparente feita pelo LDIC.

ISistemaFacade sistemaFacade = CoreContext.getInstance().getBeanFactory().getBean("sistemaFacade");

Uma outra forma e até mais simples e direta de se obter um bean a partir do contexto usando o mecanismo de inversão e controle, é a partir da classe UserBeanContext.

Essa classe é um singleton e é um atalho para acesso da fábrica de beans padrão definida. O mesmo trecho de código apresentando anteriormente para obtenção de uma instância como exemplo de IsistemaFacade usando CoreContext poderia ser feita usando UserBeanContext da seguinte forma:

ISistemaFacade sistemaFacade = UserBeanContext.getInstance().getBean("sistemaFacade");

Observe que no trecho acima apenas a interface é referenciada. Fica a cargo do LDIC retornar a instância da implementação que deve ser usada correspondente ao ID passado.

O LDIC também efetua a injeção em dependências definidas em superclasse de modo que se PessoaBC estendesse de uma classe qualquer e esta última tivesse dependências definidas via @Inject estas dependências herdadas, mesmo private, seriam resolvidas e injetadas.

Caso o ID passado para o método getBean não corresponda a um bean válido dentro do contexto da bean factory, uma BeanNotFoundException é lançada informando que um bean com o ID especificado não foi encontrado.

O lindbergframework, já se integra com JSF e Adobe Flex e usando o framework integrado com qualquer um destes últimos não é necessário o uso de UserBeanContext.getInstance().getBean() pois no caso do JSF o managedBean já é criado e suas dependências resolvidas automáticamente pelo LDIC e no caso do Flex o bean invocado para execução de um serviço ou método remoto é resolvido pelo LDIC.

Beans com escopo Singleton

O framework também provê a possibilidade de definir um bean de modo que este seja um singleton. Isto é, tenha apenas uma instância dentro do contexto. Quando um bean é definido com o escopo singleton o LDIC manterá sempre a mesma instância e sempre que o bean for solicitado ao LDIC esta mesma instância será retornada.

Se fosse desejável, por exemplo, definir que o bean SistemaFacade deve ter uma única instância dentro do contexto, então especificaríamos seu escopo como singleton na própria annotation @Bean. Abaixo é mostrado como ficaria a classe SistemaFacade de modo a operar como um singleton.


@Bean(value = "sistemaFacade",singleton = true)
public class SistemaFacade implements IsistemaFacade{}


Observe que a annotation @Bean foi alterada adicionando o atributo singleton definindo o valor deste como true indicando que o bean SistemaFacade deve ser trabalhar como um singleton dentro do contexto. O LDIC agora retornará sempre a mesma instância de SistemaFacade quando este bean for solicitado.

Configurando o framework em aplicações WEB

Até agora para configurar o framework, através de seu módulo principal, o CORE, seja
programaticamente, via XML, ou qualquer outra implementação seja em nosso código seja a partir de um método main, seja a partir de uma classe que recebe essa responsabilidade ou qualquer outra estrutura temos que chamar sempre CoreContext.getInstance().initialize(coreConfiguration); ou coreConfiguration.initializeContext(); para configurar e inicializar o framework.

Em uma aplicação WEB é comum que um framework forneça recursos para que a configuração seja feita de forma automática, sem precisar de nada programaticamente.
Este recurso também é provido pelo lindbergframework através de um ServletContextListener e da definição de alguns no Deployment Descriptor (web.xml) da aplicação. A partir daí quando o servidor for inicializado e a aplicação publicada o lindbergframework será automaticamente configurado baseado nas configurações passadas.

Essa configuração é muito simples. Baseia-se em declarar no web.xml da aplicação o ServletContextListener provido pelo lindbergframework e definir os parâmetros (<context-param>) informando onde está o arquivo de configuração do framework e qual a implementação do parser de configuração a ser usado, se será Xml, Properties, Txt, seja lá qual for, sendo que para este último é esperado uma implementação de WebCoreConfiguration.

Tanto o local onde se encontra o arquivo de configuração quando a implementação de WebCoreConfiguration a ser usada não são requeridos pois ambos possuem valores padrão. O path do arquivo de configuração caso não seja definido tem como padrão o valor lindberg-config.xml na raiz do classpath do projeto. E a implementação de WebCoreConfiguration, caso não seja declarada, é usada como padrão:

org.lindbergframework.web.core.configuration.WebClassPathXmlCoreConfiguration.

Abaixo é descrito um exemplo do que precisaria ser adicionado ao nosso web.xml se fossemos usar o mesmo arquivo de configuração que usamos nos exemplos anteriores só que agora em um projeto WEB para configurar o framework de forma automática:

<context-param><!--(ISTO É OPCIONAL. O caminho padrão para o arquivo de configuração é 'lindbergconfig.xml' localizado na raiz do classpath)-->
    <param-name>lindbergConfigLocation</param-name>
    <param-value>org/lindbergframework/configuracao/lindberg-config.xml</param-value>
</context-param>
<context-param> <!--(ISTO É OPCIONAL)-->
    <param-name>lindbergConfigClass</param-name>
    <param-alue>org.lindbergframework.core.context.WebClassPathXmlCoreConfiguration</param-value>
</context-param>
<listener>
    <listener-class>org.lindbergframework.web.LindbergContextLoaderListener</listener-class>
</listener>


No exemplo acima observe que adicionamos o listener LindbergContextLoaderListerner, que é o ServletContextListener provido pelo lindbergframework e que sabe como configurar de forma automatizada o framework. Adicionamos o parâmetro lindbergConfigLocation que é onde está o arquivo de configuração.

Esta propriedade é opcional e caso não seja declarada, o framework usa o nome e local padrão para o arquivo de configuração, que é 'lindberg-config.xml' na raiz do classpath. Importante dizer que o arquivo não obrigatoriamente tem que ser um XML, isto depende da implementação de WebCoreConfiguration que estiver usando. Se, por exemplo, ocorresse a necessidade de usar uma implementação para configurações definidas em um arquivo .properties então este parâmetro apontaria para um arquivo properties, da mesma forma se eu criar minha própria implementação de WebCoreConfiguration que trabalha com um arquivo TXT segundo uma formatação que eu criei então esse parâmetro vai apontar para um arquivo TXT que segue o padrão de formatação definido. Para que haja essa flexibilidade, é que é possível definir a implementação de WebCoreConfiguration que deve ser usada através do parâmetro lindbergConfigClass.

Passos para configuração no web.xml:
• Declarar o listener: org.lindbergframework.web.LindbergContextLoaderListener
• Declarar os Parâmetros via :
-- ◦ lindbergConfigLocation: Local onde está o arquivo de configuração caso o -- arquivo de configuração não siga o padrão é 'lindberg-config.xml' na raiz do
-- classpath.

-- ◦ lindbergConfigClass: Implementação de CoreConfiguration que efetuará o parser -- da configuração. Quando não definido este parâmetro a implementação padrão,
-- WebClassPathXmlCoreConfiguration, é usada.

A partir daí é só iniciar o servidor que o a configuração será efetuada automaticamente e você verá no console as mensagens de log informando o processo de inicialização do contexto WEB do framework.

ATENÇÃO: Para alguns servidores é necessário adicionar a lib do xmlbeans direto nas libs do servidor de modo a sobrescrever a lib padrão provida pelo mesmo. Isso se faz necessário quando ao subir o servidor se obtenha uma mensagem de erro como a descrita abaixo indicando conflito de carregamento de classes do xmlbeans.

”...Loader constraint violation in interface itable initialization: when resolving method
"org.apache.xmlbeans.impl.store.Xobj$NodeXobj.setUserData(Ljava/lang/String;Ljava/lang/Object;Lorg/w3c/dom/UserDataHa
ndler;)Ljava/lang/Object;" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the
current class, org/apache/xmlbeans/impl/store/Xobj$NodeXobj, and the class loader (instance of ) for
interface org/w3c/dom/Node have different Class objects for the type org/w3c/dom/UserDataHandler used in the
signature”

A Classe CoreContext

A classe CoreContrext é um singleton e provê acesso a toda configuração do módulo CORE do framework. Para obter a instância singleton do contexto de configuração de core basta chamar

CoreContext.getInstane()

As configurações definidas para o core como o pacote base para o contexto de
injeção de dependências, a implementação da BeanFactory, módulos dependêntes, e qualquer outra configuração de CORE pode ser acessada via CoreContext.

Veja a documentação da classe CoreContext aqui.

Inicializando CoreContext usando configuração XML

Para este post é necessário que você leia antes este outro post: LINK

Abaixo é mostrado o mesmo processo de configuração do CORE demonstrado no post citado acima, só que usando o XML.

<config-property name="exemplo" value="com.aplicacao.Exemplo">
       <property value="valor da propriedade1" constructor-arg="true" />
       <property constructor-arg="true">
            <list>
                exemplo list string 1;
                exemplo list string 2;
                exemplo list string 3;
                exemplo list string N;
            </list>
       </property>
       <property name="propriedade3">
            <array>
                exemplo list string 1;
                exemplo list string 2;
                exemplo list string 3;
                exemplo list string N;
            </array>
       </property>
</config-property>

Para este exemplo vamos considerar que o XML acima esteja no pacote org.lindbergframework.configuracao e que o nome do XML é o padrão, lindberg-config.xml, seguindo o mesmo nome do schema.


XmlCoreConfiguration coreConfiguration = new ClassPathXmlCoreConfiguration("org/lindbergframework/configuracao/lindberg-config.xml");
coreConfiguration.initializeContext();


Observe que agora inicializamos o contexto de forma diferente do exemplo anterior.

Os dois exemplos, tanto o deste post quanto o do post citado resultarão na seguinte saída no console informando o status da inicialização da configuração do framework:

INFO: Initializing Lindberg Core Context
INFO: Lindberg Core Context initialized

Neste exemplo observe que foi utilizada a classe ClassPathXmlCoreConfiguration para criar a configuração. Essa classe é uma extensão natural de XmlCoreConfiguration para trabalhar com um arquivo de configuração que está dentro do classpath do projeto. Os dois exemplos mostrados ao final configuram o framework respectivamente a partir de:


- CoreContext.getInstance().initialize(coreConfiguration);
- coreConfiguration.initializeContext();

A partir daí o core do framework está configurado e podemos por exemplo obter uma instância de um bean a partir da fábrica. Supondo que no pacote org.lindbergframework.exemplo.beans tenha um bean cujo ID seja “pessoaDAO” então podemos obter uma instância desse bean chamando a BeanFactory como demonstrado a seguir, isso só pode ser feito após claro a devida configuração do CORE.

IPessoaDAO pessoaDAO = CoreContext.getInstance().getBeanFactory().getBean("pessoaDAO");

Uma outra forma de fazer a mesma coisa e obter o mesmo bean seria:

IPessoaDAO pessoaDAO = UserBeanContext.getInstance().getBean("pessoaDAO");

Todo o funcionamento do mecanismo de injeção de dependência será detalhado mais a frente. Aqui foi demonstrado apenas como exemplo do uso da configuração na prática.

– Uso do carácter '#' no XML para definir propriedades e métodos getters estáticos

Imagine que você quer por algum motivo que o framework chame um método 'get' seu para obter a instância da implementação de BeanFactory a ser usada, imagine que você queira isso pois por algum motivo você precise fazer algum processamento nesse método 'get' para efetuar alguma customização, registro de log, enfim. Ou imagine ainda que por algum motivo você quer que a String com pacote base (onde o framework encontrará os beans que farão parte do contexto de 'inversão de controle' de modo que a criação, injeção de dependência desses seja responsabilidade do framework) esteja em numa constante em uma de suas classes de modo que você possa usá-la em outros lugares no seu projeto centralizando esse atributo na forma de uma constante.

Para estes casos o framework provê o recurso de usar o carácter coringa '#'. O uso desse carácter antes da definição de um valor de uma propriedade no arquivo XML de configuração informa que o valor real daquela propriedade será obtido através da chamada ao método 'get' estático e público ou da constante também estática e pública definidos na String ao qual o carácter '#' é fixado.

Isso só é possível para propriedades e métodos que são estáticos e públicos e nos casos do método que seja um método seguindo o padrão de nomenclatura de métodos getter, não sendo para este último caso necessário preceder o nome do método no XML com 'get' pois o framework já busca o método adequado baseado no padrão de nomenclatura.

Por exemplo, se quiséssemos que as duas propriedades mostradas anteriormente para o CORE fossem obtidas agora da seguinte forma:

- di-basepackage: A partir de uma constante estática e pública chamada BASEPACKAGE na classe com.soft.MyConstants;

- BeanFactory: A partir de um método getter público e estático chamado getMyBeanFactory na classe com.soft.MyFactoryConfiguration.

Então a nova configuração seria:

<core>
       <config-property name="lindberg.core.di-basepackage"
               value="#com.soft.MyConstants.BASEPACKAGE"/>
       <config-property name="lindberg.core.beanfactory"                value="#com.soft.MyFactoryConfiguration.myBeanFactory"/>
</core>

Observe que agora os valores das propriedades estão precedidos do carácter '#'. Observe que o valor da propriedade beanFactory, que aponta para um método 'get', não contém o prefixo 'get' ou seja o nome completo do método 'getMyBeanFactory' e sim apenas 'myBeanFactory'. Isso pode ser feito pois o framework por padrão vai buscar o método 'get', seguindo os padões de nomenclatura, fazendo 'get' + 'MyBeanFactory' e invoca o método 'getMyBeanFactory'. Da mesma forma caso deseje informar diretamente o nome do método o framework percebe e o invoca da mesma forma. Seguindo este pensamento a definição da propriedade beanFactory poderia ser feita sem nenhuma mudança no processamento da seguinte forma:

<config-property name="lindberg.core.beanfactory"value="#com.soft.MyFactoryConfiguration.getMyBeanFactory"/>

Agora informamos diretamente o nome completo do método getMyBeanFactory. O framework vai detectar que isso foi feito e não fará nenhuma conversão de nomenclatura, invocando diretamente o método informando.

NOTA: Apenas métodos e propriedades públicos e estáticos podem ser usados com '#'.

Configuração do CORE do lindbergframework

Como foi dito no post sobre a arquitetura, que pode ser visto nesse Link , o framework é composto de módulos. Neste post vamos abordar como configurar o módulo core, suas flexibilidades, alternativas e pontos de extensão.

O módulo CORE na atual versão é responsável por prover toda a estrutura de contextos no que diz respeito a beans como inversão de controle para provimento de injeção de depêndencia e é ele quem define toda a arquitetura e contratos que os outros módulos devem seguir.

Na versão atual, 1.0, o framework só prover a configuração do pacote base para scaneamento de beans candidatos a injeção de dependência e que farão parte do contexto de beans de usuário e que podem ser obtidos a partir do singleton UserBeanContext.

- Configurando o CORE

A configuração do módulo CORE é composta por informações como pacote base para resolver beans para injeção de dependência, fábrica de beans, módulos dependêntes que se deseja utilizar. As configurações de CORE são mais simples, pois dizem respeito apenas as configurações gerais que são definidas para o núcleo do framework.

As duas propriedades que podem ser configuradas no CORE são:

- lindberg.core.di-basepackage (propriedade requerida):
Pacote base de beans para injeção.
Constante que define essa propriedade: CoreConfiguration.CONFIG_PROPERTY_DI_BASEPACKAGE;

- lindberg.core.beanfactory (se não for definida a fábrica padrão será usada - AnnotationBeanFactory):
Fábrica de beans a ser usada.
Constante que define essa propriedade: CoreConfiguration.CONFIG_PROPERTY_BEAN_FACTORY

Vamos definir uma configuração de CORE para os seguintes valores usando as duas implementações de CoreConfiguration na prática:

- Pacote base de beans para injeção (lindberg.core.di-basepackage) = org.lindbergframework.exemplo.*

- Bean factory (lindberg.core.beanfactory) = org.lindbergframework.beans.di.context.AnnotationBeanFactory


Estas duas propriedades são suficientes para configurarmos o core para usarmos apenas o mecanismo de injeção de dependência. Neste caso os beans para injeção serão procurados dentro do pacote org.lindbergframework.exemplo e o ponto asterisco “.*” define que o framework também procurará beans para injeção de dependência dentro dos sub-pacotes de org.lindbergframework.exemplo e sub-pacotes destes e assim em diante.

O lindbergframework define uma interface chamada BeanFactory que define uma fábrica de beans que pode ser usada para obtenção de instâncias de beans dentro do contexto de injeção de dependência corrente. Neste caso foi definida a implementação de uma fábrica de beans que trabalha em conjunto com annotations. Mais a frente serão abordados os detalhes dessa interface BeanFactory e de todo o mecanismo de injeção de dependência.

– Configurando o CORE na Prática - Programaticamente
Abaixo é mostrado um exemplo da implementação e uso dessas configurações programaticamente direto com código java usando a implementação SimpleCoreConfiguration:

SimpleCoreConfiguration coreConfiguration = new SimpleCoreConfiguration();
coreConfiguration.setDiBasePackage("org.lindbergframework.exemplo.*");
coreConfiguration.setBeanFactory(new AnnotationBeanFactory());
CoreContext.getInstance().initialize(coreConfiguration);


OBSERVAÇÃO: O trecho de código
CoreContext.getInstance().initialize(...)
poderia ser substituido por
coreConfiguration.initializeContext();
- Esse método em CoreConfiguration faz com que o contexto de CORE
com esta configuração seja inicializado.


O trecho acima cria uma instância de SimpleCoreConfiguration, seta as propriedades pacote base onde encontrar os beans que poderão ser usados dentro do contexto de DI (dependecy injection ou injeção de dependência) e a instância da fábrica de beans a ser usada pelo mecanismo de DI. Definidas as propriedades de configuração então o último passo é configurar o módulo core baseado nestas configurações. Para fazer isso é obtida a instância singleton de CoreContext via CoreContext.getInstance() e o método initialize passando a configuração criada é invocado. Pronto, o módulo CORE já está pronto para ser usado e em qualquer lugar você pode invocar CoreContext.getInstance().getBeanFactory() para obter a instância configurada da fábrica definida e chamar o método getBean da fábrica para obter uma
instância de um bean desejado passando o “ID“ deste. Um outro modo de se obter uma instância de um bean através da mesma fábrica é usar a classe UserBeanContext via
UserBeanContext.getInstance().getBean(id). O mecanismo de injeção de dependência será detalhado mais a frente, aqui está apenas sendo demonstrado os conceitos de configuração.

– Configurando o CORE na prática – Usando XML

A seguir é demonstrado a mesma configuração só que usando uma implementação de CoreConfiguration para configuração baseada em XML. O schema que define as configurações baseadas em XML é detalhado a seguir.

Schema: http://www.lindbergframework.org/schema/lindberg-config.xsd

O schema no que diz respeito a tag <core> para definições de configurações de CORE é ilustrado de forma detalhada na imagem abaixo:



Abaixo é mostrado um simples arquivo de configuração de core que define as mesmas configurações do exemplo anterior.

<?xml version="1.0" encoding="UTF-8"?>
<lindberg-configuration
          xmlns="http://www.lindbergframework.org/schema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.lindbergframework.org/schema/lindberg-config.xsd">

<core>
       <config-property name="lindberg.core.di-basepackage"
              value="org.lindbergframework.exemplo.*"/>
       <config-property name="lindberg.core.beanfactory"
             value="org.lindbergframework.beans.di.context.AnnotationBeanFactory"/>
</core>

</lindberg-configuration>

NOTA: A beanfactory está sendo definida mas lembre que esta propriedade não é requerida e quando não informada a factory padrão, AnnotationBeanFactory, é usada automaticamente pelo framework.

– A tag <config-property>

A tag <config-property> é a mais importante de todo o documento XML de configuração. Ela é
usada para a definição de propriedades de configuração. Estas propriedades definem todo o comportamento dos componentes fornecidos pelo framework como o pacote base para buscar beans de injeção automática, gerenciador de transações, resolvedor de comandos sql, schema de banco padrão que deve ser usado, entre outros. Estes últimos são abordados mais a frente, quando o componente de persistência (LINP) for apresentado.

Esta é uma tag basicamente de nome e valor, onde o atributo nome define a chave da propriedade de configuração e o atributo valor define o valor que será usado na configuração para esta propriedade.

Esta tag fornece a flexibilidade de definição de propriedades que serão setadas na objeto valor desta propriedade no momento da inicialização e propriedades que serão usadas como parâmetro para um construtor específico.

Supondo que nós tivéssemos uma propriedade de configuração de CORE cujo a chave é exemplo e o valor para esta chave fosse a classe com.aplicacao.Exemplo e esta classe tivesse uma propriedade String chamada propriedade1, então a definição dessa propriedade seria:

* Definindo a inicialização simples de propriedades dentro de uma propriedade de configuração


<config-property name="exemplo" value="com.aplicacao.Exemplo">
          <property name="propriedade1" value="valor da propriedade1" />
</config-property>


Observe que foi usada uma nova tag dentro da tag <config-property>. Ela serve para definir
propriedades de inicialização e parâmetros de construtor de propriedades de configuração.

A tag <property> pode ser usada um número ilimitado de vezes dentro da tag <config-property> de acordo com a necessidade. Neste caso a utilizamos uma única vez, para definir o set da String 'valor da propriedade1' na propriedade de nome propriedade1 na instância do objeto do tipo com.aplicacao.Exemplo para a chave de configuração Exemplo. A propriedade propriedade1 será setada no momento da criação do objeto com.aplicacao.Exemplo. Se tivéssemos uma propriedade2, bastaria declarar uma outra tag <property> dentro de <config-property> da mesma forma que a propriedade1.

* Definindo a inicialização de propriedades do tipo List ou Array dentro de uma propriedade de configuração

Suponha agora que tivéssemos então as propriedade2 e propriedade3 e estas fossem respectivamente uma List e um Array e ambas de String. Esta tag fornece a flexibilidade de inicialização de listas e arrays de Strings diretamente pelo XML de configuração. Abaixo é mostrado como ficaria a tag <config-property> com a inicialização destas duas propriedades.

<config-property name="exemplo" value="com.aplicacao.Exemplo">
       <property name="propriedade1" value="valor da propriedade1" />
       <property name="propriedade2">
            <list>
                exemplo list string 1;
                exemplo list string 2;
                exemplo list string 3;
                exemplo list string N;
            </list>
       </property>
       <property name="propriedade3">
            <array>
                exemplo array string 1;
                exemplo array string 2;
                exemplo array string 3;
                exemplo array string N;
            </array>
       </property>
</config-property>

No trecho acima agora definimos duas novas propriedades propriedade2 e propriedade3. A primeira é uma List e a segunda um Array. Observe que agora temos duas novas tags para serem usadas dentro da tag <property>, as tags <list> e <array>. A primeira define uma lista e a segunda um array, ambos de Strings. Os valores de cada uma dessas tags são definidos com o conteúdo entre a tag de abertura e fechamento onde cada elemento da List ou Array é separado por um carácter ';'. Dentro da tag <property> se tem a flexibilidade de usar qualquer um dos dois tipos sendo que nunca os dois ao mesmo tempo dentro da mesma <property>.

* Inicialização de propriedades de configuração usando um construtor específico

Agora suponhamos que a nossa classe Exemplo tenha um construtor que recebe uma String e uma
coleção de Strings e queiramos usar este construtor para a criação do objeto Exemplo transformando a nossa definição da propriedade1 e propriedade2 em parâmetros para o construtor. Suponha também que ainda assim queiramos setar a propriedade propriedade3 da mesma forma que o exemplo anterior.

A nossa nova definição da tag <config-property> ficaria da seguinte forma:

<config-property name="exemplo" value="com.aplicacao.Exemplo">
       <property value="valor da propriedade1" constructor-arg="true" />
       <property constructor-arg="true">
            <list>
                exemplo list string 1;
                exemplo list string 2;
                exemplo list string 3;
                exemplo list string N;
            </list>
       </property>
       <property name="propriedade3">
            <array>
                exemplo list string 1;
                exemplo list string 2;
                exemplo list string 3;
                exemplo list string N;
            </array>
       </property>
</config-property>

Observe que o que mudou neste exemplo foi que a tag que definiam as propriedades propriedade1 e propriedade2 agora não tem mais definidos seus atributos nome, pois agora são parâmetros de construtor e agora ao invés disto estas tags tem a propriedade constructor-arg definido para 'true', indicando que estes serão atributos de construtor. Então o construtor que o framework buscaria para criar a instancia de Exemplo seria:

public Exemplo(String,List<String>)

Após a chamada a este construtor e a criação da instancia, a propriedade propriedade3 seria setada com o Array de String definido chamando o método setPropriedade3.

VEJA TAMBÉM COMO CONFIGURAR O CORE USANDO XML NO POST: LINK