Comments (0)

Si vous avez déjà développé un FacesConverter, vous avez certainement compris qu’il n’est pas possible d’utiliser l’injection CDI dans ce type d’objet. Je vais donc transformer le simple converter suivant pour permettre l’injection :

@FacesConverter(value="monConverter")
public class MonConverter implements Converter {

   @Override
   public Object getAsObject(FacesContext context, UIComponent component, String value) {
      // création d'un objet en fonction de la valeur à convertir
      return new MonObjet(value);
   }

   @Override
   public String getAsString(FacesContext context, UIComponent component, Object value) {
      // Exemple de version de l'objet en String
      return ((MonObjet) value).getValue();
   }

}

Tout d’abord, pour pouvoir injecter un objet et rendre le converter visible dans la vue XHTML, il faut remplacer l’annotation @FacesConverter par @Named. Puis Injecter l’objet souhaité :

//@FacesConverter(value="monConverter")
@Named
public class MonConverter implements Converter {

   // Injection possible dans ce cas
   @Inject private EntityManager em;

   @Override
   public Object getAsObject(FacesContext context, UIComponent component, String value) {
      // création d'un objet en fonction de la valeur à convertir
      return new MonObject(value);
   }

   @Override
   public String getAsString(FacesContext context, UIComponent component, Object value) {
      // Exemple de version de l'objet en String
      return ((MonObjet) value).getValue();
   }

}

Ensuite, une petite transformation de la vue est nécessaire pour faire appel à ce nouveau converter. On n’utilise plus l’identifiant du converter mais sa référence directement  :

<!-- Avant avec l'ID-->
<h:input... converter="monConverter" />
ou
<f:converter converterId="monConverter" />

<!-- Après avec l'objet directement -->
<h:input... converter="#{monConverter}" />
ou
<f:converter binding="#{monConverter}" />

Comments (0)

Pour implémenter une fonctionnalité de logout (déconnexion) à partir d’une interface JSF, il faut invalider la session en cours. Pour cela, un bouton va appeler une action d’un @Model. C’est-à-dire, coté JSF :

<h:form>
    <h:commandLink value="Logout" action="#{logoutBean.logout}" />
</h:form>

Coté Java, si on considère que le point d’entrée de l’application est /index.html :

public String logout() {
    ((HttpSession) FacesContext.getCurrentInstance().getExternalContext()
         .getSession(true)).invalidate();
     return "/index.html?faces-redirect=true";
}

Remarque, pour procéder à une redirection avec JSF2.2, il faut ajouter ce paramètre à l’URL choisie : ...?faces-redirect=true

Comments (0)

Richfaces 4.5.0.Alpha3 est sortie ! Avec cette version, une nouveauté, les fragments de page (pages-fragments). Il s’agit de classes qui permettent de développer des tests unitaires automatisés sur les applications utilisant RichFaces.

La configuration Maven pour utiliser ces fragements est la suivante :

<dependency>
    <groupId>org.richfaces</groupId>
    <artifactId>richfaces-page-fragments</artifactId>
    <version>4.5.0.Alpha3</version>
    <scope>test</scope>
</dependency>

Les sources sont disponibles sur GitHub : https://github.com/richfaces/richfaces/tree/master/build/page-fragments.

Pour plus d’informations sur Arquillian : http://slides.com/vineetreynolds/the-arquillian-universe.

Pour plus d’informations sur les tests d’application JSF : http://www.bleathem.ca/talks/2012-JavaOne/testing-jsf.html.

Comments (0)

Il existe un composant standard pour inclure une librairie Javascript : h:outputScript. Pour que JSF trouve cette librairie, il faut quelle soit présente dans un répertoire de type resources :

• Soit à la racine du contexte web : src/main/webapp/resources pour un projet Maven
• Soit directement encapsulée dans un jar : META-INF/resources


A mon sens, les deux attributs les plus importants de ce composant sont :

• library : Le chemin du répertoire où se trouve le fichier Javascript en prenant en compte le répertoire resources comme référence
• name : Le nom du fichier Javascript

Par exemple pour inclure le fichier Javascript se trouvant dans src/main/webapp/resources/ma/librairie/lib.js ou bien dans META-INF/resources/ma/librairie/lib.js :

<h:outputScript library="ma/librairie" name="lib.js" />

Pour tester sur des cas réels, vous pouvez récupérer une des nombreuses librairies Javascript packagées dans un jar disponibles à cette adresse : http://www.webjars.org/. Pour vous facilité la tâche ces librairies sont disponibles sur Maven. Par exemple pour ajouter aux dépendances de votre projet la librairie amchart :

<dependency>
    <groupId>org.webjars</groupId>
    <artifactId>amcharts</artifactId>
    <version>3.10.0</version>
</dependency>

Comments (0)

Dans cet article il est proposé de développer une petite application JSF 2.2 avec un rechargement Ajax. Il existe beaucoup d’exemples qui utilisent par simplicité des objets en session. Le problème dans ce cas c’est que l’on ne comprend pas forcément l’importance des scopes et de la structure que l’on peut utiliser lors d’un développement en prenant en compte les problématiques de production classiques (limiter et simplifier la taille et l’utilisation de la mémoire).

