VRaptor e Apostila FJ28

9 respostas
M

Pessoal.

Estou ficando doidão com vraptor, na apostila fj28 (pg. 78) da Caelum, diz que um CriadorDeSessionFactory deve ter um escopo de aplicação “@ApplicationScoped”, até aí blz…

Mas quando faço um INSERT no BD e volto na minha aplicação e dou um F5 ele não mostra o novo registro, até mesmo fechando o browser ao retornar ele continua listando os mesmos registros, reinicio o TOMCAT aí sim o novo registro é exibido… Ou seja, o @ApplicationScoped está fazendo a parte dele, para fazer um teste, retirei ele e aí funciona tudo beleza…

Então fiquei na dúvida se devo tirar o @ApplicationScoped e deixar o padrão “@RequestScoped”, não sei o quanto isso é prejudicial, pois na apostila é dito que é muito custoso criar um “CriadorDeSessionFactory” a cada requisição…

Alguém teria alguma dica?

Abs.

Marcelo

9 Respostas

magnocosta

mribeiro,

Acho melhor você postar seu CriadorDeSessionFactory.

Att,

M

É verdade cara, tem razão…

Essas são as classes sugeridas na apostila:

// Classe responsável pela criação de sessions ////////////////////
@Component
public class CriadorDeSession implements ComponentFactory<Session> {

	private final SessionFactory factory;
	private Session session;
	
	public CriadorDeSession(SessionFactory factory) {
		this.factory = factory;
	}
	
	@PostConstruct
	public void abre(){
		this.session = factory.openSession();
	}
	
	public Session getInstance() {
		return this.session;
	}
	
	@PreDestroy
	public void fecha(){
		this.session.close();
	}
	
}

// Classe responsável pela criação da fábrica de sessions ////////////////////////////////////
// Aqui se eu retiro o escopo de sessão funciona, mas deixando dessa forma não. ////////
@Component
@ApplicationScoped
public class CriadorDeSessionFactory implements ComponentFactory<SessionFactory> {
	
	private SessionFactory factory;
	private Configuration config;
	
	public CriadorDeSessionFactory(Configuration config) {
		this.config = config;
	}
	
	@PostConstruct
	public void abre(){
		ServiceRegistry serviceRegistry;
		serviceRegistry = new ServiceRegistryBuilder().applySettings(config.getProperties()).buildServiceRegistry();
		this.factory = config.buildSessionFactory(serviceRegistry);
	}
	
	public SessionFactory getInstance() {
		return this.factory;
	}
	
	@PreDestroy
	public void fecha(){
		this.factory.close();
	}
	
}

Abs.

Marcelo

Lucas_Cavalcanti

vc fez o interceptor de transações?

M

Olá Lucas…

Cara, interceptor de transações???
Seria o beginTransaction e o commit???

Existe isso na apostila? Poderia dar umas dicas?

Valeu!

Abs.

Marcelo

Lucas_Cavalcanti

tem isso na apostila sim, um pouquinho depois dos criadores de session e sessionFactory

M

Olá Lucas,

Cara, já li toda a apostila novamente, mas não encontro nada sobre Interceptor de Transações, você se refere ao @PostConstruct e @PreDestroy???

Desculpe ainda estou me familiarizando com os nomes das coisas…

Abs.

Marcelo

Lucas_Cavalcanti

Tem razão, não tem o interceptor na apostila, mas em todos os daos ele faz session.beginTransaction() e depois commit(), vc está fazendo isso?

M

Exatamente, estou fazendo assim:

public void salvar(Contato contato){
		Transaction tx = session.beginTransaction();
		session.save(contato);
		tx.commit();
	}

Já coloquei um system.out.println() antes do commit para ter certeza e ela está passando por ali normal… Só quero ter certeza de que eu não estaria prejudicando meu projeto por conta de deixar meu CriadorDeSessionFactory como @RequestScoped.

ALguém saberia me dizer quais são os impactos?

Abs.

Marcelo

Lucas_Cavalcanti

o criadorDeSessionFactory precisa ser @ApplicationScoped

senão o hibernate vai ler as configurações todas a cada request, e não há necessidade pra isso.

Criado 5 de julho de 2012
Ultima resposta 8 de jul. de 2012
Respostas 9
Participantes 3