ShareThis

Il faut tout d’abord télécharger les .jar de Quercus (disponibles ici) .

Une fois téléchargés, il faut les inclure dans le dossier lib du domaine du serveur glassfish (par exemple dans le dossier [glassfish_home]/domains/domain1/lib/).

Il suffit ensuite d’implémenter la servlet de Quercus dans le fichier web.xml de l’application et d’en définir le mapping. Par exemple pour mapper toutes les pages en .php :

 
<servlet-name>Quercus Servlet</servlet-name>
  <servlet-class>com.caucho.quercus.servlet.QuercusServlet</servlet-class>
 
<servlet-mapping>
  <servlet-name>Quercus Servlet</servlet-name>
<url-pattern>*.php</url-pattern> 
 
</servlet-mapping>

On peut maintenant créer une page PHP et l’inclure dans le répertoire contenant les pages web de l’application. Une fois le .war de l’appli déployé, la page PHP sera disponible sur le serveur Glassfish !

ShareThis

Il faut tout d’abord télécharger les deux archives .jar de Soft EU URL rewriter et les inclure dans le projet.

Il faut aussi déclarer la servlet de Soft EU URL Rewriter dans le web.xml de l’application ainsi que les urls pour lesquelles il faut appliquer ce filtre :

<!-- url rewriter -->
<filter>
    <filter-name>RewriterFilter</filter-name>
    <filter-class>cz.softeu.rewriter.RewriterFilter</filter-class>
</filter>
 
<filter-mapping>
    <filter-name>RewriterFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Ici URL Rewriter testera toutes les urls de notre application.
Pour ne filtrer que les pages JSF, il faut préciser l’url pattern suivant :

<url-pattern>*.jsf</url-pattern>

Cette librairie permet ensuite par l’intermédiaire d’un fichier de configuration (rewriter-config.xml) d’associer une adresse à afficher et une adresse réelle. On peut, par exemple, définir dans notre fichier rewriter-config.xml :

<rewriter-config xmlns:b="http://rewriter.softeu.cz/basic/">
 
    <b:regex>
        <from>^/news/(.*)$</from>
        <to>/news.jsf?id=$1</to>
    </b:regex>
 
    <b:regex type="redirect">
        <from>^/categorie/([^\?]*)/(.*)$</from>
        <to>/displayCategories.jsf?id=$1</to>
    </b:regex>
 
</rewriter-config>

Dans cet exemple, on redirige toutes les urls du type http://www.site.com/news/123/ vers http://www.site.com/news.jsf?id=123 et les urls du type http://www.site.com/categorie/nom-de-la-categorie(ou tout type de texte)/123/ vers http://www.site.com/displayCategories.jsf?id=123

La propriété type offre trois options pour la gestion des url :

- par défaut : la librairie va chercher la page dans le répertoire de l’application
- redirect : une redirection est faîte sur la page
- permanent-redirect : redirection de type HttpServletResponse.SC_MOVED_PERMANENTLY
- temporary-redirect : redirection de type HttpServletResponse.SC_MOVED_TEMPORARILY

Il est donc maintenant possible de tester : en appelant l’url http://www.site.com/news/123/
la page http://www.site.com/news.jsf?id=123 s’affichera ce qui est beaucoup mieux pour le
référencement naturel !

ShareThis

FacesContext.getCurrentInstance()
.getExternalContext()
.redirect("http://www.monSite.com");

Il suffit de récupérer l’instance en cours et d’utiliser la méthode redirect.

ShareThis

Pour augmenter (ou diminuer) le timeout par défaut d’une session (qui est par défaut de 20 minutes), il suffit de préciser dans
le web.xml :

1
2
3

 <session-config>
     <session-timeout>60</session-timeout>
</session-config>

Le timeout à préciser étant un temps en minutes.

ShareThis

Un site dispose d’une section d’upload de photos. Ces photos sont enregistrées dans un répertoire /uploads de l’application.
Un gros problème se pose alors : une fois que l’on redéploie l’application, le contenu du répertoire /uploads est vidé puisque les photos ne seront plus présentes dans le .war de l’application.
La solution à ce problème est donc les alternate docroot.