Vue d’ensemble et configurations

Dans cet exemple en conditions réelles nous pouvons séparer les objets Java en trois catégories d’où les trois packages suivant :

• Le modèle (les données dans le modèle MVC) : dans l’exemple un simple POJO, dans une application réelle cela peut être une entité JPA.
• Le contrôleur (le contrôleur dans le modèle MVC) : dans l’exemple un simple POJO, dans une application réelle cela peut aussi être une EJB.
• Le DAO pour l’accès aux données. Dans ce cas il s’agit d’un producer.

Le fichier XHTML représente la vue dans le modèle MVC. Les fichiers de configuration restent vides.

Le model

Dans cet exemple il s’agit d’un simple POJO avec une variable d’instance de type String pour sauvegarder le nom de l’utilisateur.

package org.eiw.model;

/**
 * Dans un cas réel, ce bean pourrait être un objet persistant.
 *
 */
public class HelloBean {
    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

}

Le producer

Le producer, est un POJO enregistré dans le scope Request afin de limiter le nombre d’objets en session. C’est lui qui se charge de délivrer le modèle aux autres parties de l’application, dont la vue. Il y a deux méthodes d’initialisations :

• @PostConstruct : méthode qui est exécutée automatiquement à la création de l’objet donc à chaque nouvelle requête HTTP.
• @Observes : méthode qui est exécuté lorsqu’un événement de type HelloBean est lancé. Elle remplace la valeur par défaut du modèle par la valeur de l’objet passé en paramètre.

package org.eiw.data;

import javax.annotation.PostConstruct;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.event.Observes;
import javax.enterprise.event.Reception;
import javax.enterprise.inject.Produces;
import javax.inject.Named;

import org.eiw.model.HelloBean;
/**
 * Le producer es dans le scope Request,
 * il sera recréé à chaque nouvelle requete HTTP.
 */
@RequestScoped
public class HelloWorldProducer {
    private HelloBean myHelloBean;
    /**
         * La méthode qui produit l'objet de données vis à vis de la page XHTML.
         */
    @Named
    @Produces
    public HelloBean getMyHelloBean() {
        return myHelloBean;
    }
    /**
     * Initialise myHelloBean via un évènement.
     * Méthode observeur qui s'éxécute lorsqu'un évènement
     * de type HelloBean est lancé.
     * @param helloBean Le paramètre de l'évènement détecté.
     */
    public void myHelloBeanObserver(
            @Observes(notifyObserver = Reception.IF_EXISTS)
                HelloBean helloBean) {
        myHelloBean = helloBean;
    }

    /**
     * La méthode qui initialise l'objet,
         * à chaque nouvelle requête HTTP.
         */
    @PostConstruct
    public void initMessage() {
        myHelloBean = new HelloBean();
    }
}

Le contrôleur

Cet objet est annoté avec @Model. Cela lui permet d’être enregistré dans le scope Request et d’être “outjecter” dans le contexte CDI. Il est donc visible dans la vue. Il possède une méthode public que la vue peut appeler. Il a aussi une variable d’instance de type javax.enterprise.event.Event qui va permettre de déclencher un événement de type HelloBean et donc de prévenir le producer que l’objet myHelloBean doit être initialisé avec la méthode @Observes.

package org.eiw.controller;

import javax.enterprise.event.Event;
import javax.enterprise.inject.Model;
import javax.inject.Inject;

import org.eiw.model.HelloBean;

/**
 * Controller qui va traiter les demandes des vues.
 * L'annotation est utilisée pour :
 *  - Positionner l'objet dans le scope Request
 *  - Outjecter l'objet dans le contexte d'injection CDI
 *  - Pouvoir référencer l'objet dans la vue XHTML
 */
@Model
public class HelloController {

    /**
     * Injection d'un evènement pour pouvoir prévenir
     * le producer que l'objet myHelloBean doit être modifier.
     */
    @Inject
    private Event<HelloBean> helloBeanEventSrc;

    /**
     * Action pour traiter la soumission du formulaire.
     * @param helloBean Cet instance vient de l'IHM.
     */
    public void modifierBean(HelloBean helloBean) {
        // Lancement de l'évènement de type HelloBean pour
        // provoquer l'exécution de la méthode observeur
        // pour mettre à jour le bean HeeloBean
        helloBeanEventSrc.fire(helloBean);
    }
}

La vue

Dans le fichier XHTML, il est important de remarquer que le composant de saisi et le bouton d’action sont encapsulés dans un formulaire (<h:form/>). Dès qu’un composant fait appel à une action ou un listner il faut l’encapsuler dans un formulaire.  Sinon, la vue ne peut pas interagir avec le code Java. Cela provient de  la façon de travailler de JSF, en effet, toutes les interactions entre XHTML et Java passent par la soumission d’un formulaire en POST.

