ViewScoped y composite components

He tenido que crear un componente compuesto en jsf 2.0 y durante la construcción del bean administrado me encontré con el siguiente comportamiento:

Si el managed bean está anotado @ViewScoped, y se quiere agregar un Session bean @EJB, éste último debe ser transitorio (@Transient). Pero en este caso, si se define en el componente un método y se pretende utilizar, se obtiene un error que indica que no encuentra la propiedad del nombre del método en el managed bean.

Entonces, para mi caso la solución fue modificar el managed bean para que fuera @RequestScoped, el Session bean inyectado ya no necesita ser transiente, y el componente entiende correctamente que el atributo definido como un método es efectivamente un método y no una propiedad.

La razón, se hace evidente entonces. @ViewScoped requiere que sus atributos sean o bien transitorios o bien serializables pues para mantener la vista entre peticiones tendrá que enviar su estado en el request, o almacenarlo en la sesión.

Mala decisión con dozer y proyectos dependientes

Como ya entendí que no soy un escritor, limitaré mis entradas en el blog a construir memoria. Así, esta primera entrada de este nuevo intento será para que luego no se me olvide recordar que al utilizar dozer, si se decide hacer una locura (creo que bestialidad sería una palabra más adecuada) como la siguiente, se tendrán inconvenientes para probar.

Proyecto A, depende de proyecto B.

En proyecto B se crea un archivo dozer en el que se establecen relaciones entre clases del proyecto B. Hasta ahí todo bien (o casi todo bien debería decir, pues sería mejor crear un dozer para cada relación entre clases?). Pero además se incluye una relación con una clase del proyecto A (esta es la casi segura bestialidad). Al intentar ejecutar pruebas de unidad (junit), me encontraré con que la clase del proyecto B no existe:

org.dozer.MappingException: java.lang.ClassNotFoundException: