Comments (0)

Jusqu’à présent, pour gérer plusieurs exceptions dans un bloc try/catch, il fallait un bloc catch par type d’exception. Il était bien entendu possible de “rattraper” une exception de haut niveau, de découvrir son type d’instance avec l’opérateur instance of puis de décider comment la traiter ou la relancer.

Désormais, il est aussi possible de déclarer plusieurs types d’exceptions dans un même bloc catch. Voici un exemple :

try {
   ...
} catch (IOException e) {
    System.out.println(e.getMessage());
} catch (MonException e) {
    System.out.println(e.getMessage());
} catch (Exception e) {
    System.err.println(e.getMessage());
}

// A partir de JavaSE 7
try {
   ...
} catch (IOException | MonException e) {
    System.out.println(e.getMessage());
} catch (Exception e) {
    System.err.println(e.getMessage());
}

Comments (0)

Avec Java 7, beaucoup de nouveautés sont arrivées. L’opérateur en diamant, par exemple, permet d’éliminer une redondance dans la rédaction du code source lorsque l’on déclare une collection. Par exemple avant Java 7 il fallait déclarer sa collection ainsi :

List<MaClasse> maListe = new ArrayList<MaClasse>();

Maintenant, il n’est plus nécessaire de préciser le type de la collection dans la l’instanciation :

List<MaClasse> maListe = new ArrayList<>();

Comments (0)

Certaines librairies JSF proposent des fonctionnalités d’export des tableaux (dataTable). Malheureusement, souvent ces fonctionnalités sont limités aux composants de la librairie elle-même. J’ai trouvé la librairie Lapis JSF Exporter très intéressante car elle permet d’exporter des composants de plusieurs librairies différentes de la même façon. De plus, elle est très facile d’accès et donc rapidement extensible.

Le projet est hébergé sur GitHub à l’adresse suivante : https://github.com/rdicroce/jsfexporter

Fonctionnalités

Dans la version actuelle (1.0.1.Final), il est possible d’exporter les composants suivants :

• h:panelGrid
• h:dataTable
• rich:dataTable
• p:dataTable (avec des colonnes dynamiques, lazy loading et des  p:columnGroup)
• p:treeTable
• p:dataList

Les composants supportant l’export à l’intérieur des cellules sont, entre autres :

• h/p:commandLink
• h:outputFormat
• h:panelGroup
• p:cellEditor

Les supports d’exports existants sont les suivants :

• CSV
• XML
• PDF
• XLS/XLSX

Installation

Pour installer la librairie, il faut ajouter dans les dépendances du projet la librairie core (jsf-exporter-core). C’est la librairie autour de laquelle toutes les implémentations sont développées.

<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>jsf-exporter-core</artifactId>
    <version>1.0.1.Final</version>
</dependency>

Il faudra ensuite déclarer le module d’exportation (CSV, PDF, etc.)

<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>export-type-csv</artifactId>
    <version>1.0.1.Final</version>
</dependency>
<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>export-type-excel</artifactId>
    <version>1.0.1.Final</version>
</dependency>
<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>export-type-pdf</artifactId>
    <version>1.0.1.Final</version>
</dependency>
<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>export-type-xml</artifactId>
    <version>1.0.1.Final</version>
</dependency>

Enfin, si vous souhaitez exporter des composants d’une des deux librairies RichFaces ou PrimeFaces, le “connecteur” sur la librairie

<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>export-source-primefaces</artifactId>
    <version>1.0.1.Final</version>
</dependency>
<dependency>
    <groupId>com.lapis.jsfexporter</groupId>
    <artifactId>export-source-richfaces</artifactId>
    <version>1.0.1.Final</version>
</dependency>

Exemple

Après avoir inclus les dépendances, pour utiliser  ce composant d’export, il faut d’une part, le déclarer dans les namespaces XML de la page XHTML puis l’utiliser en complément d’un bouton JSF :

xmlns:l="http://www.lapis.com/jsf/exporter"

...

<p:commandButton value="Export XLSX" ajax="false">
    <l:dataExporter source="table" fileType="excel" fileName="myfile"/>
</p:commandButton>

Comments (2)

Développer soit-même un singleton, cela n’a plus aucun intérêt. Des annotations sont faites pour cela :

