Mensajes

Código (css) [Seleccionar] Expandir

.menu {
    box-shadow: 0 5px 8px rgba(0,0,0,.1);
}
.menu li {
    display: inline-block;
}
.menu a {
    border: none;
    color: #444;
    display: block;
    font-size: .85rem;
    padding: .5rem .65rem;
    text-align: center;
    text-decoration: none;
    text-transform: uppercase;
    transition: all .2s ease-in;
}
.menu a:hover {
    color: #00bbff; /* cambia por el celeste de la imagen */
}

Te recomiendo primero que aprendas éstas cosas básicas antes de querer estilizar toda una web.

Los estándares siempre han sido beneficiosos (véase ISO por ejemplo). Para hacer lo que deseas, tendría que estar detrás una comunidad, una ONG. Por ejemplo, cada vez que se deseen hacer cambios a los formatos estándares, se forma un grupo de expertos, hace el borrador, presenta su justificación, se vota y si se ve necesario y útil, se lleva a cabo la nueva especificación o actualización.

Desde un punto de vista, sería bueno compartir formatos y que algunos no sean privativos ¬¬.

Dimitrix y sus temas amorosos xD. Cuando tienes pareja, debes cambiar ciertas cosas porque la situación cambia. Ahora, necesitas ser consciente y saber diferenciar que situaciones deberias compartir con tu pareja y que situaciones deberias compartir con tus amigas.

Un viaje en donde es muy probable que vayas a pasar momentos cool, ¿con quien crees que es ideal pasarlos?

Yo no le veo la gracia. Esotérico, paranormal, fastasmas, ets, demonios, son todas creencias de la gente que está en todo su derecho de tener. Siempre hay que burlarse de creencias ajenas, ¿cierto?

Respecto a la noticia, es muy interesante y preocupante. La produccion de alimento y materia prima se vera seriamente afectada; esperemos sea una glaciación parcial y que no afecte a todo el orbe.

[CDI]

CDI

Context and Dependency Injection o Contexto e inyección de depencias en español, es un poderoso elemento de la plataforma Java EE el cual nos provee un poderoso mecanismo de inyección de depencias. Además, nos provee de muchas utilidades, como interceptores, calificadores, eventos, decoradores, productores y trituradores, entre otros.

CDI es un concepto incomprendido por gran parte de los programadores Java EE. En el presente documento, intentaremos despejarnos las dudas. Empecemos.


Dependency Injection

Dependency Injection (DI) es un patrón de diseño que desacopla componentes depenientes. Es parte de inversion of control (IoC) donde el objetivo que es invertido es el proceso de obtención de dependencias necesarias. El término fue originalmente dicho por Martin Fowler. Una manera de pensar en DI en un entorno manejado como Java EE es pensar en JNDI al revés. En lugar que un objeto busque por otros, el contenedor inyecta su dependencia por ti. Esto es llamado Principio Hollywood, "Don't call us (buscar objetos), we'll call you (inyectar objetos)".


Gestión del ciclo de vida

El ciclo de vid de un POJO es muy simple, creas una instancia de una clase usando la palabra reservada new y esperas a la recolección de basura para que la elimine y libere algo de memoria. En su lugar, necesitas inyectar el bean y el contenedor hace el resto, esto quiere decir que el contenedor es el único responsable de gestionar el ciclo de vida de un bean: este lo crea, este lo destruye. Así que, ¿como inicializas un bean si tu no llamas a un constructor? El contenedor te brinda un manejo luego de construir la instancia y antes de destruirla. Estas anotaciones son:

• @PostConstruct: un método anotado con esta anotación es llamado inmediatamente después que el contenedor haya inyectado el bean (instanciado).
• @PreDestroy: un método anotado con esta anotación es llamado justo antes que el recolector de basura elimine el bean.

CDI Bean

Un bean CDI puede ser cualquier tipo de clase que contenga lógica de negocio. Este puede ser llamado directamente por código Java vía inyección o puede ser invocado vía El desde una página JSF. Un bean es un POJO que no extiende de nada, puede inyectar referencias en otros beans (@Inject), tiene su ciclo de vida manejado por el contenedor y puede tener sus propios metodos incerptores:

Código (java) [Seleccionar] Expandir

public class BankLoan {
    @Inject
    private AccountChecker accountChecker;
    private Date dateOfLoan;

    @PostConstruct
    private void initializeDate() {
        dateOfLoan = new Date();
    }
}

En el ejemplo anterior, se está inyectando la dependencia del bean accountChecker, esto lo hace el contenedor. El método initializeDate anotado con @PostConstruct será llamado automáticamente luego de que se instancie la clase BankLoan. Los CDI beans tienen ciertas características que deben cumplirse de manera obligatoria. Estas son:

• No debe ser una interna no estática.
  
• Tiene un constructor por defecto sin parámetros o debe declarar un constructor anotando @Inject.
  
