Guillaume VIEL :: java jee tomcat linux

Aller au contenu | Aller au menu | Aller à la recherche

mardi 23 février 2010

Ordinateur portable sans windows préinstallé

Si si ça existe! Nous avons cherché longtemps mais nous avons trouvé :

un portable sans OS!

En fait c'est Zefyris notre intégrateur préféré à qui nous achetons habituellement notre matériel informatique. Il propose depuis plus d'un an des portables sans OS, et personnalisable (mémoire, carte graphique, wifi etc.). J'ai tenté une première expérience en achetant une première machine : écran impeccable, bonne connectique, wifi qui marche bien (après quelques tâtonnements au début sur une version d'Ubuntu) etc.

Convaincu, nous avons équipé l'entreprise avec ces laptops. Du coup, windows a définitivement été éliminé de nos bureaux!

Voici la configuration choisie :

Lire la suite...

vendredi 19 février 2010

Premier et dernier noeud d'un itinéraire non fermé de plusieurs segments, liste ordonnée des segments

Ça y est c'est décidé : je vais commencer à écrire quelques billets sur les SIG et plus particulièrement sur le stockage et la manipulation des données d'un Système d'Informations Géographiques.

Le "debug" des données géographiques est une tâche souvent délicate, surtout lorsque l'on doit manipuler des notions comme des axes routiers ou bien des itinéraires. Un réseau routier, par exemple, est modélisé comme un graphe orienté entre un ensemble de sommets (noeuds) reliés ou non entre eux. Le coût d'une liaison entre sommet est généralement une distance qui n'est autre que la longueur du tronçon routier qui relie ces sommets. Rien de sensationnel jusque là.

Mais lorsqu'il faut contrôler et vérifier que le graphe est "cohérent" et qu'il correspond bien à ce que l'on souhaite, les problèmes commencent. En effet, des éditions manuelles du graphe sont souvent nécessaires : corrections de géométrie, découpage, fusion de tronçons etc. pour obtenir le graphe souhaité. Ceci entraîne fatalement des erreurs. De plus, les données des divers fournisseurs de données géographiques ne sont pas exemptes d'erreurs! Je dirais même qu'elles en sont truffées!

Lire la suite...

vendredi 23 octobre 2009

Les 7 péchés capitaux de Windows 7


dimanche 21 juin 2009

Statistiques Hibernate et EHCache via JMX grâce à Spring

Récemment, chez un client, nous avons dû mettre en place un cache de données pour améliorer les performances de l'application. Même si l'on peut attendre des gains de la mise en place d'un cache de données EHcache, encore faut il affiner le paramétrage en fonction de l'utilisation réelle de l'application. La seule manière de faire est d'avoir des statistiques sur le cache et les requêtes envoyées à la base de données. Mode d'emploi.

Lire la suite...

mercredi 10 juin 2009

Hibernate sans modèle de données avec du SQL natif et la méthode aliasToBean

Chez un client, je découvre dans un bean des getters / setters en doublon : getMaVariable() et getMAVARIABLE(). Quelle horreur!

Le client m'explique que l'équipe de développement a eu des problèmes avec les noms de colonne Oracle lors de la transformation vers un Bean avec la méthode aliasToBean d'Hibernate, car Oracle renvoit systématiquemen des noms de colonne en majuscule... Les getters / setters ne sont alors pas trouvés.
J'ai finalement trouvé comment remédier au problème et je vous fais profiter de la solution.

String q = "SELECT axe, num_route AS numRoute, pr AS prStart, prfin AS prEnd FROM GRAPHE_AXE WHERE id_ech = :idEch";
SQLQuery hq = session.createSQLQuery(q).addScalar("axe").addScalar("numRoute").addScalar("prStart",Hibernate.DOUBLE).addScalar("prEnd",Hibernate.DOUBLE);
List<AxeRange> axeRanges = (List<AxeRange>) hq.setLong("idEch", idEch).setResultTransformer(Transformers.aliasToBean(AxeRange.class)).list();


La réponse est dans ce post : http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg01043.html
C'est plus un pb lié à la base de données qu'Hibernate

a) mettre les alias portant le même nom que les membres du bean dans la requête SQL
b) utiliser addScalar sur la SQLQuery initiale avec le même nom d'alias mais en case sensitive (correspondant aux membres du bean résultat): de cette façon un mapping sera fait entre le nom donné dans addScalar et l'alias majuscule renvoyé par Oracle
c) éventuellement forcer aussi les types dans addScalar (pour éviter de récupérer des BigDecimal sur des valeurs entières!)
d) utiliser aliasBean comme d'habitude

Sources : pour l'utilisation des query natives dans Hibernate cf. http://docs.jboss.org/hibernate/stable/core/reference/fr/html/querysql.html

JVM 1.5.0_10 crash en mode remote debugging

Apparemment il est possible de faire crasher très simplement une JVM en mode debug. Je viens de le constater sur un serveur Tomcat qui était en mode debug (cf billet sur remote debugging tomcat) sur le port 8000, il suffit tout simplement de lancer une requête HTTP sur celui-ci pour faire planter la JVM :

ERROR: transport error 202: handshake failed - received >GET / HTTP/1.1< - excepted >JDWP-Handshake< ["transport.c",L41]
JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error

Il est donc vivement conseillé de ne pas mettre vos serveurs en production en mode debug... On vous aura prévenu...

Le bug est connu http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6339385


jeudi 4 juin 2009

VirtualBox 2.2 sous Debian lenny

Après avoir utilisé VMWare pour tester des architectures, qemu pour mettre en place des systèmes légers sous OpenBSD, j'ai regardé VirtualBox puisque tout le monde en parle...

Voici une "quick install" qui permet d'avoir rapidement un environnement fonctionnel.

Lire la suite...

jeudi 17 juillet 2008

Equivalence et différences OpenBSD 4.3 et Debian Etch 4.0

Dans le devoir d'installer du matériel réseau destiné à gérer le trafic, j'ai dû me pencher un peu plus sur OpenBSD  4.3 réputé fiable et sécurisé. Le seul problème est que lorsqu'on est habitué à un système, on a beaucoup de mal à en changer... Il faut tout réapprendre.

Dans le but d'accélérer mon apprentissage avec le "poisson piquant" (OpenBSD) et éviter de sans arrêt chercher, j'ai commencé à constituer une sorte de mémento permettant de passer des commandes Debian au commandes OpenBSD. J'espère que cette liste intéressera les plus curieux d'entre vous et facilitera le grand saut pour aller voir ce que donne OpenBSD.

Ma première impression est que le système est certes moins étoffé en terme de packages mais les outils présents sont très puissants! Je peux d'ailleurs citer ce qui m'a fait venir à OpenBSD : Packet Filter (alias PF), CARP et pfsync .

J'essayerai de mettre à jour ce mémento au fur et à mesure de mes découvertes. N'hésitez pas à m'envoyer vos corrections et suggestions afin que la liste s'étoffe.

PS: si certains d'entre vous savent comment faire des tableaux proprement dans Dotclear à la sauce Gandi, ça m'intéresse... car je crois qu'aucun thème ne prévoit les tableaux dans les billets!

Lire la suite...

mercredi 16 juillet 2008

Ubuntu 8.04 (Hardy Heron) : son Firefox 3 n'aime pas l'interface d'admin de la Livebox...

Toi qui me lit, tu te reconnaitras peut-être dans ces propos. Combien de fois as tu déjà été acteur de cette scène :
- alors tu travailles dans quoi?

- euh... dans l'informatique... pourquoi?
- ah super, tu vas pouvoir m'aider : j'ai un problème avec mon ordinateur : y a l'internet qui marche plus!
- :((

Parfois c'est de ton propre chef que tu vas aider tes proches pour résoudre leurs tracasseries informatiques.
Me voilà donc en train de configurer une nouvelle machine, un portable, sous Ubuntu 8.04 (Hardy Heron). L'installation se déroule plutôt bien, mais les problèmes arrivent avec le wifi et le fameux driver iwl3945 qui remplace l'ancien driver ipw3945 (qui marche très bien sur mon portable). Du coup, la led ne fonctionne plus, un appui malencontreux sur le "kill switch" (bouton wifi en haut du clavier) fait qu'il reste activé (donc pas de wifi) après le reboot etc. Bref
Ensuite, j'essaye d'accéder à la livebox comme d'habitude en me connectant à la page d'admin et juste après avoir saisi login et mot de passe, pouf! firefox te dit que le serveur a coupé la connexion!? En fait, l'interface de la livebox semble être non conforme au W3C et firefox 3 n'aime pas ça du tout. Mais alors pas du tout... La seule solution a été de désinstaller Firefox 3 et remettre Firefox 2 pour pouvoir accéder à l'interface d'admin de la livebox... :(

Là je dis bravo aux développeurs de l'interface de la livebox...

mardi 13 mai 2008

Flex : HttpService qui ne se rafraichît pas!

Comme je le disais dans un billet précédent, j'expérimente Flex avec J2EE sur une application d'administration de données.

L'architecture de l'application est assez simple : les composants flex font appel à des servlets Struts renvoyant des messages XML simple par l'intermédiaire des HttpService flex. Il m'est arrivé d'avoir un appel à un HttpService ne mettant pas à jour un arbre (composant Tree). Croyant d'abord à un problème de cache côté Hibernate, je me suis aperçu qu'en fait la servlet n'était pas du tout appelée!!! Il y avait donc un problème de cache au niveau Flex. En cherchant d'abord une erreur au niveau du code flex, je me suis aperçu que tout semblait correct : en fait le problème vient du contrôle du cache du navigateur!

Après quelques recherches, j'ai pu découvrir plusieurs solutions possible:

  • mettre le header HTTP suivant "Cache-control : no-cache, must-revalidate" dans la réponse de la servlet ou JSP (c'set celui que j'ai essayé et qui fonctionne très bien)
  • ou bien le header "Cache-control : private"
  • ou bien le header "Cache-control : no-store" (à essayer si private ne fonctionne pas)
J'ai essayé la première solution qui fonctionne à merveille. Il suffit d'ajouter ça <% response.setHeader("Cache-control","no-cache, must-revalidate"); %> en entête de JSP. On peut aussi l'intégrer dans un filtre de servlet si l'on veut appliquer ce header partout.
Le même type d'erreur peut aussi se produire si l'on oublie de mettre l'attribut contentType="application/xml" sur le tag flex HttpService.

Source : http://flexonblog.wordpress.com/2007/12/20/httpservice-not-refreshing-cache-control-problem/

jeudi 20 mars 2008

Installation Linux Debian par réseau

Il y a quelques temps, j'ai dû mettre en place un serveur permet d'installer des machines par boot réseau. En effet, pour des machines en salle blanche il est difficile d'aller y insérer un CD-rom d'install de la dernière Debian Etch... Avec un KVM IP il est cependant possible d'accéder à une machine distante comme si on avait l'écran, clavier et souris à portée de main. Ayant alors accès au BIOS de la machine, on peut à loisir modifier son mode de boot et donc choisir le boot sur carte réseau (boot PXE)...

La mise en place comporte 3 étapes :

  1. la mise en place d'un serveur DHCP
  2. la mise en place d'un serveur TFTP (Trivial FTP)
  3. l'installation des dernières images de boot sur le serveur TFTP

Lire la suite...

Monitoring JVM Tomcat 5 avec jconsole, tunnel SSH et firewall...

Dans billet du 16 mars je présentais un monitoring java avec VisualGC. En réalité, cela n'était qu'une mise en bouche par rapport à ce qui suit... En effet, jconsole, l'outil fournit en standard dans le JDK Sun a aussi tout ce qu'il faut pour réaliser un monitoring Java. Il n'est disponible qu'à partir de java 5.
En fait jconsole est utile en phase de développement. Pour un monitoring persistent, il faudra plutôt s'orienter vers des solutions comme Munin par exemple qui permet une collecte et historisation des données dans le temps, avec surtout le stockage de ces données. Toutes les données jconsole sont perdues lors de l'arrêt de la JVM. Je vais présenter ici un nième exemple de monitoring de Tomcat par jconsole en connexion non sécurisée, Dans l'entête de votre bin/catalina.sh mettez ceci (les lignes en commentaire correspondent justement à celle qui seraient susceptibles de faire marcher le SSL) :

JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=8889"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false" echo $JAVA_OPTS

jmxremote.authenticate=false : permet d'indiquer que l'on ne veut pas utiliser le fichier de password (jmxremote.password.file)
jmxremote.port=8889 : indique le port sur lequel on va se connecter avec jconsole
jmxremote.ssl=false : désactive le SSL

Ensuite, sur un client disposant d'un JDK on peut lancer jconsole comme suit :
$ jconsole mytomcathost:8889 &


Je lance un appel à ceux ou celles qui auraient réussi une connexion remote en SSL entre jconsole et le serveur à monitorer, car, oui, je l'avoue, mes nombreux essais en suivant scrupuleusement la doc Sun, que ce soit sous linux, voire sous windows (si! si! je passe de temps à autre sous cet OS...), n'ont jamais abouti! Et après de nombreuses recherches, aucun article sur internet ne semble présenter une solution qui fonctionne avec SSL. Si vous avez la solution je suis preneur : envoyez moi l'article! Les lignes suivantes seraient à ajouter :

#JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.password.file=/home/tomcat/jmxremote.password"
#JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl.need.client.auth=true"
#JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=/home/tomcat/.keystore"
#JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStorePassword=changeit"

* UPDATE 15/11/2008 : aurais-je oublié ceci : com.sun.management.jmxremote.registry.ssl=true ??? *

Pour contourner ce problème ainsi que la lourdeur de mise en oeuvre d'une connexion SSL (génération des certificats), on peut utiliser sur une plateforme de type linux d'autres outils qui peuvent prendre en charge la sécurité. Parmi les alternatives possibles, seul le tunneling SSH (avec échange de la clé publique vers le serveur cible) pourra fonctionner, moyennant quelques manipulations manuelles supplémentaires. Car en réalité, ceci n'est pas aussi simple qu'il n'y parait. Si l'on exécute les commandes suivantes sur la machine client :

ssh -L18889:localhost:8889 my.remote.tomcat.host
jconsole localhost:18889

on s'aperçoit en fait que cela ne fonctionne pas... Eh oui : côté serveur 2 ports supplémentaires aléatoires de valeur N et N+1 sont en écoute pour le RMI registry en plus du port jmxremote.port :

$ netstat -tlnp | grep java
tcp6 0 0 ::ffff:127.0.0.1:8006 :::* LISTEN 5374/java
tcp6 0 0 :::8889 :::* LISTEN 5374/java
tcp6 0 0 :::8009 :::* LISTEN 5374/java
tcp6 0 0 :::8080 :::* LISTEN 5374/java
tcp6 0 0 :::40882 :::* LISTEN 5374/java
tcp6 0 0 :::40883 :::* LISTEN 5374/java

jconsole essaye alors de se connecter sur les ports N=40882 et N+1 en localhost sur la machine cliente alors qu'il accède bien grâce à SSH par port forwarding au port 8889! Si vous êtes pressé, la solution consiste à créer 2 tunnels SSH supplémentaires vers ces ports :

ssh -L40882:localhost:40882 my.remote.tomcat.host
ssh -L40883:localhost:40883 my.remote.tomcat.host

Cette méthode n'est pas très "propre", nécessite des opérations manuelles pour trouver les ports dynamiques dès que vous redémarrez votre serveur et ne fonctionnera pas dans un environnement avec certaine configuration de firewall (il faut aussi ajouter -Djava.rmi.server.hostname=localhost au niveau serveur)...

J'ai finalement trouvé sur un des blogs Sun un article intéressant à ce sujet : Connecting Through Firewall Using JMX - Without modifying the server application

Dans cet article Daniel Fuchs explique comment créer son propre JVM agent auquel on pourra passer en option un port fixe.

Liens : Monitoring and Management Using JMX | Monitoring Applications through a Firewall | Keytool documentation

Une exploration en profondeur de l'art de la programmation shell (bash)

Je pense que c'est une des meilleures sources sur le net :
Guide avancé d'écriture des scripts Bash
L'exploration de ce langage se révèle très utile au quotidien... surtout pour ceux qui ont à administrer des serveurs d'application java.

mercredi 19 mars 2008

Remote debugging avec Eclipse d'une application web sous Tomcat

Le débogage d'application web est pénible et qui n'a pas été usé par l'utilisation intensive de traces qui au final n'apportent rien, si ce n'est de pourrir un peu plus l'application et la rendre encore moins performante qu'avant...
Une des solutions pour remédier au problème est probablement le débogage à distance. Celui qui concernera le plus de monde sera probablement le débogage d'une application web sous Tomcat. Elle est très simple à mettre en place. Il suffit d'activer JPDA au niveau de la JVM qui lance le conteneur java et d'indiquer le port sur lequel le client de débogage (Eclipse) pourra se connecter.
Les options JVM sont généralement les suivantes :

Lire la suite...

mardi 18 mars 2008

Monitoring JVM Sun avec jvmstat et VisualGC

Sun propose quelques outils pour monitorer la JVM : jstatd, jvmstat et visualGC. Cela reste rudimentaire par rapport à d'autres outils comme jconsole mais cela a le mérite d'exister! Le principal intérêt d'utiliser encore cet outil est qu'il fonctionne pour les vieilles JVM version 1.4! Cet outil n'est pas packagé directement dans le JDK. Voici comment mettre en place cette techno rapidement en Java 1.4, Java 5 ou Java 6 entre une machine linux sur laquelle réside l'application java à monitorer et un poste de travail windows ou linux

Lire la suite...

dimanche 16 mars 2008

Ouverture du blog

Voilà c'est fait...
Ceci sera probablement le nième blog portant sur la techno Java, sur Linux, et autres sujets en TIC...
On essayera aussi d'ajouter des articles concernant la géolocalisation et l'information géographique.
Mais entre nous, ce sera, en fait de blog, plutôt un bloc note qui me servira à rassembler et à ne pas oublier ce qu'on a mis du temps à trouver...


page 2 de 2 -