• @javax.ejb.Singleton – Un nouveau type d’EJB provenant dans la JSR-318. Il est utilisé pour obtenir une seule instance partagée d’une même EJB. Cette instance est thread safe et transactionnelle.
• @javax.inject.Singleton – Provient de la JSR-330, la classe annotée de cette manière ne sera instanciée qu’une seule fois.
• @javax.enterprise.inject.ApplicationScoped – Un scope provenant de la JSR-299 (CDI), le bean est dans le scope application.
• @javax.faces.bean.ApplicationScoped – Définie dans JSF 2.0 (JSR-314) Managed Beans, c’est un managed bean JSF qui est placé dans le scope application.

Toutes ces annotations vont nous permettre d’obtenir des singletons. Mais quelles sont les différences entre elles ?

La différence entre les deux annotations @javax.enterprise.inject.ApplicationScoped et @javax.faces.bean.ApplicationScoped c’est le contexte de déploiement. Si le conteneur utilisé est compatible CDI il faut utiliser l’annotation CDI  sinon, si le conteneur n’est pas compatible CDI (par exemple Tomcat) il faut utiliser l’annotation JSF2.0.

Quelles sont donc les différences entre les trois premières annotations ?

L’annotation EJB - @javax.ejb.Singleton – est la seule à proposer les services  “entreprise”, c’est à dire la gestion des transactions et de la concurrence. Il faut donc l’utiliser quand ces services “entreprise” sont nécessaires. Remarque, dans ce cas, il est tout à fait possible d’utiliser un EJB statefull avec un scope application - @javax.enterprise.inject.ApplicationScoped. Cet objet sera gérer de façon différente par le conteneur CDI mais il aura exactement les mêmes caractéristiques qu’un EJB @javax.ejb.Singleton. Donc, à mon avis, autant utiliser l’EJB singleton plutôt que le statefull en scope application.

Si vous n’avez pas besoin des services “entreprise”, autant utiliser un POJO normal, managed bean dans J2EE, avec le scope application. C’est à dire @javax.enterprise.inject.ApplicationScoped.

L’annotation @javax.inject.Singleton ne sera vraiment utile que dans un contexte J2SE. Pour plus d’information, il faut lire la documentation de référence de weld concernat le pseudo-scope Singleton.

Comments (0)

Dans J2EE6 il existe deux spécifications qui parlent de scopes applicatifs : JSR 314: JavaServer Faces 2.0 et JSR 299: Contexts and Dependency Injection for the Java^TM EE platform (CDI). La difficulté vient du fait que ces scopes ont le même nom et la même fonction :

• @javax.faces.bean.RequestScoped (JSF) et @javax.enterprise.context.RequestScoped (CDI).
• @javax.faces.bean.SessionScoped (JSF) et @javax.enterprise.context.SessionScoped (CDI).
• @javax.faces.bean.ApplicationScoped (JSF) et @javax.enterprise.context.ApplicationScoped (CDI).

Lesquels utilisés ? Comme pour certaines autres annotations qui semblent dupliquées dans J2EE, ces annotations sont identiques, elle diffèrent uniquement suivant le contexte de déploiement. JSF2.0 propose ses propres annotations pour laisser la possibilité aux développeurs de déployer des applications JSF2.0 dans des conteneurs dépourvus de CDI (Tomcat par exemple) mais en conservant l’avantage de l’outjection proposée par la JSR CDI.

Sachant cela, la sélection de ces annotations doit se faire en fonction du contexte de déploiement. Il faut bien entendu préférer les annotations CDI à JSF si le conteneur est compatible avec la JSR-299.

Il existe cependant un scope proposé par JSF2.0 et inexistant dans CDI : @ViewScoped. Il est possible dans ce cas d’utiliser la librairie DeltaSpike JSF ou Seam 3 Face Module pour avoir accès à une version CDI du scope.

Comments (0)

D’après le forum de zeroturnaround, JRebel 5.5.0 n’est pas compatible avec Wildfly8.0.0.CR1. Pour le rendre compatible il faut récupérer la dernière version de développement de JRebel (nigthly build) sur leur site internet : http://zeroturnaround.com/software/jrebel/download/early-access/.

Pour mettre à jour la librairie utilisée par le plugin JRebel dans eclipse , il faut se rendre dans l’écran de configuration JRebel : Help -> JRebel Config Center. Ensuite saisir le chemin de la librairie dans l’onglet Overview. Sinon, par défaut, le plugin utilise la version embarquée de la librairie.

