Archives par mot-clé : java

Netbeans & Unity : ça marche presque tout seul

netbeans-ayatana-header

Dans un précédent article, je partageai un plugin Netbeans pour profiter du menu global du bureau Unity d’Ubuntu. Et bien chers amis, je vous le dis : n’installer plus ce plugin.

Ne vous inquiétez pas, je ne viens pas vous annoncer une nouvelle faille de sécurité dans ce plugin (c’est à la mode en ce moment). C’est juste que son utilisation n’est plus nécessaire car les dépôts officiels d’Ubuntu contiennent la librairie Ayatana qui s’appliquera à tout vos programme Java. Et oui, vous m’avez bien lu : « à tous vos programme Java ».

Si sur votre poste, on peut trouvez un browser Cassandra écrit en Java, un serveur bouchon SMTP écrit en Java, tous profiteront du menu centralisé et surtout de la recherche dans les menus.

Elle est pas belle la vie ? Comment on fait maintenant ?

Et bien rien si vous êtes passé à Ubuntu 15.04, c’est actif automatiquement.

Et pour les autres, restez concentré, ça va aller vite :

sudo add-apt-repository ppa:danjaredg/jayatana
sudo apt-get update
sudo apt-get install jayatana

Bien entendu, ça fonctionne aussi pour les non développeurs, ça fonctionne aussi avec jDownloader.

BeanMill ou une autre vision des logs

blog_header_beanmill
Ah les fichiers de logs, les rotations de fichiers, les commandes tail sous Windows. Un fichier de log, c’est bien sur un serveur mais sur le poste du développeur, c’est tout bonnement impraticable. Et c’est en rouvrant mon Netbeans préféré que j’ai découvert le plugin BeanMill.

Je n’ai pas compris du premier coup mais c’est en fait très simple. Lorsque le plugin est installé, l’IDE se comporte alors comme un serveur de log. Finalement, il n’y a plus qu’à modifier la configuration des logs sur l’application que nous sommes en train de façonner. Par exemple, si il s’agit d’une configuration log4j, ajouter l’appender suivant au rootLogger pour voir la magie opérer :

# Log Event appender
log4j.appender.sockets=org.apache.log4j.net.SocketAppender
log4j.appender.sockets.remoteHost=localhost
log4j.appender.sockets.port=4445
log4j.appender.sockets.locationInfo=true

log4j.rootLogger=INFO, sockets

Dorénavant, l’onglet BeanMill présentera les évènements de log et nous pouvons les filtrer en fonction du contenu de chaque message, nous pouvons affecter des niveaux de trace différents en fonction des packages et le tout dans un rendu coloré qui saute aux yeux.

beanmill

Je vous préviens, l’utilisation de ce plugin est fortement addictif mais sans effet secondaire sur la santé.

Ajouter un JDK dans Ubuntu

OpenJDKvsOracle

En suivant le fil de mes articles, vous devriez savoir que dispose d’un serveur dédié sous Ubuntu. Sur ce serveur , j’héberge un serveur Glassfish. Jusqu’à maintenant, je me suis obstiné à faire tourner ce conteneur JEE avec l’OpenJDK qui se trouve par défaut dans les dépôts officiel de mon système d’exploitation.

Aujourd’hui, je n’en peux plus, après de multiples crash système de la JVM (tous les 3 jours environs). Je ne possède pas une analyse fine de la cause mais avant de me lancer dans une analyse des fichiers « core » générés, je vais simplement tenter d’utiliser le JDK officiel d’Oracle. Même si la base de ce dernier est le premier, ce dernier peut contenir un patch pour ma situation…qui sait !

Télécharger le JDK

Je ne pensais pas que ce serait une difficulté mais ce n’est pas aussi évident de télécharger le JDK depuis le site d’Oracle directement sur le serveur avec la commande  » wget ». En effet, avant de pouvoir télécharger tout fichier, il faut passer par la case d’acceptation de la license Oracle. La parade à cet obstacle passe par l’utilisation d’un analyseur de de requête HTTP (comme Firebug sous Firefox).

Dans le navigateur, avant de lancer effectivement le téléchargement de l’archive, le serveur d’Oracle lance une série de redirection :

Capture du 2013-03-10 20:13:28

La dernière URL est de la forme « wget http://download.oracle.com/otn-pub/java/jdk/7u17-b02/jdk-7u17-linux-x64.tar.gz?AuthParam=1362942876_4bc4e1d256685c05747a32db3ca2d8ac ». C’est cette URL qu’il faut reprendre avec « wget ».

Installer le JDK

En soit, l’installation n’est pas compliqué, il suffit de décompresser l’archive téléchargée dans le répertoire de son choix (au hasard « /usr/lib/jvm »). Mais pour finir l’installation proprement, il est important d’ajouter le nouveau JDK dans la configuration des alternatives pour l’exécutable « /usr/bin/java ».

Sous Linux, la commande « alternatives » permet de maintenir des versions différentes pour des liens symboliques et de changer rapidement la cible du lient. L’ajout d’un JDK se fait donc simplement au travers de la commande :

update-alternatives --install /usr/bin/java java \
                /usr/lib/jvm/jdk1.7.0_17/bin/java 2000

Pour vérifier la bonne prise en compte, rien de plus simple, la commande ci-dessous vous donnera la liste des alternatives

