Vraptor + spring + hibernate: gerenciar session e transação pelo spring

This message was edited 1 time. Last update was at 12/05/2010 22:04:14

Boa tarde

Seguindo o tutorial da FJ28, cheguei no capitulo da integração com spring, mas não consigo fazer o sistema funcionar mais desde que coloquei o controle de transação no spring.

seguem os códigos:

AppContext:

no web.xml, eu registrei um provider:

código do provider:

o dao:

e o controler;

do jeito que está, na hora de chamar algum método do dao, da o seguinte erro:

Ah, blz, é pq eu registrei um SessionFactory no spring e um no provider.
tirei o do provider, (SessionFactoryCreator), e deixei o do spring, pq ele é usado na criação do transactionManager.

ai o erro mudou para:

Sim, blz, é pq o construtor recebe uma session, e ele não ta achando o contrutor sem argumentos. Mas essa session deveria ter sido injetada pelo spring, ou pelo vraptor.
Como resolver essa situação? vou ter que deixar os dados sendo gerenciados pelo spring e pelo vraptor ao mesmo tempo?

[]'s

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6394 Offline

qdo vc usa qqer coisa com AOP (segurança por exemplo) vc não pode usar injeção de dependências pelo construtor...

ao invés do construtor crie setters pros atributos e anote-os com @Autowired (do spring) e tudo vai funcionar

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6394 Offline

e, claro, vc não pode ter o SessionFactoryCreator registrado...

possivelmente vc vá ter que receber a session do jeito do spring tb, pq ele faz coisas bizarras envolvendo threadLocals... o jeito do spring é via HibernateTemplate ou SessionFactoryUtils...

blz, vou testar usando spring puro nessa parte então.

Mas, antes disso, olhei os fontes da classe HibernateTransactionInterceptor, pelo que eu vi ele simplesmente abre e fecha a transação a cada request. Ele não faz operações de roolback? Por que esse era o motivo de querer utilizar o controlador do spring

Valeu pela resposta lucas!

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6394 Offline

sim, ele fecha a transação a todo request, mas se der algum problema no meio do caminho ele dá rollback...

o source:
http://github.com/caelum/vraptor/blob/master/vraptor-core/src/main/java/br/com/caelum/vraptor/util/hibernate/HibernateTransactionInterceptor.java

Lucas Cavalcanti wrote:sim, ele fecha a transação a todo request, mas se der algum problema no meio do caminho ele dá rollback...

o source:
http://github.com/caelum/vraptor/blob/master/vraptor-core/src/main/java/br/com/caelum/vraptor/util/hibernate/HibernateTransactionInterceptor.java

Não deveriamos ter rollback apenas em runtime-exceptions?

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6394 Offline

pq?

se vc está dentro de uma transação, e qualquer coisa dá errado, vc tem que desfazer tudo.... esse é o conceito de transações... ou tudo dá certo, ou nada acontece

This message was edited 1 time. Last update was at 12/05/2010 23:24:45

Lucas Cavalcanti wrote:pq?

se vc está dentro de uma transação, e qualquer coisa dá errado, vc tem que desfazer tudo.... esse é o conceito de transações... ou tudo dá certo, ou nada acontece

Pensei nesse conceito por causa do JTA. Apenas é feito rollback em runtime-exceptions ou quando você anota alguma não-runtime com @ApplicationException(rollback=true),

Em EJB apenas runtimes são feitas rollback.

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6394 Offline

a idéia é colocar transações onde elas fazem sentido... e onde elas fazem sentido, qqer erro é motivo de rollback

no caso de EJBs, tem muito mais coisa envolvida do que só a sua lógica de negócio, e assim talvez faça algum sentido não dar rollback em certos casos (não que eu concorde, mas...)

Notícias, artigos e o maior fórum brasileiro sobre Java