Arquivos de sites

JPA/Hibernate Static Metamodel Attributes não populados / nulos — Gerando NullPointerException

E ai galera, beleza?

Hoje tive um problema tentando utilizar os atributos metamodel estáticos do JPA/Hibernate,
sempre quando eu ia utilizá-los, eles estavam nulos… depois de um tempo quebrando a cabeça consegui achar o motivo!

Vamos exemplificar o cenário:

Entidade:

package com.mydomain.model.user;

public class User {

/** Número de identificação */
@Id
private Long id;

/** Nome de autenticação */
private String username;

//getters e setters
}

Metamodel:

package com.mydomain.metamodels;

import javax.persistence.metamodel.SingularAttribute;
import javax.persistence.metamodel.StaticMetamodel;

@StaticMetamodel(User.class)
public class User_ {
public static volatile SingularAttribute<User, String> username;
}

Uso do metamodel no predicado (predicate):


cb.equal(root.get(User_.username), “usuario_teste”);

Toda vez que eu tentava dar get(…) eu estava tomando nullpointerexception,
e a solução que encontrei foi colocar a classe User.class e a User_.class no mesmo pacote…
não sei o real motivo para precisarem estar, porém só assim funcionou pra mim..

Pesquisando descobri também que em futuros releases talvez essas classes possam ficar em pacotes diferentes,
segue algumas regras descritas na especificação do JPA 2:

  • Classes Metamodel devem estar no mesmo pacote das classes de entidade que elas descrevem;
  • Elas devem ter o mesmo nome das classes de entidade que elas descrevem, seguido por um traço-baixo (“_”, underline, underscore…).
    Exemplo: Produto.class é a classe de entidade e o Produto_.class é a classe metamodel.
  • Se uma entidade herdar de outra entidade ou de uma superclasse mapeada (mapped superclass) deve herdar da classe metamodel que descreve sua superclasse.
    Exemplo: Se ProdutoEspecial.class estende Product.class, que estende ObjetoPersistente.class, então ProdutoEspecial_.class deve estender Produto_.class, que deve estender ObjetoPersistente_.class.

É isso ai pessoal espero ter ajudado!
valeu!!!

Fonte: stackoverflow.com – debbie/Vítor E. Silva Souza

Anúncios

Parte 5 – Tutorial de Interceptadores (Interceptors) do Struts2 com Exemplo

Sejam vem vindos a parte 5 de uma série de 7 partes aonde nós vamos examinar aspectos diferentes do framework Struts2. No artigo anterior nós vimos como integrar o framework Tile com o Struts2.

Hoje vamos explorer o mundo dos Interceptadores(Interceptors) no Struts2. Nós vamos ver o que os interceptadores são e como configura-los em uma aplicação web baseada em Struts2.

Interceptadores do Struts 2: Fundamentos

O Struts2 fornece um mecanismo poderoso para controlar uma requisição usando Interceptadores. Interceptadores são responsáveis pela maior parte do processamento de requisições. Eles são invocados pelo controller (controlador) antes e depois de invocar uma action, assim eles ficam entre o controller e a action. Interceptadores executam tarefas como Logging, Validation, File Upload, Double-submit guard e etc.
struts2 request processing lifecycle
O ciclo de vida de processamento do framework Struts2 é bastante discutido na parte 1 do tutorial.

  1. A requisição é gerada pelo usuário e enviada ao Servlet container.
  2. Servlet container invoca o filtro FilterDispatcher que por sua vez determina a ação apropriada.
  3. Um por um dos Intercetors são aplicados ante de chamar a Action. Interceptors executam tarefas como Logging, Validation, File Upload, Double-submit guard e etc.
  4. Action é executada e o Result é gerado pela Action.
  5. A saída da Action é renderizada na view (JSP, Velocity, etc) e o resultado é retornado ao usuário.

Portanto os interceptadores do Struts2 removem funções cross cutting como logging de componentes action e cria uma separação mais limpa do MVC.

O Struts2 vem com uma lista padrão de interceptadores já configurada na aplicação, no arquivo struts-default.xml. Nós podemos criar nossas próprios interceptadores e pluga-los dentro de uma aplicação web baseada em Struts2.