• Es una clase concreta (no debe extender) o  es anotada con @Decorator
  
  Para mayor comprensión, veamos el siguiente diagrama de clases:
  
  
  
  
  ¿Cómo conectamos CDStore y CreditCard? La forma que todos conocemos es mediante el operador new:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStore {
    private CreditCard creditCard;
   
    public CDStore() {
        creditCard = new Visa();
    }
    public void buyItems() {
        // pagar con la tarjeta
  creditCard.pay();
    }
}
  
  El código anterior es bien simple  y es lo que nosotros hacemos y conocemos. Pero, ¿que pasaría si quisieras pagar con MasterCard?, ¿Necesitarías crear una (otra) instancia de MasterCard? Una solución pasar su dependencia por medio del constructor de una clase externa que haga uso de la clase CDStore:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStore {
    private CreditCard creditCard;

    public CDStore(CreditCard creditCard) {
        this.creditCard = creditCard;
    }
    ...
}
  
  En otra clase:
  
  
  Código (java) [Seleccionar] Expandir
  CDStore cdStore = new CDStore(new MasterCard());
  
  Ésto es lo que se conoce como inversion of control (IoC) o inversión de control (en español). La dependencia se inyecta desde una tercera clase, de ésta manera no creamos un vínculo entre CDStore y CreditCard.
  
  Inyección (@Inject)
  
  Java EE es un entorno gestionado, así que quizás no necesitas construir las dependencias tú mismo, en su lugar, puedes dejar que el contenedor inyecte las dependencias de los beans por tí. CDI tiene la habilidad de inyectar dependencias de prácticamente lo que sea. Veamos un ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStore {
    @Inject
    private CreditCard creditCard;
   
    public void buyItems() {
        creditCard.pay();
    }
    ...
}
  
  Como se puede observar, no necesitamos construir la dependencia de creditCard, se lo dejamos al contenedor. La implementación se vería así:
  
  
  Código (java) [Seleccionar] Expandir
  public class Visa implements CreditCard {
    @Override
    public void pay() {
         // logica de negocio
    }
}
  
  Nota que solo hemos especificado una implementación de la interface CreditCard. Si hubiéramos creado otra implementación, la inyección no se podría realizar porque el contenedor no sabría qué dependencia inyectar. Esto, lo resolveremos más adelante con calificadores (@Qualifier).
  
  
  
  ANEXO
  
  Puntos de inyección
  
  Una inyección puede llevarse a cabo en tres puntos:
  
  
• Por propiedad:
  
     
  Código (java) [Seleccionar] Expandir
  @Inject
private CreditCard creditCard;
  
     Nota que no es necesario especificar setter para la propiedad.
  
• Por constructor:
  
     
  Código (java) [Seleccionar] Expandir
  @Inject
         private CDStore (CreditCard creditCard) {
             this.creditCard = creditCard;
        }
  
     La regla aquí es que la inyección por constructor se puede realizar solo una vez (por    clase).
  
  
• Por setter:
     
  Código (java) [Seleccionar] Expandir
  @Inject
        public void setCreditCard(CreditCard creditCard) {
            this.creditCard = creditCard;
        }
  
  
  Ésto es un anexo, porque en realidad no importa en qué punto hagas la inyección. Por propiedad, constructor o setter, para el contenedor le da igual. Por lo tanto, escoger uno u otro, es simplemente opción personal.
  
  
  
  Injección por defecto (@Default)
  
  Tu puedes tener una dependencia para inyectar por defecto. Por ejemplo, nosotros tenemos solo una implementación, aquella, tendrá implícitamente el modificador @Default. Así, ésto:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject
private CreditCard creditCard;
  
  Es igual que:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject @Default
private CreditCard creditCard;
  
  Podemos apreciarlo en una imagen:
  
  
  
  
  Si tienes una implementación, el contenedor inyectará la única dependencia existente. Si por otro lado, tienes muchas implementaciones de una interface, el contenedor no sabrá cuál implementación debe inyectar, y aquí es cuando toman tanta importancia los calificadores.
  
  
  Calificadores (@Qualifier)
  
  Cuando el sistema inicia, el contenedor CDI debe validar que todos los beans satisfasgan cada punto de inyección existente. Si alguna dependencia de un bean no puede ser satisfecha por el contenedor CDI, entonces la aplicación no se podrá desplegar informando de una insatisfacción de dependencia. Si hay una sola implementación disponible, la inyección funcionará aplicando la dependencia única, que es marcada implícitamente con @Default.
  
  Si hay más de usa implementación y tratamos de desplegar, la aplicación no desplegará porque dectectará ambiguación en las dependencias, es decir, si hay 2 o más implementaciones, ¿cómo sabe el contenedor qué dependencia inyectar? Aquí es donde toman importancia los calificadores. Veamos el siguiente diagrama de clases que ilustra la situación actual:
  
  
  
  
  Podemos ver que hemos creado una nueva implementación, llamada MasterCard, la misma está anotada bajo el calificador MasterCardPay. Además, vemos como una nueva clase, CDStoreWithQualifier inyecta la nueva dependencia. Esto lo hará mediante el calificador. Veamos el ejemplo en código (solo las nuevas clases):
  
  Calificador MasterCardPay:
  
  
  Código (java) [Seleccionar] Expandir
  @Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, PARAMETER, METHOD})
public @interface MasterCardPay {}
  
  Implementación MasterCard:
  
  
  Código (java) [Seleccionar] Expandir
  @MasterCardPay
public class MasterCard implements CreditCard {
    private Logger logger = Logger.getLogger(MasterCard.class.getName());
   
    @Override
    public void pay() {
        logger.log(Level.INFO, "Pagando con MasterCard");
    }
}
  
  La anotación @Retention, especifica el nivel de retención de la anotación. Existen 3 tipos:
  
  
• SOURCE: la anotación será visible en el código fuente, una vez que se compila la aplicación, es descartada. La anotación no será escrita en bytecode. Por ejemplo, @Override.
  
• CLASS: La anotación se descarta durante la carga de la clase por parte del ClassLoader. Sí se escribe en bytecode.
  
• RUTNIME: No se descarta. Ésta anotación estará siempre disponible por reflection en tiempo de ejecución.
  
  Las primeras dos anotaciones no podrán ser inspeccionadas en tiempo de ejecución, mientras que la última sí. Esta es la diferencia entre las 3.
  La anotación @Target, especifica que elementos podrán ser afectados por la anotación. Hay varias opciones:
  
  
