olá
estou a possibilidade de migrar um sistema para o VRaptor 3.5.
Alguém sabe se eu posso injetar Beans CDI dentro das controller do VRaptor?
obrigado
Ainda não pode, mas poderá já na próxima versão… não lançamos no 3.5 pq a gente tá tentando remover uns pré-requisitos chatos que o CDI impõe.
Olá Lucas,
a próxima versão que vc diz é a 4? ou 3.5.1 (ou 3.6)?
obrigado
3.6… a 3.5.1 vai ser só de bugfixes.
entao ta mais perto do que eu achava 
ja está definido como será? se existirá um Weld Provider ou algo do tipo?
a branch master no github tem algum trabalho em andamento com CDI pra que eu possa fazer um fork e ver se posso dar uma ajuda?
comecei hoje um projeto bem grande que inicialmente seria com VRaptor, CDI e EJB(para as integrações remotas)…
Estava até pensando em usar Spring pra depois migrar tudo pra CDI heheh - depois de usar CDI da até preguiça do Spring
abraços
Por enquanto está sendo implementado num fork: https://github.com/asouza/vraptor
O problema é conseguir fazer tudo funcionar sem precisar criar construtores sem argumento pra tudo, senão teria que refazer todos os plugins do VRaptor.
pra isso pensei em criar proxy com javassist (que acho que da pra classes sem construtor sem argumento) mas aí acho que não vai adiantar nada pq o weld não vai reconhecer estes proxies
eh… ele faz isso antes de rodar a aplicação… precisa ter os .class
complicado 
enquanto isso vou fazer com o spring ou guice mesmo e depois migrar pra cdi… é só pojo mesmo… pra migrar depois nao deve ter tanto problema.
obrigado!
acabei insistindo no cdi e tentei usar o vraptor-cdi-plugin do github do garcia-jj… mas nao deu certo… nao sei pq na hora de scannear os plugins dava pau no jboss…
olhei o código do plugin pra ver como funciona e vi que é apenas ComponentFactory pra fazer lookup do BeanManager do CDI… e outro componente para expor um ServiceLocator…
Entao fiz o mesmo no projeto sem incluir o plugin e funcionou!
o unico problema é ter que fazer um ComponentFactory pra cada tipo de bean CDI… tentei fazer um generico mas ainda não consegui…
abraços
dá pra fazer umas malandrices usando o Guice… acho algo do tipo funciona:
-
vc precisa sobrescrever o GuiceProvider e sobrescreva o método custom Module, criando um modulo seu que registra o módulo do super.
-
Sempre que quiser um componente do CDI, receba um Supplier no construtor, e chame o .get() qdo for usar.
-
no module faça:
binder.bindListener(VRaptorAbstractModule.type(Matchers.subclassesOf(Supplier.class)), new TypeListener() {
public void hear(TypeLiteral literal, TypeEncounter encounter) {
Class tipoGenerico = pegaOTipoGenericoDe(literal.getType());
binder.bind(literal).to(new CDISupplier(tipoGenerico));
}
});- Crie o CDISupplier que implementa Supplier e no get faz o lookup no CDI com o tipoGenerico passado.
Se precisar de ajuda com qqer um desses items dá um toque
Se conseguir, por favor compartilhe a solução =)
obrigado, cara!
vou tentar isso amanhã na empresa.
aqui em casa, agora de noite, por curiosidade baixei o fork do vraptor com cdi e coloquei pra rodar.
O problema com proxy para classes sem construtor sem argumento é esse?
acontece quando o VRaptor está subindo e para várias outras classes.
para testes (só pro Weld parar d reclamar) coloquei um arquivo vazio chamado “org.jboss.weld.enableUnsafeProxies” na pasta META-INF do VRaptor… buildei… e executei o Main do Weld para standalone… o VRaptor subiu e minha aplicacao (standalone, porém dependente do vraptor) iniciou e funcionou a DI.
Ainda tinha um errinho que pra parar de dar erro coloquei um construtor vazio no br.com.caelum.vraptor.proxy.JavassistProxifier…
provavelmente isso nao vai funcionar pq tive que setar null no atributo instanceCreator…
mas enfim, to fazendo um projeto de teste agora pra rodar no JBoss
Olha só! =)
se isso ajudar a parte de não precisar do construtor vazio, ótimo!
o que o pessoal tinha feito é criar um java agent que adiciona o construtor na hora da carga das classes.
Provavelmente colocar o @Inject no outro construtor funciona pro proxifier.
boa
nem me liguei em colocar @Inject no profixier
coloquei e funcionou no standalone.
to só arrumando um probleminha no meu repositório local do maven e ja faço um projeto de teste pra ver o que acontece “deployando” no jboss 7
mais uns avanços no fork
nao estava subindo no jboss por causa que a CDIProvider.java estava tentando pegar o BeanManager via ServletContext… mas nao achava… mudei pra buscar via JNDI e blz encontrou… (mas nao sei se no tomcat ou jetty funcionaria)
só que o projeto ainda não sobe… agora ta dando NPE na InterceptorStereotypeHandler.java:58… o InterceptorRegistry não foi injetado e ficou null…
amanha eu continuo. senao não acordo amanha cedo pra trabalhar heheh
abraços!
Valeu dbdbdb!
qualquer novidade dá um toque =)
Basta colocar o arquivo vazio no jar do vraptor? Eu tenho recebido erros como:
sim, basta colocar um arquivo vazio chamado “org.jboss.weld.enableUnsafeProxies” na pasta META-INF no jar do VRaptor que resolveu estes erros.
vi aqui a “documentação” deste arquivo:
https://community.jboss.org/blogs/stuartdouglas/2010/10/12/weld-cdi-and-proxies
Eu fiz isso tanto no jar do vraptor quando no classpath da minha app, e os erros são os mesmos que sem o arquivo.
Eu já tinha lido na documentação, e ele realmente serve somente para não precisar do construtor default na serialização dos beans. Porém na documentação não cita nada referente ao @Inject no construtor que receberá a injeção. Ou seja, ainda é necessário o cdi-agent, correto? Pelo menos para mim não funcionou sem o agent, ou seja, deu tudo na mesma.
Esta flag só funciona para quem usa weld 1.1+, ou seja, tem que ter JBoss 1.1+ ou Glassfish 4+.
só hoje retomei os testes com o fork do vraptor com cdi.
de fato não adiantou muita coisa… apesar de nao dar mais os erros do proxy, as injeções com @Inject nos construtores nos códigos do vraptor não funciona 