RMI acessando aplicações JSF, Spring e Seam

Estou com o mesmo problema, não consigo fazer com que o Seam injete o DAO automaticamente na variável que criei o que gera um NullPointerException na hora de utilizar o objeto.

Veja o código do meu método que é acessado pelo RMI:

package br.com.cedro.rmi;
@Name("rmi")
public class HoursGeneratorImpl extends UnicastRemoteObject implements HoursGenerator, Serializable{
	
	/**
	 * 
	 */
	private static final long serialVersionUID = 1L;
	@In("#{userDao}")
	private UserDAO uDao;
	
	public HoursGeneratorImpl() throws RemoteException{}
	public String getTotalHours(int UsersCode, int year, int month) throws RemoteException {
		User user = uDao.findByUserCode(UsersCode).get(0);
		CalendarService calendar = new CalendarService();
		calendar.setUsername(user.getUsername());
		calendar.createCalendar(month, year);
		return calendar.getTotalGeral();		
	}
}

Embora eu não conheça o SEAM, ainda assim acho a questão esquisita.

Vai ver não entendi direito.

Na minha opinião, quem deveria injetar alguma coisa no serviço deveria ser o Spring e o seam deveria ficar fora desta região.

E ai, chutei muito fora?

flws

fantomas você não entendeu mesmo.

Veja annotation da injeção de variáveis do seam que estou usando:
import org.jboss.seam.annotations.In;

Eu também não sou um expert em nenhuma destas tecnologias, mas acredito que neste caso, o Seam gerencie toda a parte de injeção de instâncias em seus componentes, isto inclui as que são do Spring (como os DAOs). Da forma como foram integrados Seam e Spring, o segundo parece ser dependente do primeiro para ser iniciado.
Eu creio que o problema ocorra mais por que não existe o ciclo de vida do JSF nestas chamadas, assim o Seam não injeta e nem cria o componente.
Me corrijam se eu estiver errado.

Mas é justamente por isso que acho estranho!

Utilizar dois mecanismos de injeção pode deixar a coisa meio confusa.

Se achar realmente necessário (no mínimo deve ser interessante) utilize o Spring para os serviços, repositórios, daos, transações e etc… e deixa o resto com o seam.

flws

ACDias:

Eu também não sou um expert em nenhuma destas tecnologias, mas acredito que neste caso, o Seam gerencie toda a parte de injeção de instâncias em seus componentes, isto inclui as que são do Spring (como os DAOs). Da forma como foram integrados Seam e Spring, o segundo parece ser dependente do primeiro para ser iniciado.
Eu creio que o problema ocorra mais por que não existe o ciclo de vida do JSF nestas chamadas, assim o Seam não injeta e nem cria o componente.
Me corrijam se eu estiver errado.

Isto parece fazer sentido!

Confirma?

flws

Não estou conseguindo fazer com que a aplicação ao receber uma chamada via RMI entre no ciclo de vida do JSF. Devido à isso que o Seam não injeta as variáveis.

Tentei usar na minha classe a seguinte notação de scopo:

@Name("rmi")
@Scope(ScopeType.EVENT)
public class HoursGeneratorImpl extends UnicastRemoteObject implements HoursGenerator, Serializable{

mas mesmo assim continua sem funcionamento, ele não consegue injetar minha variável:

@In("#{userDao}")
private UserDAO uDao;

parece que ninguém teve esse problema ainda :(.

Me responde uma coisa, onde o Spring é usado na sua aplicação? Se não é ele quem faz a injeção de dependência, o que ele faz? Gerenciamento de segurança?

Por que você está utilizando ‘#{}’ no nome do seam component utilizado na anotação @In?

sic:

Por que você está utilizando ‘#{}’ no nome do seam component utilizado na anotação @In?