• ElementType.ANNOTATION_TYPE
  
• ElementType.CONSTRUCTOR
  
• ElementType.FIELD
  
• ElementType.LOCAL_VARIABLE
  
• ElementType.METHOD
  
• ElementType.PACKAGE
  
• ElementType.PARAMETER
  
• ElementType.TYPE
  
  Creo que la mayoría se explican solas. Las dos anotaciones que son un poco confusas son ANNOTATION_TYPE y TYPE. ANNOTATION_TYPE significa que la anotación solo podrá ser usada para anotar otras anotaciones, como @Retention. TYPE significa cualquier tipo de elemento (clases, interfaces, enums, anotaciones, etc).
  
  Comprendidos ya estos conceptos, vamos a ver la clase que inyecta la nueva implementación:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDStoreWithQualifier {
    @Inject @MasterCardPay
    private CreditCard masterCard;
   
    public void buyItems() {
        masterCard.pay();
    }
}
  
  Observa lo sencillo que es inyectar múltiples dependencias, solo basta con indicar el calificador de la dependencia que debe ser inyectada. Es posible también anotar un elemento con múltiples anotaciones. Java no nos limita en este aspecto. Por ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject @Visa @Gold
private CreditCard creditCard;
  
  
  Productores (@Produces)
  
  Como ya hemos visto, podemos inyectar CDI beans dentro de otros CDI beans. Pero, si quisiéramos inyectar POJOs, o tipo de datos primitivos, ¿sería eso posible? La respuesta corta es no y la razón es la siguiente.
  
  Por defecto, no puedes inyectar clases como String o Date y la razón, es porque ellas están empaquetadas en el archivo rt.jar (Java runtime enviroment classes) y este no contiene un descriptor de beans beans.xml. Esto es importante tenerlo presente, si un archivo no tiene un descriptor beans.xml bajo el directorio META-INF, CDI no activará el descrubimiento de beans (bean discovery) y los POJOs no podrán ser tratados como beans y por ende, no podrán ser inyectados. Afortunadamente, podemos revertir esta situación con ayuda de los productores. Veamos un ejemplo:
  
  
  
  
  Veamos que la clase CDSerialProducer tiene 3 anotaciones, las cuales pasamos a describir:
  
  
• @Produces: utilizada para producir un bean listo para inyección.
  
• @CDSerialPrefix: anotación propia.
  
• @RandomNumber: anotación propia.
  
  Primer veamos nuestras anotaciones, serán igual que los calificadores que ya hemos visto:
  
  
  Código (java) [Seleccionar] Expandir
  @Retention(RUNTIME)
@Target({FIELD, TYPE, PARAMETER, METHOD})
public @interface CDSerialPrefix { }
  
  
  Código (java) [Seleccionar] Expandir
  @Retention(RUNTIME)
