Esto por sí mismo no es peligroso. Pero analicemos este caso típico

En este caso por cada fila de la tabla, se hará una llamada al método UserManager.getUserList() para obtener el usuario actual. Si el método UserManager.getUserList() implica una llamada a la base de datos, el tiempo de carga crece imcreíblemente.

Una primera solución es usar el patrón de diseño Carga Perezosa (LazyLoad).

De esta forma la lista no se crea cada vez que se la llama desde la página JSF. Pero aún así se sigue invocando el método getUserList() multitud de veces.

La mejor solución es poner la lista en el contexto de la página, y acceder a ella directamente por su nombre en el contexto en vez de por el componente al que pertenece.
Esto se puede hacer mediante la anotación @Out o la anotación @Factory

Es decir, si en una clase 'normal' (sin la anotación @Name) utilizas un @In o un @Out o cualquier otra anotación propia de Seam, esta será ignorada. Aun así,  la API de Seam nos permite obtener instancias de otros componentes directamente, buscándolos a través de su nombre o de su clase.

El metodo getInstance también admite otros parametros para indicar si hay que crear el elemento, su contexto, etc..

• org.jboss.seam.validationFailed : Se lanza cuando hay un fallo de validación
• org.jboss.seam.postCreate.<name> : Se lanza cuando el componente con nombre <name> se instancia. Se puede usar de forma similar a la anotación @Create de los EJBs
• org.jboss.seam.exceptionNotHandled : Se lanza cuando salta una excepción que no es manejada por Seam.
• org.jboss.seam.beforePhase y org.jboss.seam.afterPhase : Se lanzan respectivamente antes del inicio y después del final de cada fase JSF. Este evento es lanzado con el parámetro PhaseEvent, que indica la fase que empieza/acaba

La lista completa de eventos puede verse en el manual

Para escuchar eventos en Seam debemos usar la anotación @Observe para anotar un método que se ejecutará en respuesta al evento. Este método deber ser siempre público y, en el caso de los eventos predefinidos, sin argumentos (con alguna excepcion).
Hay que tener en cuenta que estos métodos se ejecutan en el mismo hilo que la traza principal, de forma que hasta que no terminen de ejecutarse la aplicación no continuará, por lo que hay que tener cuidado.

Pero aparte de los eventos predefinidos, también podemos lanzar y escuchar nuestros propios eventos.
Disponemos de varias formas de lanzar nuestros eventos personalizados:

• Etiqueta @RaiseEvent
  Al ejecutar un método anotado con la etiqueta @RaiseEvent, se lanzará el evento indicado
  @RaiseEvent("venta-confirmada")
  public String confirmarVenta(int idVenta) {
    // cuerpo del metodo
  }

• Fichero de navegación pages.xml
  Puedes lanzar un evento mediante la etiqueta <raise-event>
  <navigation from-action="#{manager.confirmarVenta}">
      <rule if-outcome="success">
          <raise -event type="venta-confirmada" />
      <redirect view-id="home"/>
      </rule>
  </navigation>

• Mediante el componente Events
  Este componente permite lanzar eventos síncronos o asíncronos de manera programática.
  Los eventos lanzados de forma asíncrona se ejecutan en un hilo paralelo, por lo que son ideales para tareas pesadas o susceptibles de fallo que no deberían afectar al resto del sistema, como envío de emails, estadísticas...

  Las ventajas de usar esta manera de lanzar eventos es que, aparte de poder lanzar eventos asíncronos, se pueden añadir parámetros al evento, que serán pasados como argumentos a la función que los observe en el orden en el que se añaden. Por ello, la función observadora debe tener como máximo el mismo número de argumentos de los que se envían al lanzar el evento, y siempre el mismo tipo.
  También permite lanzar eventos al cabo de un determinado tiempo o lanzarlos al final de la transacción en curso.

  Aquí vemos un ejemplo que ejecuta un método a través de eventos cada vez que se confirma una venta.

  public String confirmarVenta(int idVenta) {
      Events.instance().raiseEvent("venta-confirmada", idVenta);
  }

  @Observe("venta-confirmada")
  public void observarVentaConfirmada(int idVenta) {   
      // do domething
  }

  También podemos optar por lanzar el evento de forma asíncrona y/o añadir más parámetros al evento, los cuales serán ignorado por las funciones observadoras con menor numero de argumentos

  public String confirmarVenta(int idVenta) {
      Events.instance().raiseEvent("venta-confirmada", idVenta, idVendedor);
  }

  @Observe("venta-confirmada")
  public void registraVenta(int idVenta) {
      // solo nos interesa el identificador de venta
  }

  @Observe("venta-confirmada")
  public String otorgaComisionAlVendedor(int idVenta, int idVendedor) {
      // Obtenemos ambos parámetros
  }

