Buenas.

Estoy intentando pasar un parámetro de un Managed Bean con ViewScoped a otro. En concreto, de una tabla, quiero "seleccionar" un elemento y mostrar los datos del seleccionado en la página siguiente, que tiene un Managed Bean distinto.
He probado con <f:setPropertyActionListener value="" target=""/>
He probado con <f:attribute name="" value=""/>
Y el paso del parámetro lo hace bien. Pero por algún motivo, JSF me construye dos veces el Managed Bean de destino (lo he probado, llama dos veces al PostConstruct). La segunda vez que lo construye, ¡me destruye el parámetro que le he pasado!.
Tengo que acabar metiendo en sesión el parámetro, y luego quitarlo. Y Prefiero no tener que meter nada en sesión.

¿Sabeis por qué ocurre?, ¿Cómo puedo pasar los parámetros (son objetos enteros) de un bean a otro?.

Un saludo, y como siempre, muchas gracias por vuestras respuestas.

Amplío el post...
Me ocurre aunque no envíe parámetros.

Me he fijado que al ejecutar un action en un viewScoped, siempre llama al PostConstruct dos veces (una antes y otra después de ejecutar el action).

¿Hago algo mal al iniciar los viewScoped?.

Un saludo.

Buenas antoniovl. Muchas gracias por tu respuesta.

He visto una posible solución, incluyendo lo siguiente:

Dentro del commandLink o commandButton, poner la etiqueta:

<f:param name="nombre" value="#{valor}"/>


Dentro de. xhtml destino, definir lo siguiente:


<f:metadata>
<f:viewParam name="nombre" value="#{viewBean.valor}"/>
</f:metadata>


En teoria debería inyectártelo. Pero iba cortito de tiempo, y estoy haciendo lo que comentas, pasar los parámetros por sesión y luego eliminarlos (algo que odio, y no me gusta nada).

Cuando tenga tiempo probaré lo del viewParam, se supone que debería funcionar.

El problema es que cuando estás en un xhtml y haces referencia a otro viewScoped Bean, al estar en el xhtml origen, construyes el viewScoped bean desde ahí. Al cambiar de xhtml, interpreta que es una pantalla nueva, destruye el view Scoped bean al que le pasaste los parámetros, y construye otro al renderizar el xhtml destino.
Es un poco lío y coñazo... pero bueno. La cosa es cogerle el tranquillo al life cycle de este tipo de beans.

¡Muchas gracias por tus propuestas!.

Un saludo.

Muchas gracias por tu recomendación. Lo probaré. Lo bueno de este proyecto es que puedo hacerlo como me plazca... tengo absoluta libertad.

Otra limitación que me parece que tienen los ViewScoped es que no pueden inyectarse EJB remotos, solo locales (al menos a mi me falló intentándolo).

Vaya faena...

Bueno, gracias por las respuestas.

¡Un saludo!.

al fin que fue la solucion

Hola aqui ya en el 2017, @antoniovl deja un ejemplo usando CDI que me parece interesante porque lo probe con Glassfish 4.1, Netbeans 8.1 and JSF 2.1.3 y parece trabajar bien.
En una aplicacion necesito esa corversacion con CDI, porque generalmente hago el CRUD en una vista .xhtml con un bean ViewScope, pero ahora necesito hacer lo que @mayantigo expreso. Esta bien este enfoque?
Trabajo actualmente con Icefaces 3.3.0, este framework tiene muchos comportamientos Ajax, y hasta ahora he trabajado solo anotaciones @ManagedBean(name = "..."), @ViewScoped y @SessionScoped, y trabaja bien. No he usado las anotaciones @Named @RequestScoped o @ConvesationScope.
Saludos Y gracias.