@Target({FIELD, TYPE, PARAMETER, METHOD})
public @interface RandomNumber { }
  
  Ahora, veamos como producimos beans para inyectar de tipo String e int:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDSerialProducer {
    @Produces @CDSerialPrefix
    private final String prefix = "T9-SK534";
   
    @Produces @RandomNumber
    public int generateNumber() {
        return new Random().nextInt(10000);
    }
}
  
  La anotación @Produces, producirá una propiedad y un método para inyectar. Seguido de @Produces, debemos de especificar el calificador con el cual se va a inyectar la propiedad y el método. En este caso son @CDSerialPrefix y @RandomNumber. Ahora veamos como los inyectamos:
  
  
  Código (java) [Seleccionar] Expandir
  public class CDService {
    @Inject @CDSerialPrefix
    private String prefix;
    @Inject @RandomNumber
    private int number;
    private Logger logger = Logger.getLogger(getClass().getName());
   
    public void createCD() {
        logger.log(Level.INFO, "Creando CD con serial: {0}", (prefix + number));
    }
}
  
  Si ejecutamos el proyecto, podemos ver que se inyectan satisfactoriamente los valores de la propiedad y el método dentro de las propiedades de CDService. Gracias a los productores, podemos inyectar prácticamente lo que sea.
  
  
  
  ANEXO
  
  API de InjectionPoint
  
  Los atributos y propidades producidad por productores (@Produces) no necesitan saber ningún tipo de información acerca de donde ellos son inyectados. Sin embargo, hay ciertos casos  donde podría ser de utilidad que el bean a inyectar sepa en qué punto de inyección se ha llevado a cabo la inyección. Un ejemplo común de ésto, es generar una dependencia dinámica de Logger (para crear logs). Generalmente, siempre creamos un Logger así:
  
  
  Código (java) [Seleccionar] Expandir
  Logger logger = Logger.getLogger(TuClase.class.getName());
  
  Lo anterior funciona correctamente, pero también podríamos generar depenencias dinámicamente. Veamos primero la API de InyectionPoint:
  
  
  
  
  Podemos usar esta API para generar una dependencia dinámica para Logger. Veamos un ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  public class LoggerProducer {
    @Produces
    private Logger createLogger(InyectionPoint ip) {
        return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
    }
}
  
  Perfecto. Ahora tan solo debemos inyectar al logger de ésta manera:
  
  
  Código (java) [Seleccionar] Expandir
  @Inject Logger log;
  
  ¿Cómo ocurre la magia? Bien, el contenedor CDI buscará cualquier bean de tipo Logger listo para inyectar, y lo encuentra gracias a que hemos anotado el método con @Produces, lo que deja ese método listo para su inyección (como con @CDSerialPrefix y @RandomNumber del ejemplo anterior).
  
  
  
  
  Trituradores (@Disposes)
  
  Ahora sabemos como producir beans o valores para inyectar, pero algunos beans podrían necesitar ser cerrados, como es el caso de conexiones JDBC o un EntityManager. Por lo tanto, algunos beans producidos deberían asegurarse de ser cerrados. Aquí es donde toman importancia los Disposers. Los Disposers son lo  contrario a Producers, éste último crea beans o valores para inyectar, mientras que el primero se encarga de destruirlo.
  Veamos un ejemplo con una clásica conexión JDBC:
  
  
  Código (java) [Seleccionar] Expandir
  public class DerbyJdbcProducer {
    private final static String DRIVER = "org.apache.derby.jdbc.EmbeddedDriver";
    private final static String URL = "jdbc:derby://localhost:1527/CDI";
    private final static String USER = "duke";
    private final static String PASS = "1234";
    @Inject
    private Logger logger;
   
    @Produces
    public Connection createConnection() {
        Connection con = null;
        try {
            Class.forName(DRIVER).newInstance();
            con = DriverManager.getConnection(URL, USER, PASS);
            logger.log(Level.INFO, "Creando conexión JDBC con Derby");
        } catch(InstantiationException | IllegalAccessException |
                ClassNotFoundException | SQLException e) {
            e.printStackTrace();
        }
        return con;
    }
    public void closeConnection(@Disposes Connection con) {
        try {
            con.close();
            logger.log(Level.INFO, "Cerrando conexión JDBC con Derby");
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}
  
  Un método disposer debe obligatoriamente recibir un parámetro @Disposes y el tipo del parámetro debe ser el mismo que el tipo devuelto con el método productor (@Produces) y su calificador (@Qualifier) en caso haya más métodos productores con el mismo tipo de retorno. Dado que el ciclo de vida de un bean inyectado depende del contexto en donde se inyecta, cuando se elimina el bean que contiene el bean inyectado, éste se destruirá también. Pero si no hubiésemos escrito el método disposer, la conexión nunca se hubiese cerrado por ser ésta independiente del contexto. Cuando el bean que contiene el bean inyectado es eliminado, antes que eso ocurra, se ejecutará el método disposer del bean inyectado, en este caso, cerrando la conexión JDBC.
  
  
  
  ANEXO
  
  Alcances (scopes)
  
  Todo objeto cuyo ciclo de vida es manejado por CDI tiene un alcance definido y un ciclo de vida que está ligado a un contexto específico. En Java, el alcance de un POJO es muy simple: tu creas una instancia de una clase usando la palabra reservada new y tu confías en el recolección de basura para deshacerse  de él y liberar alguna memoria. Con CDI, un bean es ligado al contexto y este lo mantiene en ese contexto hasta que el bean es destruido por el contenedor. No hay manera para remover manualmente un bean desde un contexto.
  
  CDI define los siguientes alcances y permite puntos de extesión para crear tu propio alcance:
  
  
• Application scope(@ApplicationScoped): Se extiende por la duración entera de una aplicación. El bean es creado solo una vez por duración de la aplicación y es descartado cuando la aplicación se apaga. Este alcance es util para cases utilitarias o helpers, u objetos que guardan datos compartidos por la aplicación entera (pero deberías ser cuidadoso con los problemas de concurrencia cuando los datos tienen que ser accesados por muchos threads).
  
  
• Session scope(@SessionScoped): Se extiene a través de muchas peticiones HTTP o muchas invocaciones de métodos por una sola sesión de usuario. El bean es creado por la duración de una sesión HTTP y es descartado cuando la sesión termina. Este ámbito es para objectos que son necesarios a lo largo de la sesión como preferencias de usuario o credenciales de login.
  
  
• Request scope(@RequestScoped): Corresponde a una simple petición HTTP o a una invocación de un método. El bean es creado para la duración de una invocación a un métod y es descartado cuando el método termina. Esto es usado para clases de servicio o beans JSF que son solo necesitados durante la duración de una petición HTTP.
  
  
• Conversation scope(@ConversationScoped): Se extiende entre múltiples invocaciones dentro de los límites de una sesión con puntos de inicio y fin determinados por la aplicación. Este alcance es usado a través de múltiples páginas como parte de un flujo de trabajo de múltiplos pasos.
  
  
• Dependent pseudo-scope(@Dependent): El ciclo de vida es el mismo que del cliente. Un bean @Dependent es creado cada vez que este es injectado y la referencia es eliminada cuando el objetivo de la inyección es eliminado. Éste es el alcance por defecto para CDI.
  
  Como puedes ver, todos los alcances tienen una anotación que tu puedes usar en tus beans CDI (todas ellas están en el paquete javax.enterprise.context). Los primeros tres alcances son bien conocidos. Por ejemplo, si tu tienes un bean de alcance de sesión como de un carro de compras, el bean será automáticamente creado cuando la sesión inicia (primera vez que un usuario se loguea) y es  destruido automáticamente cuando la sesión termina.
  
  

  Notas: El ciclo de vida de un bean @Dependent está ligado al ciclo de vida del bean que lo contiene. Se crea cuando el bean que lo contiene es instanciado y es eliminado cuando el mismo es eliminado. Es el scope por defecto.

  
  
  Conversation (@ConversationScoped)
  
  El alcande conversation es un poco diferente al resto. Este alcance mantiene estados asociados en un intérvalo de tiempo, a través de múltiples peticiones y es eliminado programáticamente (explícitamente) por la aplicación. Este alcance es usado mayormente en procesos  donde se requiere mantener valores durante múltiples peticiones HTTP pero sin extenderse demasiado, como un alcance @SessionScoped.
  
  API de Conversation:
  
  
  
  
  La principal diferencia con otros alcances, es que ellos son eliminados automáticamente por el contenedor al cabo de un tiempo cuando termina la petición, sesión, aplicación, etc. En Conversation, nosotros debemos encargarnos terminar su ciclo de vida. Por ejemplo, un bean @ConversationScoped puede ser usado para un asistence de registro de usuario. Deseamos mantener los datos que se van registrando del usuario a través de distintas páginas y que elimine el bean al terminar el registro:
  
  
  Código (java) [Seleccionar] Expandir
  @Named
@ConversationScoped
public class UserRegistrationWizard implements Serializable {
    @Inject
    private Conversation conversation;
    @Inject
    private User user;
    @Inject
    private transient Logger logger;
   
    @PostConstruct
    public void init() {
        conversation.begin();
    }
    public User getUser() {
        return user;
    }
    public void register() {
        conversation.end();
        logger.log(Level.INFO, "Usuario registrado:");
        logger.log(Level.INFO, "Email: {0}", user.getEmail());
        logger.log(Level.INFO, "Password: {0}", user.getPassword());
        logger.log(Level.INFO, "Fecha Nacimiento: {0}", user.getBirthDate());
    }
}
  
  Para probarlo, crea distintas páginas JSF y en cada una pon un formulario con un input text para el email, un input secret para el password y un input text para la fecha de cumpleaños:
  
  start.xhtml
  
  
  Código (html5) [Seleccionar] Expandir
  <h3>Inicio de registro</h3>
        <h:form>
            <h:outputLabel for="email" value="Email:"/>
            <h:inputText id="email" value="#{userRegistrationWizard.user.email}"/>
            <h:commandButton value="Siguiente" action="step2"/>
        </h:form>
  
  step2.xhtml
  
  
  Código (html5) [Seleccionar] Expandir
  <h3>Paso 2</h3>
        <h:form>
            <h:outputLabel for="password" value="Contraseña"/>
            <h:inputSecret id="password" value="#{userRegistrationWizard.user.password}"/>
            <h:commandButton value="Siguiente" action="end"/>
        </h:form>
  
  end.xhtml
  
  
  Código (html5) [Seleccionar] Expandir
  <h3>Paso 3</h3>
        <h:form>
            <h:outputLabel for="birthDate" value="F. Nacimiento:"/>
            <h:inputText id="birthDate" value="#{userRegistrationWizard.user.birthDate}">
                <f:convertDateTime pattern="dd-MM-yyyy"/>
            </h:inputText>
            <h:commandButton value="Registrar" action="#{userRegistrationWizard.register()}">
                <f:ajax execute="@form" />
            </h:commandButton>
        </h:form>
  
  Al llegar a la últma página y pulsar el botón registrar, se ejecuta el método registrar(), donde termina la conversación y se imprime toda la información del usuario recolectada durante la misma.
  
  
  Interceptores (@Interceptor)
  
  Los interceptores te permiten agregar conceptos a través de tus beans. Cuando un cliente invoca a un método en un Managed Bean (y por lo tanto a CDI beans, EJB, RESTful, ...), el contenedor puede interceptar la invocación y procesar lógica de negocio antes que el método del bean sea invocado. Los interceptores vienen en cuatro tipos:
  
  
• Interceptores a nivel de constructor: el interceptor es asociado con un constructor de la clase objetivo (@AroundConstruct)
  
• Interceptores a nivel  de método: el interceptor es asociado con un método de negocio específico (@AroundInovke)
  
• Interceptores por tiempo límite: el interceptor se interpone en el tiempo límite de los métodos (@AroundTimeout (usado solo con EJB timer)
  
• Interceptores de ciclo de vida: el interceptor se interpone en las llamadas de eventos del ciclo de vida del objetivo (@PostConstruct y @PreDestroy).
  
  Un método anotado con @AroundInvoke, debe tener el siguiete patrón de firma:
  
  
  Código (java) [Seleccionar] Expandir
  @AroundInvoke
Object <Método> (InvocationContext ic) throws Exception;
  
  Las siguientes reglas aplican a un método @AroundInvoke:
  
  
• El método puede tener cualquier modificador de visibilidad pero no debe ser static o final.
  
• El método debe tener un parámeto InvocationContext y debe retornar Object, el cual es el resultado del método objetivo invocado.
  
• El método debe lanzar una excepción comprobada.
  
• El objeto InvocationContext permite a los interceptores controlar el comportamiento de la cadena de invocaciones. Si muchos interceptores son encadenados, la misma instancia de InvocationContext es pasada a cada interceptor, quien puede agregar datos contextuales para ser procesador por otros interceptores.
  
  Echememosle un ojo a la API de InvocationContext:
  
  
  
  
  Otra forma de trabajar con interceptores, es que estos pueden estar en una clase y luego ser referenciada por la clase que los necesite:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(MisInterceptores.class)
public class MiClase { ... }
  
  O en algún método:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(MisInterceptores.class)
public void doSomething() { ... }
  
  Si queremos que un método no sea interceptado, lo anotamos con @ExcludeClassInterceptors.
  
  Veamos un ejemplo:
  
  
  
  
  Vamos con nuestro interceptor:
  
  
  Código (java) [Seleccionar] Expandir
  public class LoginInterceptor {
    private @Inject Logger logger;

    @AroundConstruct
    private Object init(InvocationContext ic) throws Exception {
        logger.log(Level.INFO, "--- ConstructInterceptor ---");
        logger.log(Level.INFO, "Entrando al constructor");
        try {
            return ic.proceed();
        } finally {
            logger.log(Level.INFO, "Saliendo del constructor");
        }
    }
    @AroundInvoke
    private Object interceptMethod(InvocationContext ic) throws Exception {
        logger.entering(ic.getTarget().toString(), ic.getMethod().getName());
        try {
            logger.log(Level.INFO, "método interceptado");
            return ic.proceed();
        } finally {
            logger.exiting(ic.getTarget().toString(), ic.getMethod().getName());
        }
    }   
}
  
  Y nuestra clase que se verá afectada por nuestro inteceptor:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(LoginInterceptor.class)
public class LoginService {
    private @Inject Logger logger;
   
    public void login() {
        logger.log(Level.INFO, "Haciendo login");
    }
}
  
  Cuando se instancie ésta clase y cuando llamemos al método login(), se ejecutarán los interceptores que hemos definido en LoginInterceptor, que son uno a nivel de método y otro a nivel de constructor.
  
  

  También se pueden proporcionar más de un interceptor, deben separarse por comas:

  
  
  Código (java) [Seleccionar] Expandir
  @Interceptors(LoginInterceptor.class, AccountcheckerInterceptor.class)
public class LoginService { ... }
  
  Los interceptores serán ejecutados en el orden que son escritos.
  
  
  Vinculación de interceptores (@InterceptorBinding)
  
  Una manera más práctica y que es la más aconsejada por su bajo acoplamiento, es Interceptor Binding. Es muy fácil de hacer, solo basta crear un Interceptor Binding que es muy parecido a un calificador:
  
  
  Código (java) [Seleccionar] Expandir
  @InterceptorBinding
@Retention(RUNTIME)
@Target({METHOD, TYPE})
public @interface Loggable { }
  
  El interceptor cambia muy poco, solo debemos anotar con @Interceptor y el interceptor binding que hemos creado, en nuestro caso, @Loggable:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptor
@Loggable
public class LoginInterceptorBinding { ... }
  
  Ahora, en nuestra clase objetivo (donde se interceptarán los métodos), solo debemos anotar la clase o los métodos/constructor que queremos interceptar. Por ejemplo:
  
  
  Código (java) [Seleccionar] Expandir
  public class LoginServiceBinding {
    @Loggable
    public void Login() {
        ...
    }
}
  
  Como se puede observar, es mucho más práctico de esta forma y además, más agradable a la vista. Para poder utilizar ésta manera, debemos de agregar nuestro interceptor binding en el descriptor de beans (beans.xml):
  
  
  Código (xml) [Seleccionar] Expandir
  <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
       http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="all">
    <interceptors>
        <class>com.acme.interceptors.binding.LoginInterceptorBinding</class>
    </interceptors>
</beans>
  
  Prioridad de interceptores
  
  Los interceptores sigue el orden en el que los hemos escrito en la clase interceptada, pero podemos crear nuestro propio orden. Por ejemplo, tenemos dos interceptores con prioridad diferente:
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptor
@CdDisponibility
@Priority(200)
public class CdDisponibilityInterceptor {
    @Inject
    private Logger logger;
   
    @AroundInvoke
    public Object checkCdDisponibility(InvocationContext ic) throws Exception {
        try {
            logger.log(Level.INFO, "Ejecuando método interceptor checkCdDisponibility");
            return ic.proceed();
        } finally {
            logger.log(Level.INFO, "Terminando ejecución método interceptor checkCdDisponibility");
        }
    }
}
  
  
  Código (java) [Seleccionar] Expandir
  @Interceptor
@DvdDisponibility
@Priority(300)
public class DvdDisponibilityInterceptor {
    @Inject
    private Logger logger;
   
    @AroundInvoke
    public Object checkDvdDisponibility(InvocationContext ic) throws Exception {
        try {
            logger.log(Level.INFO, "Ejecutando método interceptor checkDvdDisponibility");
            return ic.proceed();
        } finally {
            logger.log(Level.INFO, "Terminando ejecución del método interceptor checkDvdDisponibility");
        }
    }
}
  
  Ahora, nuestra clase interceptada:
  
  
  Código (java) [Seleccionar] Expandir
  @CdDisponibility @DvdDisponibility
public class SellService {
    public void checkDisponibility() {
        ...
    }
}
  
  Si ejecutamos, veremos la siguiente salida:
  
  
  Código [Seleccionar] Expandir
  Información:   Ejecuando método interceptor checkCdDisponibility
Información:   Ejecutando método interceptor checkDvdDisponibility
Información:   Terminando ejecución del método interceptor checkDvdDisponibility
Información:   Terminando ejecución método interceptor checkCdDisponibility
  
  Como vemos, el primer interceptor (menor prioridad) se ejecuta primero y el segundo (mayor prioridad), se ejecuta después de éste, pero el segundo termina primero. Luego que termina el interceptor de mayor prioridad, el flujo vuelve hacia el de menor prioridad.
  
  
  Decoradores (@Decorator)
  
  Decorador es un patrón de diseño muy común, originalmente acuñado por Gang of Four (la banda de los cuatro). La idea detrás de este patrón es tomar una clase y envolverla con otra (se dice que esta la decora). De esta manera, cuando tu llamas a una clase decorada, debes pasar a través del decorador antes que alcances la clase objetivo. Los decoradores son usados para añadir lógica a un método.
  
  Tomemos como ejemplo un registro para una tienda de CDs online. Hay la membresía básica, que los permite acceder gratis a 15 CDs. Luego, cuando hay ofertas, viene el decorador que lo que hace es incrementar la cantidad de CDs a 40 (+25 del decorador).
  
  interface Membership
  
  
  Código (java) [Seleccionar] Expandir
  public interface Membership {
    public int freeCDs();
}
  
  Implementación BasicMembership
  
  
  Código (java) [Seleccionar] Expandir
  @Basic
public class BasicMembership implements Membership {
    @Inject
    private Logger logger;
   
    @Override
    public int freeCDs() {
        logger.log(Level.INFO, "[+] Clase BasicMembership");
        logger.log(Level.INFO, "Gratis 15 CDs");
        return 15;
    }
}
  
  @Basic es un calificador, que como ya sabemos sigue ésta anatomía:
  
  
  Código (java) [Seleccionar] Expandir
  @Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface Basic { }
  
  Ahora, veamos nuestro decorador:
  
  Decorador MembershipGiftDecorator
  
  
  Código (java) [Seleccionar] Expandir
  @Decorator
public class MembershipGiftDecorator implements Membership {
    @Inject @Delegate @Basic
    private Membership membership;
    @Inject
    private Logger logger;
   
    public int orderGift() {
        logger.log(Level.INFO, "[+] Clase decoradora para Membership");
        logger.log(Level.INFO, "Regalo momentáneo de 25 CDs");
        return membership.freeCDs() + 25;
    }
    @Override
    public int freeCDs() {
        return orderGift();
    }
}
  
  Lo primero que vemos, es que hemos anotado el decorador con @Decorator. Esta anotación le dirá al contenedor que es decorador. Un decorador debe implementar a la interface de la implementación que quiere decorar, es por eso que el decorador implementa también a Membership. Dentro del decorador, vemos que inyectamos la implementación BasicMempership (@Basic) y la anotamos con @Delegate para indicar que ese bean será decorado. A continuación, sobreescribimos el método de la interface y añadimos la lógica de negocio que deseamos. En nuestro caso, agregar 25 CDs gratis.
  
  Por último hacemos uso del decorador:
  
  
  Código (java) [Seleccionar] Expandir
  @Named
public class MembershipBean {
    @Inject @Basic
    private Membership gift;
   
    public void orderGift() {
        gift.freeCDs();
    }
}
  
  Vemos que NO inyectamos al decorador, si no al bean normal (@Basic). El contenedor se encarga de añadir la lógica del decorador al método del bean. Si ejecutamos, vemos ésta salida:
  
  
  Código [Seleccionar] Expandir
  Información:   [+] Clase decoradora para Membership
Información:   Regalo momentáneo de 25 CDs
Información:   [+] Clase BasicMembership
Información:   Gratis 15 CDs
  
  El orden es porque yo he ejecutado primero la lógica del decorador y al último del bean. Si hubiera sido al revés, el resultado hubiera sido invertido.
  Los decoradores no están activados por defecto en CDI, así que debemos listarlos en el descriptor beans.xml:
  
  
  Código (xml) [Seleccionar] Expandir
  <decorators>
        <class>com.acme.decorator.MembershipGiftDecorator</class>
</decorators>
  
  Eventos
  
  Los eventos permiten a los beans interactuar con sus dependencias en tiempo de no-compilación. Cuando un bean define un evento, otro bean puede disparar el evento e incluso otro bean puede manejar el evento. Los beans pueden estar en paquetes y capas distintos dentro de la aplicación. El esquema que siguen éstos eventos es el observer/observable, de Gand of four.
  
  Los productores de los eventos disparan los eventos usando la interface Event (javax.enterprise.event.Event). Un productor eleva eventos llamando el método fire(), pasando el objeto asociado al evento.
  
  Veamos un ejemplo. En nuestra tienda online de CDs, cada vez que se quiera agregar un ítem al carro, deseamos disparar un evento CDI que envíe el ítem que se desee agregar al método observador addItem y reciba el ítem elegido por el usuario para que se agrege al carro.
  
  Vamos con nuestro bean CDShopCart:
  
  
  Código (java) [Seleccionar] Expandir
  @Named("cdShopCart")
@RequestScoped
public class CDShopCart {
    @Inject
    private Event<CD> cdAddedEvent;
   
    public void addItem2cart() {
        List<String> songs = new ArrayList<>();
        Collections.addAll(songs,
                "The day that never comes",
                "Enter Sandman",
                "The fourth horseman",
                "Whiskey in the jar");
        CD cd = new CD("Metallica", songs);
        cdAddedEvent.fire(cd);
    }
}
  
  Este bean tendrá un alcande de petición (@RequestScoped), es decir que su ciclo de vida será igual al de una petición HTTP. Esto es así porque solo vamos a utilizar este bean para agregar un ítem (CD) al carro. Vemos que hemos definido una propiedad tipo Event que acepta datos tipo CD. Cuando se ejecute el método addItem2cart, se ejecutará el evento CDI y se enviará un bean CD para que sea procesado por el método observador, que lo define la siguiente clase:
  
  
  Código (java) [Seleccionar] Expandir
  @SessionScoped
public class Cart implements Serializable {
    @Inject
    private transient Logger logger;
    private List<CD> items;
   
    @PostConstruct
    public void init() {
        items = new ArrayList<>();
    }
   
    public void addItem(@Observes CD cd) {
        logger.log(Level.INFO, "Nuevo CD añadido al carro");
        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
        logger.log(Level.INFO, "Canciones:");
        for(String song : cd.getSongs()) {
            logger.log(Level.INFO, song);
        }
    }
}
  
  El método addItem() es el método observador. Este método escucha el evento y cuando se lanza lo captura y recibe el objeto asociado con el evento lanzado, en este caso CD. Es conveniente que la entidad CD sea pasivada (implemente Serializable). Además, vemos que el carro de compras está marcado como @SessionScoped ya que el carro de compras estará ligado siempre a la sesión de un usuario.
  
  Para disparar el evento, podemos usar JSF, por ejemplo:
  
  
  Código (html5) [Seleccionar] Expandir
  <h:form>
            <h:commandButton value="Agregar CD al carro" actionListener="#{cdShopCart.addItem2cart()}">
                <f:ajax execute="@form"/>
            </h:commandButton>
        </h:form>
  
  Cuando se haga click en el botón, se ejecutará el método y se lanzará el evento. Si hacemos click, veremos lo siguiente en el log:
  
  
  Código [Seleccionar] Expandir
  Información:   Nuevo CD añadido al carro
Información:   Autor: Metallica
Información:   Canciones:
Información:   The day that never comes
Información:   Enter Sandman
Información:   The fourth horseman
Información:   Whiskey in the jar
  
  Ahora, para hacer más interesante nuestro ejemplo, podemos crear calificadores llamados @Added y @Removed para identificar a cada evento: Agregar y Eliminar. Para esto, debemos hacer unos pequeños cambios:
  
  Debemos cambiar el alcance de CDShopCart de @RequestScoped a @SessionScoped:
  
  
  Código (java) [Seleccionar] Expandir
  @Named("cdShopCart")
@SessionScoped
public class CDShopCart implements Serializable {
    @Inject @Added
    private Event<CD> cdAddedEvent;
    @Inject @Removed
    private Event<CD> cdRemovedEvent;
    @Inject
    private CD cd;
   
    public void addItem2cart() {
        List<String> songs = new ArrayList<>();
        Collections.addAll(songs,
                "The day that never comes",
                "Enter Sandman",
                "The fourth horseman",
                "Whiskey in the jar");
        cd.setAuthor("Metallica");
        cd.setSongs(songs);
        cdAddedEvent.fire(cd);
    }
    public void removeItemFromCart() {
        cdRemovedEvent.fire(cd);
    }
}
  
  Los métodos observadores del carro, se verán así:
  
  
  Código (java) [Seleccionar] Expandir
  public void addItem(@Observes @Added CD cd) {
        logger.log(Level.INFO, "Nuevo CD añadido al carro");
        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
        logger.log(Level.INFO, "Canciones:");
        for(String song : cd.getSongs()) {
            logger.log(Level.INFO, song);
        }
    }
    public void removeItem(@Observes @Removed CD cd) {
        logger.log(Level.INFO, "CD Removido");
        logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
    }
  
  Prestar atención al calificador después de @Observes. Esto identifica al evento disparado, @Added representa un nuevo CD agreado y @Removed eliminará un CD del carro.
  
  Nuestra web, se verá así:
  
  
  Código (html5) [Seleccionar] Expandir
  <h:form>
            <h:commandButton value="Agregar CD al carro" action="#{cdShopCart.addItem2cart()}">
                <f:ajax execute="@form"/>
            </h:commandButton>
            <h:commandButton value="Eliminar CD del carro" action="#{cdShopCart.removeItemFromCart()}">
                <f:ajax execute="@form"/>
            </h:commandButton>
        </h:form>
  
  
  
  
  
  
  Descarga en PDF
  
  https://mega.nz/#!bpBmxSAA!ize0-Dy5Urqh20AP-jH_18mwIEcsjAjQnNNGvRkwiFQ
  
  
  
  Eso es todo lo que quería compatirles acerca de CDI. Es un tema muy importante y que pocos entienden y comprenden cómo funciona. Espero que el presente documento es ayuda a entender un poquito mejor cómo funciona CDI y sus nuevas características.
  
  Nos vemos en otra oportunidad, hasta la próxima.

Eso es porque el puto editor te lo reconoce como cursiva xDDD

Puedes hacerlo con PHP:

Código (php) [Seleccionar] Expandir


$dom = new DOMDocument;
$dom->loadHTMLFile('la_url');
$table = $dom->getElementsByTagName('table')[0];
$links = $table->getElementsByTagName('a');
// haces peticiones a cada link, y extraes el correo (debe tener algun id asociado o por el estilo) de la misma forma


Es obvio, arreglo[0] = 1, arreglo[1] = 2, arreglo[2] = 3, etc. Si i vale 3, -> 4 + (4 + 1) = 9.

Bootstrap te recomiendo que lo customices o bajes un theme de bootwatch por ejemplo, el estilo por defecto esta ya sobreusado y da la impresion de poca originalidad.

Tambien tienes otras alternativas, como foundation por ejemplo, con un diseño más limpio y el mismo sistema de grilla. Full responsive.

Si el proyecto es escolar, metele bootsrap si estas familiarizado con el. Puedes bajar plantillas de acuerdo al modelo de tu aplicación.

Esa condicion ya esta definida en el bucle, no necesitas volverla a definir. Otra cosa, debes sumar i + i+1, no el arreglo en sí. Tu lógica esta mal.

Respecto al porque, es claro, siempre sumas arreglo + arreglo[i + 1]. Veamos caso por caso:

Cuando i = 0, arreglo + arreglo[i+1] = 1 + 2 = 3

Cuando i = 1, arreglo + arreglo[i+1] = 2 + 3 = 5

Cuando i = 2, arreglo + arreglo[i+1] = 3 + 4 = 7

Cuando i = 4, arreglo + arreglo[i+1] = 4 + 5 = 9

En realidad es muy fácil analizar ese algoritmo, debes ser más analítico. Utiliza hojas para hacer gráficos, asi analizarás mejor.