En revanche, la partie de la page qui se rafraîchit n’est pas nécessairement dans un formulaire.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core">
<h:head>
</h:head>
<h:body>
	<h:form>
		Saisir votre nom :
		<h:inputText value="#{myHelloBean.name}" />
		<h:commandButton value="valider">
			<f:ajax render="message" execute="@form"
				listener="#{helloController.modifierBean(myHelloBean)}" />
		</h:commandButton>
	</h:form>
	<h:outputText id="message" value="Hello #{myHelloBean.name} !" />

</h:body>

</html>

La seule contrainte pour que le composant puisse être mis à jour correctement c’est d’exister dans la page générée avant la demande de rechargement. Le code suivant ne fonctionnerai pas par exemple :

<h:outputText id="message" value="Hello #{myHelloBean.name} !"
              render="#{not emty myHelloBean.name}" />

Le déploiement

Pour déployer cette application, il suffit d’utiliser le plugin wildfly avec la commande suivante : mvn wildfly:run. Ensuite de se rendre sur l’adresse http://localhost:8080/hello-world-ajax/index.jsf  et de visualiser le résultat :

Après avoir saisi son nom et cliqué sur le bouton validé, seul le libellé “Hello !” est mis à jour :

Que s’est-il passé coté HTTP lorsque le bouton “valider” est pressé ? Une requête POST est envoyée à la servlet JSF qui donne la main au contrôleur. Ensuite pour le rechargement seul un rechargement partiel est envoyé à la page d’origine. On peut d’ailleurs voir le contenu du message mis à jour. Le flux qui transite sur le réseau est donc limité au strict minimum.

Ce tutoriel est disponible sur GitHub à l’adresse suivante : https://github.com/yanLanglois/jsf-2.2-tutoriel/tree/master/hello-world-ajax.

Comments (0)

Voici un exemple d’une application JSF2.2 minimaliste. Une vue xhtml un bean Java contenant le message “Hello world !”. Une configuration minimaliste aussi pour pouvoir déployer l’application dans le serveur wildfly.

Vue d’ensemble et configurations

Pour cette application il est suffisant d’avoir un fichier Java porteur des données (le model), un fichier xhtml décrivant la vue et un quelques fichiers de configuration :

• beans.xml : ce fichier est vide dans cet exemple. Il permet à l’application de bénéficier du CDI
• faces-config.xml : ce fichier est vide dans cet exemple. Il permet de configurer tout ce qui est en lien avec JSF
• web.xml : ce fichier est facultatif je l’ai ajouté pour avoir un exemple de namespace XML pour la bonne version du serveur wildfly

Pour rappel, JSF est une technologie qui se base sur le modèle MVC-2. Le rôle du contrôleur est joué par la servlet JSF qui centralise les demandes provenant de la vue et qui redirige vers les bons traitements Java (avec JSF on parle en général d’actions).

Le model (Bean Java)

L’objet Java qui va contenir les données, c’est à dire le message “Hello world !” est un String. Cet objet va être créé par un producer en scope Request. A chaque nouvel appel à la vue, une nouvelle requête sera nécessaire et l’objet sera recréé de toute pièce.

package org.eiw.data;

import javax.annotation.PostConstruct;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.inject.Produces;
import javax.inject.Named;

/***
 * Le producer est dans le scope Request,
 * il sera recréé à chaque nouvelle requête HTTP.
 */
@RequestScoped
public class HelloWorldProducer {
	private String message;

	/**
	 * La méthode qui produit l'objet de données vis à vis de la page XHTML.
	 */
	@Named
	@Produces
	public String getMessage() {
		return message;
	}

	/**
	 * La méthode qui initialise l'objet,
	 * à chaque nouvelle requête HTTP.
	 */
	@PostConstruct
	public void initMessage() {
		message = "Hello world !";
	}
}

La vue (XHTML)

Dans ce fichier, nous allons utiliser le conteneur CDI pour récupérer l’objet Java des données vu ci-dessus. Nous allons ensuite l’associer à un tag JSF pour formater son affichage :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core">
<h:head>
</h:head>
<h:body>
	<h:outputText value="#{message}" />
</h:body>

Pour récupérer l’objet, il faut utiliser son nom qui est égal par défaut au nom de l’instance avec le langage EL : #{maVariable}.

Le déploiement

Pour déployer cette application, il suffit d’utiliser le plugin wildfly avec la commande suivante : mvn wildfly:run. Ensuite de se rendre sur l’adresse http://localhost:8080/hello-world/index.jsf  et de visualiser le résultat :

Remarque : s’il s’agit de la première fois que vous utilisez le plugin wildfly, il vous faudra un peu de temps pour démarrer l’application car il est nécessaire de télécharger, dans le repository maven local, le serveur complet avant de le démarrer.

Ce tutoriel est disponible sur GitHub à l’adresse suivante : https://github.com/yanLanglois/jsf-2.2-tutoriel/tree/master/hello-world.

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)

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)

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.