jamirdeajr wrote:Se não entendi errado, você gostaria de utilizar do mesmo jeito que fazia antes, só que com JPA ?

Eu faço assim:

Ejb3Configuration cfg = new Ejb3Configuration(); Configuration hbmcfg = cfg.getHibernateConfiguration(); boolean bCreate = false; // você decide if (bCreate) { SchemaExport s = new SchemaExport(hbmcfg); // boolean script, boolean export, boolean justDrop,boolean justCreate s.execute(true, false, false, false); } else { SchemaUpdate s = new SchemaUpdate(hbmcfg); s.execute(true, false); };
E lá no persistence.xml deixei assim:
<property name="hibernate.hbm2ddl.auto" value="none"></property>

Lucas Cavalcanti wrote:acabei de testar aqui assim:

- declaração do packages no web.xml
- interceptor extendendo:
@Component public class Teste extends JPATransactionInterceptor { public Teste(EntityManager manager) { super(manager); } @Override public boolean accepts(ResourceMethod method) { return super.accepts(method); } }
- sem as outras classes...


no meu teste aqui ele passou pelo método accepts. O erro aí deve ser outro...

voltando ao seu código:
usuario = (Usuario) this.dao.getUsuarioDAO().selectByID(usuario.getId()); if (usuario != null) this.result.include("usuario", usuario); this.result.redirectTo(this.getClass()).formulario();
vc carrega o usuário, adiciona ele no result e faz o redirect... ou seja: é outra requisição e outra session, por isso o lazy init...

tenta trocar no dao.selectByID o manager.getReference por manager.find, isso deve funcionar

desculpe a confusão =S

Lucas Cavalcanti wrote:hum... tenta fazer o seguinte então:

- tire a configuração de packages da jpa
- troque a anotação do interceptor de @Component para @Intercepts
-crie as classes:

@Component @ApplicationScoped public class MyEntityManagerFactoryCreator extends EntityManagerFactoryCreator { //construtor } @Component public class MyEntityManagerCreator extends EntityManagerCreator { //construtor }
assim deve funcionar

[]'s

Lucas Cavalcanti wrote:faltou um ! no accepts do interceptor:

@Override public boolean accepts(ResourceMethod method) { return !method.containsAnnotation(NoTransaction.class); }

[]'s

Lucas Cavalcanti wrote:vc está achando trabalhoso desenvolver em geral ou só essa parte da Session?

tem uma issue no VRaptor para implementar isso, mas a gente ainda não achou uma forma boa de fazer https://github.com/caelum/vraptor/issues/#issue/188

Não há nada de errado criar uma classe que encapsula um único valor, isso é até uma boa prática. É raro ter um int ou uma string perdida no sistema que não tenha um significado maior que possa ser colocada numa classe. É bem mais fácil dar manutenção depois se for uma classe do que se for um int espalhado pelo código, não é verdade?

E não é uma simples classe que só encapsula os valores, ela pode ter comportamento também. O seu paginator por exemplo poderia ser usado para cuidar dentro da paginação dos seus daos, com um método do tipo:

public class Paginator { public Query pagina(Query query) { query.setFirstResult(page*PAGE_SIZE); .setMaxResults(PAGE_SIZE); return query; } }

Ou seja, não é um trabalho a mais a toa, ele tem algumas vantagens.

Lucas Cavalcanti wrote:quando vc fizer o redirect, vc pode passar os valores padrão

Lucas Cavalcanti wrote:não dá pra usar <c:url> dentro dos attributos do displayTag...

vc tem que fazer algo assim, que talvez funcione:

<c:url value="xxx" var="abc"/> ... requestURI="${abc}"

tá certo o construtor do Controller sempre ser chamado, mas a instância do Paginator é a mesma dentro da Sessão do usuario.

se vc muda os parametros do paginator, mesmo assim ele volta pro valor inicial?

Lucas Cavalcanti wrote:o jeito mais educado no VRaptor seria criar uma classe Session scoped:

@SessionScoped @Component public class Paginator { private int resultSize; private int page; //.... }

receber essa classe no construtor do controller (ou de alguma outra classe que vc precisar disso) e interagir com ela.

vc pode colocar métodos mais representativos e úteis do que só os getter/setters