Comments (0)

Lorsque l’on débute en J2EE il est parfois difficile de voir la différence entre certaines annotations. Elles proviennent souvent de spécifications (JSR) différentes et peuvent avoir un rôle similaire ou totalement identique. Certaines fois, il s’agit uniquement d’une différence de contexte dans lequel le code est développé ou déployé.

Les annotations suivantes sont utiles pour déclarer des objets Java qui vont être accessibles dans le langage EL via les symboles #{} (on parle d’outjection par opposition à injection).

@javax.faces.bean.ManagedBean

Cette annotation arrive avec la JSR-314 JavaServer Faces 2.0. Grâce à elle, il n’est plus nécessaire de déclarer les Managed Bean JSF dans le fichier XML faces-config.xml. Elle n’est utile que lorsque le l’application développée est déployée dans un contexte où le conteneur CDI n’existe pas, comme Tomcat par example.

De plus, elle peut facilement être confondue avec l’annotation suivante @java.annotation.ManagedBean.

@javax.annotation.ManagedBean

Cette annotation est définie dans la JSR-250. Elle est utilisée pour déclarer un managed bean spécifié dans la JSR-316. Il ne faut pas confondre avec les managed bean JSF. Le principe de la JSR-316 est de pouvoir transformer n’importe quel POJO (Plain Old Java Object) en objet pouvoir avoir un cycle de vie, des intercepteurs, etc.

Dans un contexte CDI, cette annotation est obsolète car le principe du CDI est de transformer tous les POJO en Managed Bean. Donc cette annotation n’est pas du tout utile. Elle n’aura d’ailleurs aucun impact visible sur l’exécution du code.

@javax.enterprise.inject.Model @javax.inject.Named

L’annotation @Model est équivalante à l’annotation @Named à laquel il a été rajouté le contexte @RequestScoped (@javax.enterprise.context.RequestScoped).

Ces annotations proviennent de la JSR 299 “contexts and dependency injection” (CDI). Cette JSR offre beaucoup plus de possibilités d’utilisation que celle sur JSF2.0. Dans un contexte où une application est déployée dans un conteneur compatible CDI il est donc préférable d’utiliser les annotations CDI plutôt que JSF2.0.

Conclusion

Le choix de l’annotation à utiliser dépend essentiellement du conteneur où l’application sera déployée. Il est toujours préférable d’utiliser les annotations provenant de la JSR-299 (CDI) dans le cas où le conteneur est compatible avec CDI.

Pour plus d’information cet article est très intéressant : Is @javax.faces.bean.ManagedBean Dead on Arrival?

Comments (0)

Pour débuger l’authentification faite grâce à picketLink avec JBoss Wildfly, il est nécessaire d’ajouter le logger ci-dessous puis de modifier la priorité par défaut de la console.

org.picketlink.idm

Pour cela, il faut se connecter à la console du serveur d’application puis se rendre sur la gestion des logger dans l’onglet “LOG CATEGORIES”.

Ajouter la catégorie associée au package picketLink avec le niveau DEBUG.

Enfin dans la catégorie “HANDLER”, modifier le niveau de log du handler console.

Pour information, les modifications sont prises en compte à chaud. Pas besoin de redémarrer le serveur.

Comments (0)

Il est toujours compliqué de savoir quelles versions il faut utiliser pour les fichiers de description des déploiements (comme le fichier web.xml par exemple). Cet article a pour but de référencer les principaux fichiers utilisés dans le cadre d’une application java J2EE 7 avec une petite explication sur leur utilité.

CDI 1.1

Il s’agit du fichier beans.xml. Il est obligatoire si l’on souhaite utiliser l’injection de dépendance. Attention, il peut resté totalement vide.

<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"
       version="1.1" bean-discovery-mode="all">
</beans>

Ce fichier doit être déposé dans le répertoire WEB-INF/lib ou WEB-INF/classes/META-INF pour un archive web (WAR) et META-INF/ dans une archive java (JAR)

Pour plus d’information : JSR 346: Contexts and Dependency Injection for Java^TM EE 1.1

Bean Validation 1.1

Deux fichiers pour cette JSR (349) : validation.xml et constraints.xml

<validation-config
        xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd"
        version="1.1">
