Google Chrome et les proxys http sur Xfce

Afin de débugger une requête REST posant problème sous Google Chrome, je me suis tourné vers le proxy http charles écrit en Java.

Mais au lieu de pouvoir positionner un proxy http dans les settings de Chrome, j'ai eu comme réponse la page suivante:

En fait, ce que n'aime pas Google Chrome, c'est le fait que mon environnement graphique soit Xfce. On rencontre la même erreur avec le navigateur Chromium sur lequel Google Chrome est basé.

Si maintenant je veux utiliser un proxy http avec Google Chrome sous Gnome, j'obtiens bien la boite de dialogue suivante relative au "serveur mandataire".

Donc il est fort probable que cette boite de dialogue de sélection du proxy soit un composant de Gnome - non installé dans mon environnement Xfce.

Pour pouvoir définir un proxy http avec Google Chrome dans l'environnement graphique Xfce, on procèdera donc comme suit:

• Positionner la variable d'environnement http_proxy avec l'adresse du proxy avant de lancer Chrome,
• Ou ajouter --proxy-server=<adresse du proxy> sur la ligne de commande de Chrome.

Debian: Utiliser java-package pour créer des packages natifs depuis les JDK et JRE de Sun

Installer java sous Linux consiste trop souvent:

• à décompresser un fichier .tar.gz ou .zip,
• à lancer un fichier .bin qui extrait son contenu dans le répertoire courant

Sur Debian, le package java-package de la section contrib permet de convertir une archive du JDK ou du JRE livrée par Sun (en fait Oracle maintenant) en package natif Debian (un fichier .deb), ce qui est bien plus commode et plus propre pour l'installation qu'un .tar.gz ou un fichier binaire.

Sur Debian Wheezy, après avoir ajouté contrib au fichier /etc/apt/sources.list puis lancé apt-get update, on installe java-package comme suit:

apt-get install java-package

Le paquet java-package installe la commande make-jpkg (make java package) qui convertit une archive .bin ou .tar.gz en provenance d'Oracle en paquet Debian.

Par exemple:

fakeroot make-jpkg /home/myuser/Downloads/jre-6u38-linux-x64.bin

On obtient alors dans le répertoire courant le fichier:

oracle-j2re1.6_1.6.0+update38_amd64.deb

Qu'il suffit d'installer comme suit:

sudo dpkg -l oracle-j2re1.6_1.6.0+update38_amd64.deb

On peut vérifier le contenu du package généré par:

sudo dpkg -c oracle-j2re1.6_1.6.0+update38_amd64.deb

En utilisant java-package, les JRE et JDK Java s'installent comme les autres logiciels sous Debian, et Java est accessible pour tous les utilisateurs du système et pas seulement pour un utilisateur donné.

Note: Si vous voulez convertir une archive de Java 7, il se peut que vous obteniez l'erreur suivante "No matching plugin was found".

En fait l'update 10 (et ceux d'après) de Java 7 n'est pas encore prévue dans java-package (qui ne prévoit qu'un digit de 0 à 9 !).

Il suffit alors de modifier le fichier /usr/share/java-package/oracle-j2re.sh (ou /usr/share/java-package/oracle-j2sdk.sh) pour ajouter [0-9] à la regexp du nom de l'archive.

Par exemple pour un JDK 7 sous Linux 64 bits:

        "jdk-7u"[0-9][0-9]"-linux-x64.tar.gz") # SUPPORTED
            j2se_version=1.7.0+update${archive_name:6:1}${revision}
            j2se_expected_min_size=180 #Mb
            j2se_priority=317
            found=true
            ;;

Pourquoi les paquets sun-java* ont été retirés des dépots Debian & Ubuntu

Depuis 2006 et le changement de license par Sun du JDK et du JRE pour une license DLJ (Distro License for Java) , les systèmes d'exploitation libres comme Debian et Ubuntu pouvaient proposer dans leurs dépôts les JVM et JRE publiés par Sun.

Maintenant, suite au rachat de Sun par Oracle, on revient à la case départ, à savoir que Sun n'autorise désormais plus la redistribution de sa machine virtuelle Java (non libre).

Les acteurs du libre, Debian, Ubuntu, ... ont donc supprimé de leurs dépots les paquets sun-java*, et c'est pour cela qu'au mois de décembre 2011 suite à une mise à jour sur Debian ou Ubuntu, on pouvait se retrouver avec openjdk à la place de la JVM de Sun sans trop comprendre pourquoi.