O framework cria um objeto de ActionInvocation que encapsula a action e todos os interceptadores configurados para aquela action. Cada interceptador é chamado antes da action ser chamada. Uma vez que a action é chamada e o resultado é gerado, cada interceptador é chamado de novo na ordem contrária para executar o trabalho de pós-processamento. Interceptadores podem alterar o workflow (fluxo de trabalho) da action. Isso talvez impessa a execução da action.

Nossa Meta

Nossa meta sera criar um interceptador customer MyLoggingInterceptor, o qual irá logar a requisição antes de qualquer action ser chamada. Ele também irá imprimir o nome da classe Action e o tempo de execução em milisegundos.

Criando o Interceptador de Log

Crie uma classe java MyLoggingInterceptor no pacote net.viralpatel.struts2.interceptors e copie o seguinte conteúdo dentro dela.
struts2-logging-interceptors

package net.viralpatel.struts2.interceptor;import com.opensymphony.xwork2.ActionInvocation;

import com.opensymphony.xwork2.interceptor.Interceptor;

public class MyLoggingInterceptor implements Interceptor{

    private static final long serialVersionUID = 1L;

    public String intercept(ActionInvocation invocation) throws Exception {

        String className = invocation.getAction().getClass().getName();

        long startTime = System.currentTimeMillis();

        System.out.println("Before calling action: " + className);

        String result = invocation.invoke();

        long endTime = System.currentTimeMillis();

        System.out.println("After calling action: " + className

                + " Time taken: " + (endTime - startTime) + " ms");

        return result;

    }

    public void destroy() {

        System.out.println("Destroying MyLoggingInterceptor...");

    }

    public void init() {

        System.out.println("Initializing MyLoggingInterceptor...");

    }

}

Configurando o interceptador no struts.xml

Uma vez que nós criamos uma classe interceptadora, tudo o que precisamos fazer é configurar ela no arquivo struts.xml e usa-la com as actions.

Para configurar o interceptador criado há pouco, adicione o seguinte código dentro do struts.xml

<interceptors>    <interceptor name="mylogging"

        class="net.viralpatel.struts2.interceptor.MyLoggingInterceptor">

    </interceptor>

    <interceptor-stack name="loggingStack">

        <interceptor-ref name="mylogging" />

        <interceptor-ref name="defaultStack" />

    </interceptor-stack>

</interceptors>

Esse código deve ser adicionado depois da tag <result-types >  no <package ></package>. Aqui nós configuramos um novo interceptador mylogging com a tag <interceptor >. Também veja que nós definimos um interceptor-stack com o nome de loggingStack. Isso é para ter certeza de que o Struts2 chamará todos os interceptadores padrões assim como chamará o nosso interceptador customizado. Isso é muito importante como por exemplo a lógica de validação não será chamada na nossa aplicação Struts2 se nós ignorarmos o stack padrão (defaultStack) dos interceptadores.

Nós podemos fazer o novo loggingStack como interceptador padrão ou podemos configurar ele em cada nível de action. A fim de faze-lo um stack padrão, nós devemos adicionar o seguinte no struts.xml

<default-interceptor-ref name="loggingStack"></default-interceptor-ref>

Uma vez que nós adicionamos o código acima no Struts.xml, o logginStack será aplicado à todas as action daquele pacote.

Também nós talvez quiséssemos aplicar o interceptador customizado para apenas determinadas actions. Para fazer isso, nós precisamos adicionar a tag interceptor-ref na action.

<action name="login"    class="net.viralpatel.struts2.LoginAction">

    <interceptor-ref name="loggingStack"></interceptor-ref>

    <result name="success" type="tiles">/welcome.tiles</result>

    <result name="error">Login.jsp</result>

</action>

Isso é tudo pessoal

Se nós executarmos nossa aplicação StrutsHelloWorld no ecplipse e olharmos os logs do console, nós vamos encontrar as declarações de log que nós imprimimos no nosso interceptador.

Initializing MyLoggingInterceptor.....

..

..

Before calling action: net.viralpatel.struts2.LoginAction

..

..

After calling action: net.viralpatel.struts2.LoginAction Time taken: 313 ms

..

..

..

Destroying MyLoggingInterceptor...

Download do código fonte

Clique aqui para fazer o download do código fonte sem os JARs (17KB)

Fonte: viralpatel.net – Viral Patel