LANG (charset) par défaut d’une JVM

Par defaut, la variable $LANG permet de choisir l’encoding par defaut de la JVM. Cette variable est dans /etc/sysconfig/i18n

Pour forcer un notre encodage, il est possible de passer l’option -Dfile.encoding=ISO-8859-1″ comme paramètre de la JVM ; ceci permettra de considére ce charset pour les fichiers lus par la JVM. Pour que tomcat serve des pages dans cet encoding il faudra ajouter :-Djavax.servlet.request.encoding=ISO-8859-1
Dans les dernieres version d’openSuse le fichier i18n n’existe plus, il faut alors ajouter ce parametres aux parametres de le JVM dans le fichier j2ee puis relancer tomcat. Il est aussi possible de passer par /etc/sysconfig/langage pour changer la variable $LANG

Cette solution permet de fixer le charset par defaut dans le mode souhaité qui doit etre le même que celui d’apache quand on utilise l’ajp13 ; à UTF-8 ou WEBISO-8859-1 … ou autre

Etat de la JVM d’un serveur d’application

Pour connaitre l’etat de la JVM d’un serveur d’application, du moins la mémoire qui lui reste et celle qu’il utilise, il faut accéder aux fonction de la classe Runtime ce la-dite JVM.

La jsp suivante affiche les principales informations :
<HTML>
<HEAD></HEAD>
<BODY>

<%java.lang.Runtime.getRuntime().gc();%>
— JVM MEMORY AVANT GARBAGE —<BR>
Total Memory : <%=java.lang.Runtime.getRuntime().totalMemory()/(1024*1024)%>Mo<BR>
Free Memory : <%=java.lang.Runtime.getRuntime().freeMemory()/(1024*1024)%>Mo<BR>
Max Memory : <%=java.lang.Runtime.getRuntime().maxMemory()/(1024*1024)%>Mo<BR>
<BR>

<%java.lang.Runtime.getRuntime().gc();%>

— JVM MEMORY APRES GARBAGE —<BR>
Total Memory : <%=java.lang.Runtime.getRuntime().totalMemory()/(1024*1024)%>Mo<BR>
Free Memory : <%=java.lang.Runtime.getRuntime().freeMemory()/(1024*1024)%>Mo<BR>
Max Memory : <%=java.lang.Runtime.getRuntime().maxMemory()/(1024*1024)%>Mo<BR>
<BR>
Proc Dispo : <%=java.lang.Runtime.getRuntime().availableProcessors()%><BR>
</BODY>
</HTML>

Gestion des Cookies dans un ensemble de pages JSP avec @include

J’ai rencontré pas mal de problèmes avec les JSP est les cookies, ces derniers sont assez utile pour laisser quelques traces et configuration sur le client de l’internaute qui peuvent être utiles pour l’optimisation de la navigation sur un site ou pour la suivi des statistiques.
Lors de l’intégration dans un contexte JSP utilisant des includes, il y a pas mal de petites règles à respecter pour que cela fonctionne sans quoi il y a moyen de s’arracher les cheveux !

Ce qu’il faut avoir : les Cookies doivent être envoyé dans l’entête de la réponse. Lorsque les pages générées sont de taille importante, le seveur d’application peut envoyer la page par morceaux dès qu’il y a suffisemment de données pretes. Du coup, si l’ajout du cookie est fait après le premier flush, il ne sera pas pris en compte. Il est donc important que les Cookie soient placés suffisemment tot dans la page pour éviter le flush.
Dans un contexte d’utilisation avec des include de JSP, il faut savoir en plus que le tag jsp:include a tendance à déclencher des flush (ce qui me semble étange puisque le fulsh peut être passé en option et que par défaut il ne l’est pas). Du coup, si le cookie est enregistré par une sous JSP, il ne sera pas pris en compte par le navigateur ; arrivant trop tard. La solution dans ce cas est d’utiliser un tage @include à la place du jsp:include, mais attention son utilisation est très différente puisque dans ce cas il s’agit de l’import du source importé avant la compilaton de la JSP et non de l’appèle à une autre JSP. Ce qui peut poser des problème si la modification est faite à postérieuri.

Bref, ma solution dans ce cas, réunir dans un fichier d’entête toutes les opération intervenant sur les Cookies et intégrer cette page au travers d’un @include dans toutes les pages du site en entête. L’utilisation généralisée du @include etant à proscrire à mon avis.

Modification du timeout des sessions avec tomcat

Pour modifier le timeout des sessions d’une webapp sous tomcat, il suffit d’ajouter les lignes suivantes dans le fichier web.xml :

<session-config>
<session-timeout>30</session-timeout>
</session-config>

Arnaque au renouvellement de nom de domaine

Après un petit bla bla incompréhéensible pour un néophite franchouillard mais pourtant très clair concernant le choix du registar différent pour le renouvellement, on n’hésites pas à vous proposer un renouvellement à un prix défiant toute concurence: 2 fois plus cher que le prix du marché, rien que ça !

Bref, ca a l’air bien officiel ce Domain Registry of América, même si c’est londonien, mais il n’y a rien d’autre à dire que de dénoncer cette politique commerciale qui joue sur la nouveauté de l’internet et l’usage de la langue anglaise pour vous faire payer au double du prix un service pour lequel vous avez dejà un marchant.
Par ailleurs, ce que ne dit pas cette lettre, c’est que tous les services d’hébergements que vous aviez pour votre site seront perdu, bref de quoi se retrouver avec un coquille vide et 6 mois de démarche pour retrouver son site opérationnel.
Au passage, le prix en ligne sont trois fois plus cher que l’offre normale, alors on a vraiment de la chance de cette belle promo LOL ! A mettre à la poubelle illico-presto !

Mes amis journalistes s’exprimant sur la technologie

Un thème d’actualité avec un équipement très important en France et les risque que chacun encours quant à la sécuritée de ses données personnelles. Bref, c’était à mon avis un reportage qui a du sens et une bonne idée d’in – formation du téléspectateur.
Malheureusement, cet élan de technophilie s’est finie, comme toujours, droit dans le mur entre journaliste incompétents et copain qui s’y connais en informatique, interviewé pour donner le mauvais conseil. Bref la honte !

Ce que l’on en retient : tous les réseaux sont pas défaut ouvert et il faut vous protéger avec un clef magique : la clef WEP. Tous vos disques sur sont accessible par tout le monde sinon !

Ce que n’ont pas compris les journalistes :

  • Un ordinateur ne partage pas son disque dur par défaut, le risque n’est donc pas aussi grand que l’on veuille le faire entendre
  • Les installations classiques ne sont plus ouvertes depuis bien longtemps, toutefois il est vrai qu’il faut faire très attention à celà sans quoi le réseaux est utilisable par n’importe qui
  • Celà fait maintenant 2 à 3 ans que le WEP est has-been, une clef 128 bits est crackée par attaque active en moind d’une heure ; par attaque passive (simple écoute) en moins d’une semaine

Alors s’il y a deux conseils à donner aux Internautes : choisir tout d’abord du WPA et uniquement du WPA pour encrypter les communications, solution non 100% fiable mais actuellement très correcte. Et ensuite qui n’a rien à voir, mais serait utile : ne pas tous prendre le canal 1 donné par défaut lors de l’installation, ca ne changera pas grand chose à la sécurité, mais coté performance, c’est la cata.

Quant aux entreprises, la règle est simple : considérer un accès Wifi comme un accès depuis Internet ! Utiliser pour l’accès des protocole type IPSEC et pas de sécurité de niveaux 2 (WPA ou WEP) dont les clefs partagées ne changement pas assez souvent et doivent être largement diffusées. Ces solutions ne doivent être utilisées qu’en complément d’un système sécurisé à identification individuelle.

Enfin c’est mon avis !

Dernier point : ne regardez plus les emissions de “vulgarisation” de l’informatique à la TV : c’est bidon !

Mise à jour … Effet sans lien ou peut-être … je ne sais pas, alors que de chez moi je captais pas loin de 10 réseaux Wifi ; quelque jours après cette diffusion et une série de mise à jour de live-box plus tard, 90% ont disparu. Réduction de puissance d’émission ?!? En tout cas une petite prise de conscience semble-t-il !

Option de cache des objets statiques avec apache2

Lorsque l’on modifie le CSS d’un site il est important de rafraichir la page sans quoi celle-ci est affichée avec le CSS ancienne version … résultats déplorables garantis !

Pour contourner celà, il est tout à fait possible de forcer un rafraichissement plus régulier de certains éléments comme les feuilles de style. Pour se faire, il faut ajouter à la config d’Apache quelques lignes que voici :

ExpiresActive On
ExpiresDefault “access plus 1 hours”
ExpiresByType text/css “access plus 1 hours”
ExpiresByType text/html “access plus 1 hours”
ExpiresByType image/gif “access plus 1 days”
ExpiresByType image/jpeg “access plus 1 days”
ExpiresByType image/png “access plus 1 days”

Bien sûr  il y a différentes façon de faire, et le paramétrage est à votre guise…
Attention toute fois, si l’on suit le modèle ci-dessus, les pages dynamiques (jsp, php) seront cachées elles-aussi ce qui peut vous poser des problèmes de raffrachissement ! Elles sont en effet identifiées sous le type text/html.
Une autre configuration peut être : ExpiresActive On
ExpiresDefault “access plus 1 hours”
ExpiresByType text/css “access plus 1 hours”
ExpiresByType text/html “now”
ExpiresByType image/gif “access plus 1 days”
ExpiresByType image/jpeg “access plus 1 days”
ExpiresByType image/png “access plus 1 days”

Des listes modifiables par drag & drop

Une des grosse fonctionnalité d’Ajax est d’offrir une interface dynamique de type client lourd dans un navigateur, nous avons déjà parlé de la communication en tâche de fond qui est le coeur d’Ajax, mais ce qui se passe au niveau du front end est tout aussi important. De nombreux site utilise cette technique de drag & drop pour permettre aux utilisateur de composer eux-même leur interface à leur gout. La première implémentation que nous avons pu en voir il y a quelque années était ici ; depuis les choses ont évoluées …

L’occasion de ce petit billet est un article décrivant en détail le fonctionnement de cette technique en liaison avec un base de donnée. Ce tutoriel pour php est plutôt bien fait, reprenant point par point la liaison à la base de donnée, l’utilisation des css et enfin les fonctions javascript de manipulation et  drag & drop. L’article sur les listes triées dynamiques avec ajax.

Pour ceux qui en outre souhaiterai voir une implémentation plus complète, vous trouverez un bon exemple sur Auverblog.info