Ceux qui comme moi n'ont pas installé Java avec Synaptic mais à la main dans un répertoire utilisateur n'auront pas de soucis !

Erreurs de débutant en Java: fermer les fichiers !

Les développeurs Java débutants (j'en vois qui ont de l'expérience et qui continuent de faire cette erreur chaque jour ...) considèrent souvent qu'il est inutile de libérer les ressources allouées.

Comme il s'agit de Java et que le Garbage Collector veille, il est trop souvent considéré que la mémoire se libère de façon automatique, ce qui n'est que partiellement vrai.

Une des erreurs courantes consiste à ne pas fermer les fichiers ouverts, que ce soit en lecture ou en écriture.

Considérons la méthode suivante qui consiste à copier un fichier par bloc de 1024 octets sur un autre filesystem:

public static boolean copyTo(File src, File dest, boolean close)
throws IOException {
FileOutputStream out = null;
FileInputStream in = null;
try {
if (!src.exists())
throw new FileNotFoundException(src.getAbsolutePath());
if (dest.exists() || !dest.createNewFile())
return false;
out = new FileOutputStream(dest);
in = new FileInputStream(src);
int len = 1024;
int nread;
byte[] b = new byte[len];
for (;;)
if ( (nread = in.read(b, 0, len)) <= 0) break; else out.write(b, 0, nread); return true; } finally { if (close) { try { out.close(); } catch (IOException ioe) { } try { in.close(); } catch (IOException ioe) { } } } }

Le paramètre close permet de fermer ou non les flux ouverts (input et output).

Si on appelle cette méthode, par exemple 2048 fois avec un nom de fichier de destination qui change et le paramètre close à false, on obtient l'erreur suivante:

java.io.IOException: Too many open files
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:883)
at FileNotClosed.copyTo(FileNotClosed.java:36)
at FileNotClosed.main(FileNotClosed.java:17)

Et on n'arrive qu'à copier 510 fichiers, ce qui veux dire qu'on en a ouvert 2*510 soit 1020 fichiers, parce que le max open files défini par process sur cette machine Linux est de 1024:

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32768
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 32768
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Les autres fichiers ouverts le sont par la JVM elle même.

En conséquence de quoi, il est primordial de fermer TOUS les fichiers ouverts après leur utilisation, et ce de façon systématique dans le bloc finally afin que la fermeture soit faites dans tous les cas.

Evidemment si un System.exit() est appelé, le bloc finally correspondant lui ne le sera pas.

Ce genre d'erreur se voit tous les jours, et dans un serveur d'applications par exemple, cela fait des ravages !

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Mozilla Firefox 3.0.3 setup on linux Debian with Java enabled

Installation pre-requisistes for Firefox 3.0.3 on Linux Debian (Etch):

--> Login as root as installation is done in /opt
--> Install GTK 2.10 in /opt
--> Modify slightly the end of the script for JRE download or download it manually from www.java.com

#!/bin/sh

#
# Login as root
#
echo "Please Login as root"
su -

#
# Go to Mozilla Firefox install directory
#
cd /opt

#
# Download Mozilla Firefox Package
#
echo "Downloading Mozilla Firefox"
wget "http://download.mozilla.org/?product=firefox-3.0.3&os=linux&lang=fr"

#
# Extract Firefox Directory
#
echo "Extracting Mozilla Firefox"
bzip2 -d firefox-3.0.3.tar.bz2
tar -xvf firefox-3.0.3.tar
rm -fr firefox-3.0.3.tar

#Or
#tar -xjf firefox-3.0.3.tar
#rm -fr firefox-3.0.3.tar.bz2

#
# Create Firefox start script
#
echo "Creating Firefox start script"
cat > firefox/start-firefox.sh << EOF
#!/bin/sh
export LD_LIBRARY_PATH="/opt/gtk210/lib"
export MOZ_NO_REMOTE=1
/opt/firefox/firefox \$*
EOF
chmod a+x firefox/start-firefox.sh

#
# Download Java Runtime Environment
#
echo "Downloading Java JRE"
wget http://javadl.sun.com/webapps/download/AutoDL?BundleId=23103
echo "Installing Java JRE"
chmod u+x jre-6u7-linux-i586.bin
./jre-6u7-linux-i586.bin
rm -fr jre-6u7-linux-i586.bin

