Un Pool de connexion ?

Qu'est-ce qu'un pool de connexion?

Un pool de connexions est un magasin de connexions à une base de données qui peut être utilisé et (plus important encore) réutilisé pour se connecter à une base de données.
Pourquoi a-t-on besoin de pools de connexion?

Les connexions aux bases de données sont coûteuses à créer et à maintenir. Les raisons en sont nombreuses, notamment:

    Établissement d'une connexion réseau au serveur de base de données
    Analyser les informations de la chaîne de connexion
    Authentification de l'utilisateur
    Initialisation de la connexion à la base de données dans la base de données
    Établissement de contextes transactionnels

Désormais, si vous avez une application Web avec un seul utilisateur, vous pouvez simplement créer une connexion à une base de données au début de la session utilisateur, puis la fermer à la fin. Cependant, ce scénario est hautement improbable!

Imaginez maintenant un scénario plus réaliste dans lequel des centaines, voire des milliers d’utilisateurs, accéderont à votre application Web. Si la session de chaque utilisateur crée une connexion à une base de données, vos utilisateurs subiront un retard pendant l'installation de cette connexion et, deuxièmement, les performances globales de votre système se détérioreront.

Alors, en réponse à la question de savoir pourquoi ils sont nécessaires, ils améliorent à la fois les performances et l'évolutivité de votre système.
Comment fonctionnent les pools de connexion?

Plutôt que de créer une nouvelle connexion chaque fois que nécessaire, un pool de connexions est créé au démarrage de votre serveur d'applications. Ces connexions peuvent ensuite être utilisées et réutilisées. Lorsqu'une nouvelle connexion est requise, le pool recherche une connexion disponible. S'il en existe un, il est renvoyé au demandeur. Si aucune n'est disponible, la demande est mise en file d'attente ou une nouvelle connexion est établie en fonction du nombre de connexions déjà présentes dans le pool et de la configuration de celui-ci. Une fois la connexion établie, au lieu de la fermer, la connexion est renvoyée au pool de connexions pour être utilisée par le demandeur suivant.

OK.

Code lab JAX-RS 2.0

Intégration MDL et JSF

Bonjour, voici une idée pour utiliser du MDL dans vos future projet #jsf une intégration complète du MDL avec les vues xhtml (facelets), utilisant le support ajax et bien évidement la notion de templating, les bean managed de type CDI et bien d'autre techno de la JEE.

le code source ici: https://github.com/ricken07/javatuto/tree/master/jsf

GlassFish Encodage, modifier la valeur par Defaut

Le codage par défaut de GlassFish renvoie le texte codé en ISO-8859-1. Ceci est basé sur le protocole de transfert hypertexte - HTTP / 1.1 RFC 3.7.1 Canonicalisation et valeurs par défaut du texte qui requiert le codage par défaut pour que le texte soit renvoyé de cette manière.

Les développeurs d'applications Web utilisent souvent UTF-8 comme encodage dans leurs applications, mais ne parviennent pas à modifier les valeurs par défaut du serveur. Cela s'applique à tout ce qui utilise Servlets (y compris JSP et JSF). Vous pouvez modifier les valeurs par défaut dans sun-web.xml ou glassfish-web.xml comme indiqué ci-dessous en définissant l'élément de codage de paramètres.

<glassfish-web-app>
    <!-- Modifiez le codage de caractères par défaut de ISO-8859-1 à UTF-8 -->
    <parameter-encoding default-charset="UTF-8"/>
</glassfish-web-app>

fichier glassfich-web.xml

source: JHON YEARY

JSF2.2: configuration du "répertoire des ressources"

JSF 2.2 permet de configurer le répertoire utilisé pour la recherche de ressources.

Par défaut, le mécanisme de gestion des ressources introduit dans JSF 2.0 recherche les ressources dans les emplacements suivants:

1. /resources sous le dossier racine de l'application Web.
2. /META-INF/ressources dans les fichiers JAR.

L'inconvénient de /ressources est que tout dans ce dossier est accessible de l'extérieur par défaut. Cela n'est pas toujours souhaitable, en particulier pour les composants composites. Par conséquent, JSF 2.2 introduit le paramètre de contexte javax.faces.WEBAPP_RESOURCES_DIRECTORY pour spécifier le répertoire utilisé pour la recherche de ressource dans le système de fichiers de l'application Web (point 1 dans la liste ci-dessus). Dans la liste ci-dessous, le chemin est déplacé vers                    /WEB-INF/resources par exemple. Ressources à l'intérieur /WEB-INF peut être consulté par JSF, mais jamais du "monde extérieur".

illustration:

A la découverte de Vraptor4

Lorsque vous travaillez avec Java pour le Web, il existe de nombreux frameworks MVC possibles basés sur l'action. VRaptor est l'un de ceux et il est opensource. Sa 4ème version est basée sur CDI 1.1 et offre une haute productivité à vos application Web. Cet article vous donnera une brève aperçu de son intégration.

1. Créer un projet web maven;
2. Edité votre fichier pom.xml, pour ajouter les dépendences de Vraptor:

 <dependency>
            <groupId>br.com.caelum</groupId>
            <artifactId>vraptor</artifactId>
            <version>4.2.0-RC3</version>
  </dependency>

3. Mettre en place votre contrôleur.

Tout ce que vous devez faire pour démarrer votre premier contrôleur sur VRaptor est d'annoter votre classe avec @Controller, et le framework compte sur ses conventions URL et JSP pour vous permettre d'utiliser le moins de configurations possible. Ceci est un exemple:

HelloController.java

index.jsp, votre vue se trouvant à l'emplacement: WEB-INF/jsp/hello/index.jsp

la documentation sur Vraptor4, ici docs

le code source du projet helloVraptor, ici source