Estas URLs además de ser más intuitivas y agradables a la vista, también son más agradables para buscadores de internet como google (o podríamos decir más agradables para EL BUSCADOR de internet).Esta es una de las técnicas seo más simples, destinadas a mejorar tu posicionamiento en buscadores.

En Seam podemos obtener estas URLs sencillas a través del filtro URLrewrite. Este filtro básicamente se encarga de traducir URLs, y es muy muy fácil de usar.
Una de las principales ventajas es que es una capa independiente que se coloca por encima de la aplicación. No es necesario modificar ni una línea de código ya existente, simplemente definir cómo se van a traducir las direcciones.

1. Añadir el archivo urlrewrite.jar que viene incluido en la distribución de Seam en la carpeta WEB-INF/lib del proyecto. La mejor forma de hacerlo es mediante el archivo de ant que crea el seam-gen
2. Configurar el filtro UrlRewrite en el web.xml tal y como se indica aqui
3. Crear el fichero urlrewrite.xml que contiene las reglas de traduccion de urls en la carpeta WEB-INF. Aqui pongo el fichero del ejemplo seambay, pero lo mejor es mirar la documentacion oficial
   <!DOCTYPE urlrewrite
       PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
       "http://tuckey.org/res/dtds/urlrewrite3.0.dtd">

   <urlrewrite>

      <rule>
        <from>^/feedback/([A-Za-z0-9]*)$</from>
        <to last="true">/feedback.seam?member=$1</to>
      </rule>
      
      <rule>
        <from>^/itemdetail/([0-9]*)$</from>
        <to last="true">/auction.seam?id=$1</to>
      </rule>
      
      <rule>
        <from>^/bidhistory/([0-9]*)$</from>
        <to last="true">/bidhistory.seam?id=$1</to>
      </rule>

   </urlrewrite>

En otro post esplicaré con más detalle las posibilidades del fichero urlrewrite.xml, cómo usar parámetros, cómo traducir de nombres a identificadores numéricos, y cómo conseguir que las urls amigables las pueda generar nuestra aplicación tras el envío de formularios o acciones.

• @PersistenceContext
  EntityManager entityManager;

  El EntityManager es inyectado directamente por el EJB container. El ciclo de vida del EntityManager inyectado de esta forma terminará cuando la transacción sea completada.
  Tras el cierre de la transacción, las entidades son desacopladas del contexto de persistencia, lo que puede dar lugar a una LazyLoadException.

• @PersistenceContext(type=PersistenceContextType.EXTENDED)
  EntityManager entityManager;

  El EntityManager es inyectado directamente por el EJB container, y estará disponible aún después de que la transacción haya sido completa.
  Las entidades pueden seguir asociadas al contexto de persistencia durante varias interacciones.

• @In
  EntityManager entityManager;

  De esta forma, el EntityManager es inyectado por Seam y asociado al contexto de conversación, con las mismmas características que un EntityManager de tipo extendido.

• @PersistenceUnit
  EntityManagerFactory;

  public void getNewEmInstance() {
  return emf.createEntityManager();
  }

  Esta anotacion inyecta un EntityManagerFactory, que permite crear objetos EntityManager mediante el método EntityManagerFactory.createEntityManager();

1) Indica los métodos que van a invocarse vía Ajax
Simplemente marca con la anotación @WebRemote los métodos que quieras invocar por Ajax.

Si quisieses invocar un EJB en lugar de un POJO, las anotaciones @WebRemote deberán estar en la declaración los métodos de la interface del EJB.

2) Importa los scripts necesarios
Primero debes importar el script que contiene el código que permite las llamadas remotas:

Ahora por cada componente que contenga métodos que quieras invocar vía Ajax debes importar otro script en el que indicas el nombre del componente (el que has definido en la anotacion @Name).
Este script contiene el stub del componente, que indica los métodos a los que puedes llamar y la definición de sus tipos.
Por ejemplo, si tienes un componente anotado con @Name("calculadora") deberás incluir la siguiente linea

Si quisieses acceder a más de un componente en la misma página puedes especificar varios componentes:

También puedes importar el javascript de los componentes usando el tag s:remote.

3) Invoca el método y maneja la respuesta
Ahora podemos invocar los métodos de nuestra calculadora marcados con @WebRemote.
Para obtener los objetos javascript que representan nuestros componentes debemos hacerlo a través de Seam.Component.
En la llamada le pasamos los parámetros que tenga el método al que estemos invocando (admite sobrecarga) y un último parámetro que será la función a la que se invocará con el resultado de la invocación

También puedes acceder a los campos del componente que tengan un getter asignar un valor a los que tengan un setter.

Seam Remoting también permite evaluar EL Expressions, trabajar con Collections, hacer debug de las llamadas enviadas y recibidas, suscribirse a una cola JMS.
Toda esta información y más se encuentra disponible en la documentación en inglés

Pero estas ventajas solo están disponibles dentro de los componentes, es decir, en aquellas clases anotadas con @Name.
Si en una clase normal quisiésemos obtener el EntityManager, deberíamos hacerlo manualmente.

• setup: Sirve para configurar el proyecto. Te pregunta entre otras cosas el directorio de instalación de JBoss, si quieres desplegar un archivo war (sin EJBs) o un ear (con EJBs), el nombre del paquete donde irán las clases, y parámetros de la conexión con la base de datos.
• new-project: Crea un proyecto para eclipse con todas las dependencias y la configuración básica a partir de los datos proporcionados a través del setup.
• update-project: Actualiza el proyecto con las últimas dependencias.
• delete-project: borra el proyecto
• deploy: Despliega el proyecto y el datasource en JBoss
• undeploy: Replega el proyecto y el datasource.
• explode: Desplega el proyecto y el datasource en JBoss como una estructura de ficheros, sin empaquetar.
• restart: Resetea el proyectodesplegado con ”explode”
• unexplode: Replega el proyecto y el datasource desplegado con ”explode”
• new-action: Crea un nuevo Stateless Session Bean con su correspondiente interface y sus anotaciones.
• new-form: Crea un nuevo Stateful Session Bean con su correspondiente interface y sus anotaciones.
• new-conversation: Crea un nuevo Stateful Session Bean con su correspondiente interface y sus anotaciones. Añade anotaciones y esqueletos de métodos para trabajar con Tasks. También crea una clase de Test que puede usarse para simular el ciclo de petición/respuesta de JSF.
• new-entity: Crea un nuevo Entity Bean con sus anotaciones.
• generate-entities: Genera Entity Beans a partir de un modelo existente en la base de datos

Aunque seamgen está pensado para trabajar principalmente con eclipse y JBoss AS, también puede configurarse para crear aplicaciones para netbeans y glassfish, que tiene diferentes archivos de configuración.
Además puedes modificarla facilmente, ya que no deja de ser un simple script que trabaja con ant.

Al usar la opción new-project se crea un nuevo proyecto con una estructura de directorios que a primera vista parece algo compleja. Sin embargo vamos a ver como cada carpeta tiene una función o
definida.

• bootstrap: Contiene el JBoss Embeddable EJB 3.0 container, para poder desplegar EJBs fuera del servidor de aplicaciones.
• classes: Contienen los archivos de bytecodes (.class) de los componentes definidos por el desarrollador.
• dist: Contiene los archivos empaquetados (ear, war, jar) que serán desplegados en el servidor de aplicaciones.
• exploded-archives: Contiene la estructura de directorios que se puede desplegar directamente en el servidor de aplicaciones.
• lib: Contiene todas las librerías(.jar) con las dependencias necesarias para la compilación y ejecución de la apliación.
• nbproject: Contiene los archivos necesarios para trabajar en el proyecto con netbeans.
• resources: Contiene todos los archivos de configuración.
• src: Contiene el código fuente de los componentes definidos por el desarrollador, separados en tres bloques: entidades, acciones y test.
• test-build: Esta carpeta está destinada a almacenar los test de integración.
• view: Contiene todos los elementos relativos a la vista, como archivos css, imágenes, archivos xhtml...

Vamos a ver los archivos de configuración que podemos encontrarnos en un proyecto Seam, su localización y cometido.

• *-ds.xml: Contiene los par ́metros de conexión a la base de datos. Este archivo debe desplegarse en el directorio "deploy" de JBoss
• seam.properties: Este archivo debe estar presente obligatoriamente (aunque esté vacío) en la carpeta raíz del archivo jar que va a desplegarse o en la carpeta classes del archivo war.
  Este archivo se usa para configurar las propiedades de los componentes.
  components.xml: Puede aparecer en tres lugares; el directorio "META-INF" del archivo jar, el directorio "WEB-INF" del archivo war, o cualquier directorio que contenga clases anotadas con @Name. En él se declaran y configuran componentes.
• components.properties: Especifica el valor de variables que pueden usarse en el archivo components.xml, como @debug@. Estas variables se reemplazan cuando se despliega la aplicación.
• persistence.xml: Se sitú en el directorio "META-INF"" del archivo jar y en él se declaran las unidades de persistencia.
• security.drl: En él se declaran las reglas de autorización del subsistema Drools. Se coloca en la raíz del archivo ear o en el directorio "classes" en el caso de desplegar en un archivo war.
• application.xml: Es el descriptor de despliegue de Enterprise Application Archives y es un archivo estándar en aplicaciones java 2 EE. Se sitúa en el directorio "META-INF" del archivo ear y en él se declaran los módulos de la aplicación y las dependencias.
• ejb-jar.xml: Es el descriptor de despliegue est ́ndar de la especificació EJB. Se coloca en el directorio META-INF del archivo jar, y en Seam contiene la declaración del SeamInterceptor.
• jboss-app.xml: Es el descriptor de aplicación específico de JBoss y se sitúa en el directorio "META-INF" del archivo ear.
• faces-config.xml: Es el archivo de configuración central de JavaServer Faces. Se encuentra en el directorio "WEB-INF" del archivo war.
• pages.xml: Especifica las reglas de navegación. Se encuentra en el directorio "WEB-INF" del archivo war.
• web.xml: Es el descriptor Web estádar especificado en J2EE. Se encuentra en el directorio "WEB-INF" del archivo war.
• import-*.sql: Se coloca en la raíz del archivo jar. Puede contener código sql que será ejecutado cada vez que se despliegue la aplicación

Una aplicación Seam típica tendrá la siguiente estructura de archivos

my-application.ear/
    jboss-seam.jar
    jboss-el.jar
    jboss-el-api.jar
    META-INF/
        MANIFEST.MF
        application.xml
    my-application.war/
        META-INF/
            MANIFEST.MF
        WEB-INF/
            web.xml
            components.xml
            faces-config.xml
            lib/
                jsf-facelets.jar
                jboss-seam-ui.jar
        login.jsp
        register.jsp
        ...
    my-application.jar/
        META-INF/
            MANIFEST.MF
            persistence.xml
        seam.properties
        mi/
            paquete/
                myapplication/
                    Clase1.class
                    Clase2.class
                    Clase3.class

• La idea de workspace. Cada usuario de la aplicación debe tener su propio espacio de trabajo, sin interferir en la actividad del resto de usuarios.
• La idea de transacción. La mayoría de los frameworks están construidos siguiendo una arquitectura sin estado, incapaz de manejar correctamente los contextos de persistencia extendidos, dando lugar a fallos como la famosa LazyLoadException.
• La idea de tarea en un workflow.

Uniendo y respetando estos tres conceptos, obtenemos el modelo conversacional de Seam, que nos
permite construir aplicaciones eficientes de más ráidamente.
Este modelo sigue las siguientes reglas para crear o destruir el contexto de conversación:

• Siempre hay una conversación activa durante la petición, el proceso de validación, la actualización de los modelos de datos, la invocación de la aplicación o la respuesta del ciclo de vida de JSF.
• Con cada petición JSF, Seam intenta restaurar una ”conversación larga” (longrunning conversation) que existiese previamente. Si no la encuentra crea una conversación nueva.
• Cuando se encuentra una anotacion @Begin en un méodo que se ejecute, la conversación activa se promociona a conversación larga.
• Cuando se encuentra una anotacion @End en un método que se ejecute, cualquier conversación larga se degrada a conversación normal.
• Tras cada respuesta JSF, Seam almacena los contenidos de la conversación larga si existe, y si no destruye el contenido de la conversación normal.
• Cualquier petición JSF propaga el contexto de conversación, y por defecto las peticiones normales no lo propagan.
• Si una petición JSF es redirigida, Seam almacena y restaura posteriormente la conversación para preservar su contenido.