</validation-config>

<constraint-mappings
        xmlns="http://jboss.org/xml/ns/javax/validation/mapping"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.1.xsd"
        version="1.1">
</constraint-mappings>

Ces fichiers doivent être déposés dans le répertoire META-INF d’une archive Java (JAR).

Pour plus d’information : JSR 349: Bean Validation 1.1

JPA 2.1

Pour avoir accès à la base de données, il est obligatoire de posséder le fichier persistence.xml.

<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
             version="2.1">
</persistence>

Il existe aussi un fichier de mapping des entités qui n’est pas obligatoire : orm.xml. Il permet, entre autre, de référencer des classes qui se trouvent dans une même application mais dans des librairies tierces (JAR).

<entity-mappings xmlns="http://xmlns.jcp.org/xml/ns/persistence/orm"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence/orm http://xmlns.jcp.org/xml/ns/persistence/orm_2_1.xsd"
                 version="2.1">
</entity-mappings>

Ces deux fichiers doivent être positionnés dans le répertoire META-INF/ dans une archive java (JAR). Pour rappel, seul le fichier persistence.xml est obligatoire s’il est question d’avoir des accès avec une base de données.

Pour plus d’information : JSR 338: Java^TM Persistence 2.1 :

EJB 3.2

Ce fichier n’est pas non plus obligatoire : ejb-jar.xml.

<ejb-jar 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/ejb-jar_3_2.xsd"
         version="3.2">
</ejb-jar>

Ce fichier doit être positionné dans le répertoire META-INF/ dans une archive java (JAR).

Pour plus d’information : JSR 345: Enterprise JavaBeans^TM 3.2

Servlet 3.1

Pour plus d’information : JSR 340: Java Servlet 3.1 Specification

JSF 2.2

Pour la partie vue de J2EE7, le fichier faces-config.xml n’est plus obligatoire.

<faces-config 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/web-facesconfig_2_2.xsd"
              version="2.2">
</faces-config>

Un fichier JSF est un fichier XML avec l’extention *.xhtml. Il se présente sous cette forme :

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
</html>

Le fichier faces-config.xml doit se trouver dans le répertoire WEB-INF/ d’une archive web (WAR).

Pour plus d’information : JSR 344: JavaServer^TM Faces 2.2

JAX-WS 2.2

Pour les services web, il s’agit du fichier webservices.xml :

<webservices 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/javaee_web_services_1_4.xsd"
             version="1.4">
</webservices>

Il doit être positionné dans le répertoire WEB-INF/ d’une archive web (WAR).

Pour plus d’information : JSR 224: Java^TM API for XML-Based Web Services (JAX-WS) 2.0, JSR 109: Implementing Enterprise Web Services, JSR 181: Web Services Metadata for the Java^TM 

Conclusion

Pour plus d’information et connaître les autres fichiers qui permettre de réaliser d’autres types de traitements, par exemple des batchs en J2EE7 ou décrire une archives entreprises (EAR) : http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html#7

Cet article est fortement inspiré de ce site internet : http://antoniogoncalves.org/2013/06/04/java-ee-7-deployment-descriptors/

Comments (0)

La version 0.0.1 de JSFCharts est disponible. Cette librairie est un wrapper JSF de Highcharts 3.0.x (3.0.1 pour cette version). Le site de démonstration est hébergé ici. Les sources de cette application exemple sont disponibles sur GitHub.

Une fois intégrée à votre projet, elle vous permettra de générer les graphiques dynamiques  suivants :

• Ligne (Line)
• Histogramme (Bar, Column)
• Aires (Area)

Pour l’intégrer dans un projet Maven, il faut ajouter ces informations dans votre POM :

	<repositories>
		<repository>
			<id>jsfcharts-repo</id>
			<name>Jsfcharts Maven Repository</name>
			<url>http://yanlanglois.github.io/jsfcharts/repository</url>
			<layout>default</layout>
		</repository>
	</repositories>

	<dependencies>
		<dependency>
			<groupId>org.eiw</groupId>
			<artifactId>jsfcharts-core</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>org.eiw</groupId>
			<artifactId>jsfcharts-jslib</artifactId>
			<version>0.0.1</version>
		</dependency>
	</dependencies>

Rappel : des informations complémentaires sur JSFCharts sont disponibles ici.