#
# Set up Java plugin for Mozilla Firefox
#
echo "Setting up Java Plugin for Firefox"
ln -s /opt/jre1.6.0_07/plugin/i386/ns7/libjavaplugin_oji.so firefox/plugins/

Correct Java installation for Firefox can be checked on http://www.java.com/fr/ or http://www.java.com/fr/download/installed.jsp

Heure d'été, Classe Date, JDK 1.5 et TimeZone

Alors que l'on est passé à l'heure d'été ce week-end, soit UTC+0200 au lieu d'UTC+0100, je me suis aperçu ce matin que le JDK 1.5 de Sun ne me donnait pas (plus en fait !) l'heure correcte ... alors que la machine elle avait bien changé d'heure, comme le confirmait Gnome et la commande date.

En fait, la classe Date de Java était restée à l'ancienne heure, contrairement à moi qui ai vu mon week-end écourté, mais bref.

En effet, Java tient compte du TimeZone, et un simple

new Date();

doit vous donner la date courante et tenir compte du TimeZone, et non vous donner la date GMT définie par nos amis Anglais.

La raison de ce problème est que le JDK 1.5 ne me donnait pas le TimeZone me correspondant. Au lieu d' "Europe/Paris" j'obtenais GMT+0100 soit le TimeZone de la semaine dernière.

TimeZone.getDefault().getID()=GMT+01:00

Pour remédier à ce problème, il suffit soit d'utiliser un JDK plus récent, c'est à dire un JDK 1.6, soit de modifier le TimeZone par programme comme suit:

TimeZone tz = TimeZone.getTimeZone("Europe/Paris");
TimeZone.setDefault(tz);

On peut également modifier la propriété "user.timezone" et lui affecter la valeur "Europe/Paris", par exemple sur la ligne de commande Java, via un -D.

Je n'ai pas testé toutes les versions de JDK 1.5, mais les dernières versions du JDK 1.5 (jdk1.5.0_14 et jdk1.5.0_15) ont toutes deux ce bug sous Linux.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Java 1.5: Utilisation des imports avec JMS

La facilité en Java consiste à utiliser des imports "génériques" du genre:

import java.util.*;

ou

import javax.jms.*;

.
Autre méthode possible, laisser Eclipse réorganiser les imports du fichier source Java.

Lorsqu'on utilise Java 1.5 sur du code Java écrit pour la version 1.4 voire 1.3 du JDK, on peut rencontrer l'erreur suivante à la compilation:

reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match