On va pouvoir, dans le fichier sun-web.xml, définir un répertoire externe à l’application où l’on stockera les photos et y mapper une url. Ainsi, si on déclare dans notre sun-web.xml :

<property name="alternatedocroot_1" 
  value="from=/uploads/*
  dir=/home/">
</property>

Glassfish ira chercher toutes les photos qui auront l’url http://www.monSite.com/uploads/maPhoto.png dans le dossier /home/uploads/ du serveur.

A noter qu’il est possible de définir plusieurs alternate docroot, il faudra alors les déclarer sous la forme :

<property name="alternatedocroot_1" value="..."></property>
<property name="alternatedocroot_2" value="..."></property>
<property name="alternatedocroot_3" value="..."></property>

ShareThis

Concrètement, le virtual hosting permet facilement de créer des serveurs virtuels avec pour chacun des noms d’hôtes différents.
Il est ensuite possible pour chaque serveur virtuel d’écouter sur un n° de port défini et de gérer la sécurité (SSL…).
On pourra bien sûr, déployer des applications sur ce serveur virtuel.

Voici comment créer un nouveau domaine à l’aide de la console d’administration de glassfish :

Il faut tout d’abord se rendre dans la section virtual server ( HTTP Service > Virtual Server ) et cliquer sur New.
Une fois sur l’écran « New Virtual Server », mettre un nom unique en id et préciser le nom d’hôte ou l’adresse IP de votre serveur dans la case Host.
Laisser les autres propriétés par défaut et faire Ok.

Il faut ensuite créer un « http listener » qui interceptera les requêtes ( faire HTTP service > HTTP Listeners).
Cliquer sur New.
Sur l’écran New HTTPListener, mettez un nom, l’ip du serveur ainsi que le n° de port sur lequel le listener doit interpréter les requêtes et sélectionnez le serveur virtuel précédemment créé. Faire Next puis sur l’écran suivant laisser les options par défaut et faire Finish.

Il ne reste plus qu’a retourner sur notre serveur virtuel ( dans HTTP Service > Virtual Server ) pour y indiquer le nom de notre http-listener dans la case http-listener.

ShareThis

Voici une petite astuce toute simple permettant de déployer son application directement à la racine, c’est à dire ne plus avoir :

http://www.monDomaine.com/MonApplication/page.jsf

mais

http://www.monDomaine.com/page.jsf

Il suffit, lors du déploiement, de spécifier « / » pour le context root.
L’application sera alors disponible à partir de la racine du site.

ShareThis

Il faut tout d’abord faire un « binding » du DataTable dans le Bean JSF associé à la vue :

public class MonBean {
 
	private HtmlDataTable myDataTable;

public HtmlDataTable getMyDataTable() {

return myDataTable;
}

public void setMyDataTable(HtmlDataTable myDataTable) {

this.myDataTable = myDataTable;
}

}

Et dans la page JSP ne pas oublier l'attribut binding sur le DataTable (pour lier le DataTable à celui du bean) :

<h:dataTable value="#{monBean.maListe}" var="item" binding="#{monBean.myDataTable}">

</h:dataTable>
Il est ensuite possible de récupérer l'index de chaque ligne grâce à la propriété ronIndex du DataTable :

<h:outputText value=" #{monBean.myDataTable.rowIndex}" />

ShareThis

Le framework JSF offre trois possibilités de « scope » pour les managed beans :

• request (les valeurs des propriétés du bean sont sauvegadées le temps de la requête)
• session (les valeurs sont mises en sessions)
• application (les valeurs sont sauvegardées lors dez toute la durée de l’application)

Lorsqu’un managed bean est mis en session, il peut être utile de le récupérer à partir d’un autre bean de l’application. Ceci peut être fait de cette façon :

FacesContext fc = FacesContext.getCurrentInstance();
MonBean bean = (MonBean) fc.getExternalContext().getSessionMap().get( »nomDuBeanDansFacesConfig »);

Il suffit de récupérer le context de l’application, puis de récupérer le bean en session grâce à son nom déclaré dans le faces-config.xml.

ShareThis