Lorsque le wifi est instable que la connexion ne fonctionne quelques secondes pour se perdre juste après et que la seule façon de retrouver une connexion est de redémarrer le module iwlwifi ou le service network. Si vous êtes en dual boot, il est possible que l’option Windows 10 de démarrage rapide en soit la cause. Essayer donc de désactiver l’option de démarrage rapide (fast startup).
Source : https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_dual-boot_with_windows_and_fast-boot_enabled
Une autre cause potentiel du problème : la gestion de l’énergie : https://forum.ubuntu-fr.org/viewtopic.php?id=2063349
Pour lister les streams d'un fichier vidéo il faut utiliser la commande ffprobe :
ffprobe -i [filename]
Depuis la montée de version du dernier ubuntu j’avais des problèmes avec ma carte réseau Linksys WMP54G. Impossible de la faire fonctionner malgré la bonne détection des réseaux WIFI aux alentours.
Connaître le modèle de sa carte
Il existe plusieurs architectures de carte WMP54G. La mienne est une RT2561/RT61 :
xxxx@xxxx-desktop:~$ lspci | grep -i network
04:06.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
J’ai compris que le problème venait de la gestion de l’optimisation de l’alimentation électrique : NetworkManager WiFi Power Saving.
Vérifier du paramètre d’alimentation électrique
Il existe 4 niveaux de gestion :
-
NM_SETTING_WIRELESS_POWERSAVE_DEFAULT (0): use the default value
-
NM_SETTING_WIRELESS_POWERSAVE_IGNORE (1): don't touch existing setting
-
NM_SETTING_WIRELESS_POWERSAVE_DISABLE (2): disable powersave
-
NM_SETTING_WIRELESS_POWERSAVE_ENABLE (3): enable powersave
Mon paramètre était positionné sur 3 par défaut. Je l’ai mis sur 0 et ma carte s’est de nouveau mise à fonctionner :
yan@yan-desktop:~$ cat /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
[connection]
wifi.powersave = O
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}" />
Il est possible de démarrer le navigateur Chrome (ou Chromium) en supprimant les éléments de menus propres au navigateur comme :
- La barre d’adresse
- La barre des boutons
- Les onglets
Pour cela, il faut utiliser le switch --app. Par exemple la commande : chromium-browser --app=http://google.com ou chrome --app=http://google.com provoque l’ouverture de la fenêtre suivante :
Grâce à cela, il est possible de démarrer des applications web comme s’il s’agissait d’applications client lourd.
Un commande permet de connaître le numéro de version exact de sa distribution ubuntu : lsb_release -a.
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
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.
En travaillant sur un test Graphene 2, je me suis rendu compte qu’il pouvait être très intéressant de tracer le contenu des requêtes HTTP attaquant une application web. Lorsque cette application est déployée sur un serveur JBoss, il suffit d’ajouter une ligne dans le fichier jboss-web.xml :
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<valve>
<class-name>org.apache.catalina.valves.RequestDumperValve</class-name>
</valve>
</jboss-web>
Remarque, je n’ai pas essayé sur WildFly, mais la technique devrait fonctionner de la même façon. Ce fichier doit être dans le répertoire WEB-INF de l’archive web.
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érencename : 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) 