En effet, les classes java.util.Queue et javax.jms.Queue existent toutes les deux ... dans le JDK et comme j'ai mis les deux imports, j'obtiens une ambiguité et la compilation échoue (ce n'est pas un warning).

Personnellement, je préfère de loin spécifier au début du fichier source Java l'intégralité des imports dont j'ai besoin. Par exemple, dans un programme d'envoi et de réception de messages JMS:

import javax.jms.QueueConnectionFactory;
import javax.jms.QueueConnection;
import javax.jms.Session;
import javax.jms.QueueSession;
import javax.jms.Queue;
import javax.jms.QueueReceiver;
import javax.jms.QueueSender;
import javax.jms.MessageListener;

import javax.jms.Message;
import javax.jms.MapMessage;

import javax.jms.JMSException;

Comme cela, non seulement je sais exactement quelles classes Java j'utilise mais je vois également en un coup d'oeil que telle classe qui pourrait me poser un problème n'est pas utilisée dans mon implémentation.

Pour une fois, incitons les développeurs à être un peu moins "lazy" que d'habitude :-)

Note: L'erreur "reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match" survient sur le programme d'exemple JMS de Sun TransactedExample.java, qui avait été écrit avant Java 1.5 évidemment.

 Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Groovy 1.0 est sorti

Je viens de voir que la version 1.0 du langage Groovy est sortie hier.

Pour rappel, Groovy est un langage de script pour la plate-forme Java dont la syntaxe s'inspire de nombreux autres langages comme Ruby, Python ou Smalltalk.

Groovy peut être téléchargé sur le site de codehaus.

L'annonce de la sortie de Groovy par Guillaume Laforge est ici.

Sun annonce Java 6 (Java SE 6)

Sun Microsystems vient de sortir la version 6 de Java Plateform Standard Edition (Java SE 6).

Cette version 6 de Java, qui a mis deux ans à sortir des laboratoires de Sun, serait 30% plus performante que Java 5, et la nouvelle machine virtuelle de Sun mettrait moitié moins de temps à démarrer.

La nouvelle JVM (Java Virtual machine) de Sun s'adapte désormais à la plate-forme matérielle d'exécution, notamment aux caractéristiques du processeur.

Parmi les ajouts de Java 6, on peut citer l'interopérabilité avec les langages de scripts comme Javascript, PHP ou Ruby ainsi que le support des services Web, sans avoir besoin d'une plate-forme J2EE.

Par contre, il semble que Java 6 n'intègre pas pour l'instant le support du langage de script groovy.

Les développeurs et ingénieurs logiciels qui travaillent avec Java vont certainement faire des tests prochainement pour voir si les promesses de Sun Microsystems sont au rendez-vous.

Java 6 est disponible pour Solaris x86, Solaris x64, Windows ainsi que pour plusieurs distributions Linux (en format RPM pour Linux et Linux x64).

De plus, le code source du JDK SE 6 est disponible sur le site de Sun.

Enfin, le langage Java devrait être disponible en Open Source prochainement, d'après les dires de Sun.

Un très ancien bug non découvert jusque là

Dans un billet où je tirais à boulets rouges sur le Copier/Coller, je mettais en évidence les inconvénients de cette pratique trop répandue.

Une fois n'est pas coutume, j'ai corrigé la semaine dernière un bug qui date d'au moins 2 ans, sur une implémentation JMS, bug qui n'avait pas été encore découvert car la plupart des utilisateurs d'applications JMS (comme les autres d'ailleurs) utilisent le Copier/Coller à outrance !

Le problème était le suivant.

Si l'on fermait le contexte JNDI juste après les appels aux lookup() JNDI des queue et queue connection factory, les connexions JMS échouaient par la suite !

C'est à dire que les connexions JMS avaient besoin du contexte JNDI pour se connecter au queue manager JMS, ce qui est une erreur.

Si ce bug n'a pas été découvert plus tôt, c'est parce que la majorité des programmes d'exemples JMS ferment le contexte JNDI en même temps que les autres ressources de l'application JMS, et non après les opérations de lookup() JNDI, ce qui serait la manière logique de faire.

Donc, pour une fois, merci au Copier/Coller !

Cela dit, de manière générale, je préconise généralement de ne pas fournir de programmes d'exemples dans les livrables d'un logiciel, car, malgré les avertissements d'usage dans les cartouches d'entête des fichiers, les utilisateurs et programmeurs utilisent trop souvent ces programmes d'exemples comme templates de base à leurs développements.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

pop3/tcp server failing (looping), service terminated

Alors que je testais un applicatif Java, dont le but était de faire communiquer un serveur mail et un middleware orienté message, je me suis aperçu que le super serveur inetd s’arrêtait rapidement.

Plus possible alors d’accéder au serveur mail via le protocole POP3 avec JavaMail.

La raison du problème ? Le code utilisant JavaMail se connectait en permanence pour vérifier la présence de nouveaux messages sur le serveur mail, et comme aucun message n’était disponible, on recommençait encore et encore et sans timer !

Seulement voilà, inetd n’aime pas les connexions intempestives depuis le même processus, et s’arrête (par défaut) au bout de 40 connexions en une minute. inetd voit ce genre de cinématique comme une attaque.

Au crédit d’inetd: il ne laisse pas faire n’importe quoi !

Au débit de JavaMail, il n’est pas simple par défaut de savoir si des messages nouveaux sont arrivés sur le serveur, et le seul moyen de le faire est d’ouvrir de nouveau le Folder POP3 …

En fait, JavaMail n’y est pour rien, c’est le protocole POP3 qui n’offre aucune possibilité de savoir si de nouveaux messages sont arrivés.

Aussi la méthode hasNewMessages() de la classe javax.mail.Folder renvoie toujours false !

Cette limite de 40 connexions par minute est ancienne et un peu obsolète, vu la puissance actuelle des machines ; néanmoins il est possible de changer ces valeurs par défaut:

* En recompilant inetd après avoir changé les #define appropriés.
* En modifiant la configuration du service qui reçoit trop de connexions.

Pour modifier la configuration du service, on remplacera dans inetd.conf, la ligne correspondant au service pop:

pop-3 stream tcp nowait root /usr/sbin/vm-pop3d vm-pop3d -i

par

pop-3 stream tcp nowait.500 root /usr/sbin/vm-pop3d vm-pop3d -i

pour autoriser par exemple 500 connexions par minute.

Il faut ensuite redémarrer inetd:

/etc/init.d/inetd reload

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

De l’usage des programmes d’exemple

Un utilisateur m’appelle pour une question sur l’implémentation JMS dans le middleware orienté message sur lequel je travaille.

Il m’envoie un bout de code et me demande ce qui ne va pas dans son code, et pourquoi il perd des messages.

Je me rends compte que comme la majorité des exemples d’appels à un provider JMS que l’on trouve sur le net, sa session est non transactionnelle en AUTO_ACKNOWLEDGE.

Donc, si son applicatif s’arrête entre la réception du message et avant le traitement de ce dernier, le message est “perdu” puisque commité par le queue manager (AUTO_ACKNOWLEDGE !) et non traité par l’application !

Pourquoi est-ce que dès que les développeurs ont 15 lignes de code à écrire, il leur faut un exemple ?

Normalement, c’est leur métier d’écrire des programmes, ils ne devraient pas avoir des sueurs devant une page blanche !

L’exemple n’a rien de mauvais en soi, mais ce que je lui reproche, c’est l’utilisation qui en est faites la plupart du temps: si on prend un exemple pour aller plus vite dans son travail, sans prendre le (peu de) temps nécessaire pour savoir ce que l’exemple fait ou ne fait pas, au final, au lieu de gagner du temps, on en perds !

Et beaucoup plus que ce qu’on pensait gagner initialement.

Utiliser un exemple est une bonne chose, mais pas si on l’utilise comme une boite noire et surtout sans réfléchir.

Après, l’étape suivante, c’est de poster un message sur les forums: “voilà, je fais ça, ça a l’air bon mais ça ne marche pas … Est-ce quelqu’un peut m’aider ?” ….

Enfin, malheureusement, les exemples sont rarement faits pour résoudre précisément votre problème, sinon la vie serait trop belle, et puis il faut lire (un minimum) la Javadoc JMS.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
JavaMail en IMAP avec un serveur Exchange

JavaMail en IMAP avec un serveur Exchange

Accéder à un compte IMAP avec JavaMail ne pose à priori pas de problèmes.

J’étais en train de tester un bridge entre un MOM JMS et des serveurs Mails divers et variés, quand je me suis mis à tester sur Exchange, le serveur de Microsoft.

Sur Exchange, surprise à l’ouverture du Folder IMAP, la mailbox n’existe pas !
Ah bon, pourtant, j’ai un user valide et je suis connecté.

La raison de l’erreur dont la stack suit:

Exception occurred: javax.mail.MessagingException: A2 NO There is no replica for that mailbox on this server.;
nested exception is:
com.sun.mail.iap.CommandFailedException: A2 NO There is no replica for that mailbox on this server.
at com.sun.mail.imap.IMAPFolder.doCommand(IMAPFolder.java:2125)
at com.sun.mail.imap.IMAPFolder.exists(IMAPFolder.java:406)
at com.sun.mail.imap.IMAPFolder.checkExists(IMAPFolder.java:280)
at com.sun.mail.imap.IMAPFolder.open(IMAPFolder.java:779)

est que le serveur Exchange me redirigeait vers un deuxième serveur pour m’authentifier, et utilisait le premier (celui que je lui avais donné à la connexion) pour ouvrir la INBOX.

Manque de chance, la INBOX n’existe (normal) que sur le deuxième serveur (celui que j’ignorais) !

Moralité, si vous rencontrez la belle erreur “There is no replica for that mailbox on this server", pensez à mettre les traces IMAP et regardez si vous ne voyez pas passer un autre nom de serveur ; c’est celui-ci qu’il faudra utiliser.

Les développeurs de chez Microsoft pourraient étoffer le message d’erreur, par exemple: “you’ve been redirected for authentification, please check serveur name” !

Les devéloppeurs ne pensent jamais assez à l’utilisateur final …

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple