Re: [sdx-developers] RE : Derniers commits

[Pierrick Brihaye]

Salut,

Je réponds tard. Pas trop le temps en ce moment : grrrr...

Martin Sevigny wrote:

> Et encore meilleur ce lundi, ce sera mieux vers la fin de la semaine...


Oui. En tout cas, au dernier CVS, j'ai des bugs :

ERROR   (2002-08-28) 09:41.18:010   [sdx.framework] (Unknown-URI) 
Unknown-thread/Utilities: No attribute named "id" is associated with the 
configuration element "application" at 
file:/C:/tomcat4/webapps/sdx/sdxworld/conf/application.xconf:47:94
org.apache.avalon.framework.configuration.ConfigurationException: No 
attribute named "id" is associated with the configuration element 
"application" at 
file:/C:/tomcat4/webapps/sdx/sdxworld/conf/application.xconf:47:94

J'imagine que ça doit venir des récents changements dans les méthodes 
d'accès aux id. Pas eu trop le temps de suivre pour être plus précis, hélas.


> On a trouvé un bogue étrange : lorsqu'il y a plus d'une base de
> documents, seule la première est indexée correctement. Les autres, seuls
> les champs SDX sont indexés, pas les champs utilisateurs! C'est pourquoi
> si on charge la base avec des projets puis on essaie de chercher une
> URL, on n'aura pas d'erreur mais on ne trouvera jamais (par la
> recherche) le document en question... C'est notre première priorité en
> ce lundi.


Vous en êtes où ?


> C'est corrigé. Deux choses : il manquait une CatalogManager.properties
> dans le CLASSPATH pour satisfaire la classe Cocoon et il y avait un WARN
> sur l'absence de catalogues, ce qui n'est pas nécessaire bien sûr.


Vu.


> Ce n'es pas un résultat vide, c'est une erreur interne... Relié à mon
> commentaire sur le premier point. Nous y travaillons...


OK.


> > 3) Autre chose bizarre, l'index "s" a une valeur "sontensuite". 
> > L'original semble pourtant comporter l'espace. Problème de filtrage ?
>
> Je n'ai pas remarqué...


Je refais un test... dès que ça tourne.


> Dans l'explorateur, tu right-cliques dans la partie de droite, tu fais
> "nouveau", "document texte" (par exemple) tu lui donnes un nom et il est
> vide...


Oui. En fait, je me suis emmelé les pinceaux avec les fichiers dont le 
nom commence par un point :-)


> Non, c'est l'endroit où sont les applications Web. Intouchable, c'est
> dans la spécification des servlets. Je constate toutefois que Tomcat
> (dans server.xml) semble avoir quelques possibiltiés de modifier cela,
> mais c'est donc hors SDX.


> Un contexte ou une application Web, les deux sont utilisés. A noter ici
> que "sdx" peut être remplacé par ce que tu veux...


> Non, un dossier WEB-INF, obligatoire (specs servlets), qui doit contenir
> le web.xml. Les jars de 'lib' et les 'classes' de classes sont chargées
> automatiquement. L'usage veut que ce dossier soit protégé, d'où
> l'intérêt d'y mettre des fichiers de configuration, potentiellement
> sensibles.
>
> Si tu veux appeler cela ainsi... ;-)

>
> Contexte est ambigu. Je dirais des dossiers contenant (peut-être) des
> applications SDX.
>
> En fait, pour un développeur, c'est simple : il doit y avoir un
> applicatin.xconf dans un dossier */conf sous 'sdx'. Et puis, pour
> l'instant, il doit y avoir un fichier (vide) dans
> WEB-INF/sdx/applications qui correspond à "*". On fera cette semaine une
> interface Web pour générer/supprimer ce fichier, qui constitue
> l'enregistrement de l'application auprès de SDX.

Je rappelle que ma demande concernait la terminologie de la doc. Je ne 
faisais que proposer des termes... Et apparemment, tu en as d'autres à 
proposer :-)

De but en blanc, il est assez difficile, en lisant une classe X ou Y de 
savoir où on va lire le fichier de configuration. Ceci dit, la doc 
s'améliore. Merci ! J'espère pouvoir recontribuer le plus vite possible. 
Quelques problèmes de bécane en ce moment...


> > BTW. Est-il concevable de sortir les applis du contexte SDX afin de
> > faciliter la mise à jour de SDX (suppression de 
> > tomcat/webapps/sdx) puis 
> > extraction automatique du war ? Personnellement, j'ai toujours la 
> > trouille qu'une extraction automatique me flingue mes 
> > sous-répertoires.
>
> Je sais, mais ce n'est pas possible, sauf par liens symboliques sous
> UNIX. Tomcat ne sert que ce qu'il y a sous webapps, et chaque dossier
> sous webapps est sa propre application, avec son propre CLASSPATH, etc.


Soit.


> C'est à corriger. En passant, il y a un schéma pour les application.conf
> qui est déjà dans la doc (sdx_v2/src/documentation/src/xml/schemas/...).
> Il semble y avoir une petite erreur (du moins XML Spy se plaint), on
> regarde cela aujourd'hui.


OK.


> Il y a beaucoup de TODO, mais ça avance. En ayant fait depuis deux
> semaines environ 5 ou 6 applications SDX 2, les bogues commencent à
> sortir et on les corrige à mesure.


Tu pourrais faire un point de ce qui est fonctionnel ? J'ai hâte de 
migrer vers SDX2.


> On vient de faire la mise à niveau Cocoon 2.0.3, ça marche avec Saxon,
> les derniers CVS de Lucene, etc. J'espère pouvoir faire une deuxième
> sortie publique vers la fin de la semaine.


OK. Qu'en est-il des améliorations faites sur le parseur Lucene ? As-tu 
une appli qui permette de tester ce qui s'appelait simpleQuery sous SDX1 ?


> Et on termine cela en septembre.


Wow !

Sinon, que Rasik ne s'impatience pas trop : j'ai vu les questions qu'il 
m'a posées. Disons que la plupart des mes remarques concernent :

1) des structures comme :

if
else if

sans else

2) l'accès à des noeuds XML dont on est pas sûr qu'ils existent. Cela 
risque de lancer des NPE, ce qui est peut-être trop sévère dans la 
mesure où on peut parfois utiliser des valeurs par défaut.

A bientôt.
--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden