Actuellement j’ai comme mission la maintenance et évolution d’un progiciel chargé de stocker les différents produits multimédia de mon client. Cet système est développe avec une mélange de technologies dont personne dans chez le client les maîtrise: Java, Spring, Tapestry, CRX, log4j… C’est le problème de faire un appel d’offre, accepter un fournisseur et casser la relation avec lui avant de recevoir un produit fini avec ça documentation. Mais bon: c’est comme ça.

Un des problèmes que j’ai trouvé dernièrement c’est de paramétrer une url via un fichier xml. On a besoin de ça parce que pour le moment on était obligé à livrer 3 versions différents pour chaqu’un des serveurs (recette, preproduction et production). La difficulté étais en faire arriver le valeur à l’interface (Tapestry) et à différents composants.

Finalement ma solution a été la suivant (et pas forcement la meilleur):

1. Utiliser la dependency injection de spring pour lire un fichier XML et créer un Bean simple (getters et setter). J’ai fais l’appel juste après de valider l’utilisateur et le mot pass, dans le fichier .java.

ApplicationContext ctx = new ClassPathXmlApplicationContext("chamin/au/fichier.xml");

BeanLien lien = (BeanLien) ctx.getBean("BeanLien");

2. Avec la URL du lien, initialiser une variable de session crée par Tapestry.

setLien(lien .getLien());
...
// getters et setters en abstract sont implémentes pour Tapestry automatiquement
@Persist
public abstract String getLienBOPRO();
public abstract void setLienBOPRO(String value);

3. Utiliser la variable dans le templates via ognl.

<a jwcid="@Any" target="_blank" href="ognl:lien">

4. Configurer le fichier .page pour pouvoir utiliser la variable lien.

<property name="lien" persist="session"/>

Je ne sais pas si cela est la meilleur solution mais pour le moment ça fonctionne. Le grand problème avec Tapestry est d’arriver comprendre l’architecture pour pouvoir faire de choses un peu plus complexes.

Disclaimer: je comprend que c’est article-la peut être de la charabia pour un personne non-technique mais je l’ai écrit surtout pour moi et pour me souvenir en un avenir au même temps que pratique mon français écrit.

Aquest és el missatge que porta martiritzant-me tota la setmana. Aparentment tenim alguna part del codi mal feta, on no tanquem els fitxers oberts, però per més que ho reviso, la veritat és que no trobo res.

L’unica possibilitat està en l’utilització de la llibreria vfs d’Apache que l’utilitzem per llegir uns fitxers enzipats. No sabem si és que quant obrim un zip de mes de 500 fitxers, per a començar atractar-los, aquest son comptats com a fitxer obert pel S.O.

Però el que és més curiós és que el mateix codi s’ha provat en diferents maquines, inclòs una màquina de pre-prod que és una replica exacte de la màquina de producció i aquest funciona correctament.

Tanmateix em queda una llarga jornada demà monitoritzant i retocant diferents parametres que podem trobar a /proc/sys/fs/ del linux.

En concret interessent els fitxers file-max (nombre maxim de fitxers oberts) , file-nr (fitxers oberts actualment) i d’altres fitxers sobre inodes…

Buff ja veurem.