J'ai fais beaucoup de biblio dans ma thèse, et plutôt que d'ajouter un lien web, un DOI, ou autre dans mes BIBTEX, je sauvegarde tous les PDF dans un répertoire en local. Ce qui me permet d'utiliser Beagle pour fouiller dans ma biblio pour retrouver un truc que j'ai lu. Mais, le client Beagle par défaut sous GNOME quoique super bien fait, commence à me faire râler un brin:

1. pourquoi diable n'affiche t-il pas une liste verticale déroulante (avec tous les résultats, plutôt que le machin page par page existant).
2. surtout: pourquoi n'affiche t-il pas les chemins d'accès aux fichiers dans la liste, il faut cliquer sur un résultat pour voir sa localisation... >_<
3. pourquoi ne plus afficher le nom du fichier mais afficher à la place le champ title des metadata quand elles sont disponibles (XMP), dans le cas des articles scientifiques, la méta title n'est jamais remplie, c'est presque toujours "title" ou "article", d'où: afficher tout simplement le nom du fichier, metadata ou pas, ce ne serait pas superflu.

Et sinon, c'est dommage la Web service interface de Beagle est maintenant désactivée...

Mémo de l'installation sur mon serveur: Je ne veux pas installer les paquets tomcat-5.5, tomcat5.5-admin et tomcat5.5-webapps présent dans les dépôts Ubuntu. Car avec ces paquets:

• le fichier de configuration du service tomcat est /etc/default/tomcat.
• les fichiers server.xml et web.xml se trouvent dans /etc/tomcat, mais le reste des fichiers de configuration sont dans /var/lib/tomcat.
• les webapps sont dans /var/lib/tomcat/webapps, mais l'application Tomcat se trouve dans /usr/share/tomcat.
• on a un script de gestion du service /etc/init.d/tomcat.

Cette intégration dans le système peut être intéressante sous certains abords, mais je n'en ai pas l'utilité et puis, c'est surtout pas pratique du tout. Il est beaucoup plus propre d'installer manuellement un Tomcat dans /home/tomcat, et donc sur la partition /home du système sous l'utilisateur et le groupe www-data. Ainsi, ça ne pourri pas /usr, et de plus les applications Web à déployer peuvent être volumineuses, ou si une application Web écrit des données dans son webContent (le répertoire où elle est déployée), c'est pas très pro. sans doute, mais c'est pratique. Pour créer un service système pour un Tomcat installé manuellement, il suffit d'écrire un fichier /etc/init.d/tomcat tel que: Il faut disposer les droits idoines sur le fichier: Puis l'ajouter aux scripts systèmes: L'étape suivante pour une installation qui va bien, est d'utiliser le connecteur Tomcat jk_connector. Pour Apache, c'est le module mod_jk pour accéder à Tomcat depuis Apache, et ainsi l'abstraire du port 8080 pour accéder aux applications web déployées sous Tomcat. Ce qui en plus d'être plus simple et pratique dans l'écriture des URL, peut s'avérer nécessaire, par exemple si vous faites un appel à une servlet depuis un script PHP qui est lui, hébergé sur un autre serveur sur lequel la création d'une socket sur un port autre que 80 est interdit (par exemple, les serveurs de free.fr). Pour mod_jk, installer le paquet libapache2-mod-jk, et éditer le fichier /etc/apache2/mods-available/jk.load: Les JkMount sont les points de montages des applications Web que vous voulez monter. Editer ensuite le fichier /etc/apache2/workers.properties : Il ne suffit plus qu'a redémarrer Apache. Cette configuration fonctionne bien, mais n'est pas sensitive aux sous-domaines éventuels de votre configuration d'Apache, ainsi http://trevize.net/Bouquinoscope et http://njames.trevize.net/Bouquinoscope pointe vers la même webapp Tomcat. Une solution assez simple est de créer un VirtualHost pour notre Tomcat, par exemple http://webapps.trevize.net, pour cela éditer le fichier worker.properties: Commentez les points de montage JkMount indiqués précédemment dans /etc/apache2/mods-available/jk.load. Pour finir, il suffit d'ajouter le VirtualHost en éditant un fichier /etc/apache2/sites-available/webapps: Il ne suffit plus qu'a monter le site avec a2ensite webapps, et redémarrer Apache. Configuré ainsi, Tomcat est accessible uniquement sur http://webapps.trevize.net. Pour que l'accès aux webapps sur le site soit plus eye-candy, un coup d'URL-rewriting avec le module rewrite pourra par exemple faire pointer http://trevize.net/Bouquinoscope vers http://webapps.trevize.net/Bouquinoscope.

J'ai expérimenté le problème intéressant des modes headless/headful en Java en codant une application de crawling de GoogleImage. Mon application crawl les pages de résultats de GoogleImage, télécharge les images proposées dans les résultats pour les stocker en local, et renvoie une page contenant des miniatures des images retrouvées. Au moment de stocker les images, j'utilise le programme convert du projet ImageMagick pour les retailler, et JIU, Java Imaging Utilities, pour obtenir leur résolution. Le projet est une servlet sur une machine distante où X est installé, mais est tomcat est lancé dans une session non X. JIU semble avoir besoin de la variable DISPLAY, car l'exception suivante est levée: D'après ce forum, c'est un problème rencontré aussi avec JMF, la solution est de préciser la propriété système demandant à Java d'utiliser le mode headless: ou seulement pour le Toolkit AWT: mais cela ne peut fonctionner dans mon projet car j'utilise dans mon code la classe ToolkitLoader de JIU qui, apparement, nécessite un mode headful. Du coup, pour obtenir la résolution j'utilise un java.awt.Image obtenu par ImageIO en mode headless. Pour plus d'info sur les mode headless et headful de Java, voir ce tutoriel.