DataModelSelection en Conversation context problem

Después de mucho probar me he dado cuenta que el datamodelselection funciona en un contexto de session

Interceptar toda la aplicacion en Seam

Podemos utilzar la filosofía de Seam de interceptar todo, para cronometrar nuestra aplicación y comprobar en que métodos se producen retardos.

1. Creamos una clase que extienda de org.jboss.seam.ejb.SeamInterceptor es decir la clase que utiliza Seam para interceptar los componentes de la aplicacion:
• public class MiaoInterceptor extends SeamInterceptor {
  
  @AroundInvoke
  public Object aroundInvoke(InvocationContext invocation) throws Exception
  {
  
  if(invocation.getTarget().getClass().getPackage().toString().contains("es.miao")){
  long l = System.currentTimeMillis();
  
  String invocacion=invocation.getTarget().getClass().getSimpleName()+"."+invocation.getMethod().getName()+"()";
  System.out.println("INICIANDO: "+invocacion);
  
  Object o = invocation.proceed();
  long ll = System.currentTimeMillis();
  
  System.out.println("FINALIZANDO: "+invocacion+" Tiempo total: "+(ll-l)+" milisegundos");
  
  return o;
  }
  return invocation.proceed();
  }
  
  }
  
2. Cambiar en el ejb-jar.xml el interceptor de seam por el nuestro
• <?xml version="1.0" encoding="UTF-8"?>
  <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
  version="3.0">
  <interceptors>
  <interceptor>
  <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
  </interceptor>
  <interceptor>
  <interceptor-class>es.miao.MiaoInterceptor</interceptor-class>
  </interceptor>
  </interceptors>
  <assembly-descriptor>
  <interceptor-binding>
  <ejb-name>*</ejb-name>
  <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
  </interceptor-binding>
  <interceptor-binding>
  <ejb-name>*</ejb-name>
  <interceptor-class>es.miao.MiaoInterceptor</interceptor-class>
  </interceptor-binding>
  </assembly-descriptor>
  </ejb-jar>
  

InstantiationException: Configurar intelli jidea para correr pruebas de seam

Un problema es que el seam necesita que en el directorio donde se copian todos los recursos empleados exista el security.drl, y esto se hace settings>compiler>resource patterns e incluir ?*.drl;

además hay que copiar persistence-text.xml a persistence.xml, esto lo hace el archivo ant del seam, pero hay que indicarselo al intellijidea. se puede hacer configurando la prueba para que corra una tarea ant antes de arrancar.

Alta de autonomo en epigrafe de programador en sevilla

Hacienda al lado de la casa de la moneda
La seguridad social en calle castelar mapa

1. darse de alta en el IAE (Impuesto de actividades económicas)
• Mostrador 16 pedir modelo 036
• pedir número para declaración censal
• entregar modelo cumplimentado
• epigrafe 762 Programador
2. ir a la seguridad social
• fotocopiar el 036 sellado
• llevar el numero de cuenta para domiciliación
• llevar el número de la seguridad social
• el epigrafe en seguridad social es el 72210:Edición de programas
  

jbpm en seam

primer ejemplo a seguir el numberguess example de seam aunque también está el dvd-store

hay que definir el componente de la definición del proceso en el components.xml:

<component class="org.jboss.seam.core.Jbpm">
<property name="pageflowDefinitions">
<value>pageflow.jpdl.xml</value>
<value>cheat.jpdl.xml</value>
</property>
</component>


y posteriormente la definición del proceso en este caso de cheat.jpdl

<pageflow-definition xmlns="http://jboss.com/products/seam/pageflow"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-1.2.xsd"
name="cheat">

<start-page name="confirm" view-id="/confirm.jspx">
<transition name="yes" to="cheat">
<action expression="#{numberGuess.cheated}"/>
</transition>
<transition name="no" to="end"/>
</start-page>

<page name="cheat" view-id="/cheat.jspx">
<redirect/>
<transition to="end"/>
</page>

<page name="end" view-id="/numberGuess.jspx">
<redirect/>
<end-conversation/>
</page>

</pageflow-definition>


y en el pages.xml arrancamos el pageflow

<pages>
<page view-id="/numberGuess.jspx">
<begin-conversation join="true" pageflow="numberGuess"/>
</page>
<page view-id="/confirm.jspx">
<begin-conversation nested="true" pageflow="cheat"/>
</page>
</pages>

aunque también se puede arrancar desde el componente

@Create
@Begin(pageflow="numberGuess")
public void begin(){
...

}

pages.xml navegacion

Entre las razones de elegir el pages.xml para definir la navegación se encuentran:

1. la posibilidad de especificar valores del request en la redirección
2. comenzar o acabar una conversación desde la evaluación de una regla
3. avaluar cualquier expressión de tipo EL
   

Para ver el empleo del pages.xml se puede ojear lo que produce el seam-jems generate-entities



Utilizar reglas de navegacion con pages.xml

lo que en faces-config.xml se escribiría así:

<navigation-rule>
<from-view-id>/editDocument.xhtml</from-view-id>
<navigation-case>
<from-action>#{documentEditor.update}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/viewDocument.xhtml</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>

lo que en pages.xml quedaría así:

<pageview-id="/editDocument.xhtml">
<navigationfrom-action="#{documentEditor.update}"
evaluate="#{documentEditor.errors.size}">
<ruleif-outcome="0">
<redirectview-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page>

o incluso

<pageview-id="/editDocument.xhtml">
<navigationfrom-action="#{documentEditor.update}">
<ruleif="#{documentEditor.errors.empty}">
<redirectview-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page>

Gestión de errores en Seam

Con la etiqueta "restrict" me parece que se produce una redirección una vez que se salva la condición?

Ejemplo de Seam util para investigar: blog, en este no se recoge la excepción en el pages.xml, unicamente la clase de excepción EntryNotFoundException tiene las etiquetas:
@ApplicationException(rollback=true)
@HttpError(errorCode=HttpServletResponse.SC_NOT_FOUND)
y entonces y con el web.xml:

<error-page>
<error-code>404</error-code>
<location>/seam/404.xhtml</location>
</error-page>

directamente busca el 404.xhtml

Las excepciones heredan de RuntimeException y se producen en la invocación de un metodo jsf, es decir metodo público que no devuelve nada.
ejemplo metodo jsf que lanza excepción:
public void buscar(){
....
thrown new RuntimeException("algo ha fallado");
....
}

ademas se pueden producir a través del pages.xml con la etiqueta "restrict" o con "action" dentro de "page"

<page view-id="/gestion/*">
<restrict>#{authenticator.admin}</restrict>
</page>

<exception class="es.miao.MiaoExcepcion">
<redirect view-id="/error.xhtml">
<message>ha funcionado la runtime exception</message>
</redirect>
</exception>


Se supone que al entrar en cualquier pagina que se corresponda con el patrón "/gestion/*" es decir todas aquellas que se encuentren en la carpeta gestion, serán restringidas a que el componente authenticator responda afirmativamente al metodo isAdmin().
De lo contrario la etiqueta restrict se encarga de llevar a la página de error correspondiente.

<exception class="org.jboss.seam.security.NotLoggedInException">
<redirect view-id="/login.xhtml">
<message>#{messages.masInfo}</message>
</redirect>
</exception>

Con "restrict" es el componente Identity el que se encarga de evaluar la expressión y lanzar la correspondiente excepción, también podríamos obtener una excepción de la etiqueta "action"
<action execute="#{catalogoAction.disminuye}" />

Se supone que las acciones jsf no devuelven nada como resultado return void. Sin embargo la etiqueta restrict espera un boolean [boolean isAdmin(), ó , boolean isChecked()]