update-alternatives --config java

Ce sites m’ont aidés à retrouver ces commandes et à comprendre de quoi s’agissait:
http://linuxdrops.cAom/install-glassfish-with-jdk-7-on-centos-rhel-fedora-debian-ubuntu/
http://linux.about.com/library/cmd/blcmdl8_alternatives.htm

Redmine, Rails, Warbler, JBoss : la magie de JRuby

J’ai toujours regreté de ne pas trouver un outil de bug tracking Open Source et sympa dans l’écosystème Java. Certes, il y a bien Jira qui offre une licence au projet Open Source (je trouve que c’est d’ailleurs une très bonne démarche de leur part qui permet de conserver leur business model tout en soutenant la communauté). Mais c’est bien loin de mon business model personnel composé à 80% de vaporware.

De plus, j’ai toujours été attiré, intrigué, piqué au vif par Redmine. Les quelques heures de prise en main que j’ai pu en faire m’ont fait très bonne impression. Il n’a pas l’air aussi personnalisable que Jira mais l’interface respire la simplicité et l’évidence, je ne me suis jamais posé de question sur ce que je faisais.

Je désespérais donc de trouver un outil équivalent à déployer sous mon JBoss ou mon Tomcat et j’en venais à la conclusion, mainte fois partagé, que finalement on est jamais mieux servi que par soi-même. Et là, je suis tombé sur cet article et ma vie a changée :

http://www.javacodegeeks.com/2012/02/redmine-installation-getting-started.html

Et toute cette magie repose sur Warbler un gem à installer qui permet d’encapsuler les applications Rails dans un package war. Le tout utilisant JRuby pour l’exécution. Et je garantie que les explications données dans l’article ci-dessus fonctionne à merveille pour un Redmine 1.3.1 déployé sur un JBoss 7.1.0. Et pour avoir un peu plus de détail sur le fonctionnement de Warbler :

http://jrubyist.wordpress.com/2009/10/15/using-jruby-warbler-rake-to-deploy-rails-apps-to-jboss/

Back to bascis of JSTL

En ce moment, je travaille sur une mini application permettant de collecter des données de performances de mon application mesurées pendant l’exécution de mes tests Selenium. Pour effectuer les mesures, je me base sur dynaTrace Ajax Edition qui installe un plugin sur les navigateurs contrôlés par Selenium et envoi les données à mon application qui se chargera de stocker les données et offre un écran pour les restituer.

J’ai voulu la faire simple, en utilisant un projet de Servlet et JSP tout ce qu’il y a de plus simple. Pour que ma page JSP soit belle, j’ai aussi voulu utiliser les JSTL. Et je dois bien l’avouer, cela a nécessité un rafraîchissement sur les versions de JEE et les compatibilités avec les versions de JSTL.

Qu’est ce que JSTL ?

JSTL est l’acronyme pour Java Standard Tag library. Elle offre 2 choses :

  • comme son nom le laisse entendre, une bibliothèque de taglib (pour manipuler les variables, contrôler son exécution par des tests et des boucles, …)
  • les Expression Language qui permet d’écrire des mini scripts Java dans une syntaxe ${ // mon code Java }

Les versions de JSTL

Bien entendu, JSTL est une spécification qui a évolué au cours du temps. Voici, ici les correspondances de version JEE :

Servlet JSP JSTL JEE
2.5 2.1 1.2 5
2.4 2.0 1.1 1.4
2.3 1.2 1.0 1.2

Avec la version 1.2 de JSTL les Expression Language ne pouvaient être utilisées qu’au travers de la balise c:out. Pour les versions suivantes, les EL peuvent être utilisées n’importe où dans la page JSP.

Il faut donc être vigilant. Votre projet doit être dans une bonne version. Si vous utilisez Maven, votre fichier pom doit contenir les bonnes références :

<dependency>
     <groupId>javax.servlet</groupId>
     <artifactId>servlet-api</artifactId>
     <version>2.5</version>
     <scope>provided</scope>
</dependency>

Votre web.xml doit avoir la bonne entête. Pour une version 2.5 de Servlet :

<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">
...
</web-app>

Il faut également être vigilant sur la manière dont on référence les taglib dans les JSP. En version 1.0, il faut utiliser la syntaxe suivante :

<%@taglib uri="http://java.sun.com/jsp/core" prefix="c" %>

Pour les versions plus récentes, voici la ligne :

<%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>

Implémentation de JSTL

JSTL est une spécification. Pour fonctionner, il faut disposer d’une implémentation. Heureusement la plupart des fournisseurs de serveurs d’application (comme Glassfish ou JBoss) fournisse une implémentation.

Mais ce n’est pas le cas de Tomcat. Et pour remédier à ce problème, il y a 2 solutions, soit vous récupérer des librairies d’implémentation et vous les ajouter dans le répertoire lib d’installation de votre Tomcat. Soit vous ajoutez la dépendance ci-dessous dans votre fichier pom :

<dependency>
     <groupId>javax.servlet</groupId>
     <artifactId>jstl</artifactId>
     <version>1.2</version>
</dependency>

La plupart de mes informations proviennent de ce post : http://www.mularien.com/blog/2008/04/24/how-to-reference-and-use-jstl-in-your-web-application/