Registro componente opicional

Assuntos Gerais
#1

@Override protected void registerCustomComponents(ComponentRegistry registry) { registry.registry(SessionCreator.class, SessionCreator.class); registry.registry(SessionFactoryCreator.class, SessionFactoryCreator.class); }

só pra constar, é assim mesmo ??

não é nada como

@Override protected void registerCustomComponents(ComponentRegistry registry) { registry.registry(Session.class, SessionCreator.class); registry.registry(SessionFactory.class, SessionFactoryCreator.class); }

??

sim eu ainda não pude testar… assim que conseguir testar dou retonro se descobrir

#2

já descobri que é como anotado no exemplo 1

#3

só uma coisa que tá errada na documentação (e vai ser corrigida hoje): o certo é registry.register(…)

#4

true!!!

[code]public class CoreProvider extends SpringProvider {

@Override
protected void registerCustomComponents(ComponentRegistry registry) {
	registry.register(SessionCreator.class, SessionCreator.class);
	registry.register(EntityManagerCreator.class, EntityManagerCreator.class);
	registry.register(EntityManagerFactoryCreator.class, EntityManagerFactoryCreator.class);
	registry.register(TransactionInterceptor.class, TransactionInterceptor.class);
}

}[/code]

^^ … consegui fazer o LAZY com meus entityManager e session lucascs \o/ …

agora ate economizando anotação eu estou… antes eu tinha uma anotação @DontIjectDaoFactory (no VRaptor 2) … quando encontrava essa anotação em logica ou componente, eu não criava uma conexão real…

agora eu mando um EntityManger Enchaced que só conecta mesmo quando chama o primeiro método… não preciso mais me preucupar com métodos que não precisam de conexão ^^ … CGLib muito rox

#5

Muito bom! =)

Se você quiser escrever uma receita de como vc fez isso, a gente publica no site do VRaptor… e agradece imensamente =)

a seção de cookbooks vai ser inaugurada hoje provavelmente, com receitas de usuários

[]'s

#6

[quote=lucascs]Muito bom! =)

Se você quiser escrever uma receita de como vc fez isso, a gente publica no site do VRaptor… e agradece imensamente =)

a seção de cookbooks vai ser inaugurada hoje provavelmente, com receitas de usuários

[]'s[/quote]

ok! combinado… vou preparar um texto,

de toda forma, o código fonte esta no grupo de dev do vraptor, com meu pessim inglês mas esta =x

#7

[quote]^^ … consegui fazer o LAZY com meus entityManager e session lucascs \o/ …

agora ate economizando anotação eu estou… antes eu tinha uma anotação @DontIjectDaoFactory (no VRaptor 2) … quando encontrava essa anotação em logica ou componente, eu não criava uma conexão real…

agora eu mando um EntityManger Enchaced que só conecta mesmo quando chama o primeiro método… não preciso mais me preucupar com métodos que não precisam de conexão ^^ … CGLib muito rox[/quote]

Lavieri, era isso que eu ia comentar. Ao invés de você SEMPRE trazer a session, traga uma espécie de “lazy-session”. Aliás a especificação EJB não diz nada sobre o entity-manager ser lazy ou não. Creio que as injeções de resources e entity-managers são non-lazy, correto?

#8

[quote=garcia-jj][quote]^^ … consegui fazer o LAZY com meus entityManager e session lucascs \o/ …

agora ate economizando anotação eu estou… antes eu tinha uma anotação @DontIjectDaoFactory (no VRaptor 2) … quando encontrava essa anotação em logica ou componente, eu não criava uma conexão real…

agora eu mando um EntityManger Enchaced que só conecta mesmo quando chama o primeiro método… não preciso mais me preucupar com métodos que não precisam de conexão ^^ … CGLib muito rox[/quote]

Lavieri, era isso que eu ia comentar. Ao invés de você SEMPRE trazer a session, traga uma espécie de “lazy-session”. Aliás a especificação EJB não diz nada sobre o entity-manager ser lazy ou não. Creio que as injeções de resources e entity-managers são non-lazy, correto?[/quote]

eram non-lazy ^^ … agora eu crio elas LAZY … ou como prefiro chamar… JIT (Just-in-Time)

#9

Desculpe o flood, mas… excelente trabalho, parabéns. E obrigado por compartilhar.

Abraços

#10

verdade! bom trabalho

sera que ainda precisamos fazer com que o Interceptor seja quebrado em duas interfaces?

#11

[quote=Paulo Silveira]verdade! bom trabalho

sera que ainda precisamos fazer com que o Interceptor seja quebrado em duas interfaces?[/quote]

Mas essa solução do colega não pode entrar como default no vraptor? Há um custo tão grande em ter uma lazy-session/lazy-entitymanager?

#12

já está no cookbook…

mas dá pra colocar nos utils do vraptor também…

#13

[quote=Paulo Silveira]verdade! bom trabalho

sera que ainda precisamos fazer com que o Interceptor seja quebrado em duas interfaces?[/quote]

na verdade Paulo, a sugestão escolhida na lista de discução de dev do vraptor acabou ficando em adicionar um opicional a anotação @Intercepts, ficando assim

anotado como true, todas as Dependencias serão injetadas via proxy, com objetos lazy.

segue link da sugestão => http://github.com/caelum/vraptor/issues/#issue/110

#14

observação, um link para a versão inicial de todas as versões que criei estão aqui

http://www.guj.com.br/posts/list/141500.java

posteriormente junto com as sugestões do lucascs, o código foi mudado para fazer uso de algumas classes auxiliares internas do vraptor

#15