[sdx-developers] RE : Derniers commits

[Martin Sevigny]

Bonjour,

> Je constate que sdxworld est à nouveau fonctionnel :-)

Et encore meilleur ce lundi, ce sera mieux vers la fin de la semaine...
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.

> Quelques questions cependant :
> 
> 1) Quand je démarre Tomcat, j'ai :
> 
> > Starting service Tomcat-Standalone
> > Apache Tomcat/4.0.4-b3
> > Cannot find CatalogManager.properties
> > Cannot find CatalogManager.properties
> > Cannot find CatalogManager.properties
> > Cannot find CatalogManager.properties
> > Cannot find CatalogManager.properties
> > Starting service Tomcat-Apache
> > Apache Tomcat/4.0.4-b3
> 
> Apparemment, cela correspond au log (sdx) :
> 
> fr.gouv.culture.sdx.exception.SDXException: SDX CONFIGURATION
> FAILURE:
> Unable to find an <sdx:catalogs> element defining entity 
> catalogs(<sdx:catalog>) within the <sdx:documentBases> element at : 
> file:/C:/tomcat4/webapps/sdx/sdxworld/conf/application.xconf:47:125
> 
> Mais bon, cela est probablement en TODO...

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.

> 2) Après avoir chargé les documents, j'ai une NPE sur une requête 
> d'index ne donnant aucun résultat (W, Z...)
> 
> fr.gouv.culture.sdx.exception.SDXException: Unable to get the document
> from the search hits : null
>       at 
> org.apache.cocoon.www.sdxworld.results_xsp.generate(C:\tomcat4
> \work\Standalone\localhost\sdx\cocoon-files\org/apache/cocoon/
> www/sdxworld\results_xsp.java:648)
> 
> Est-ce que cette exception ne peut pas être interceptée plutôt que de 
> surcharger les logs ? Selon moi, un résultat vide n'est pas 
> exceptionnel :-)

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

> 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é...

> 4) J'ai aussi quelques problèmes de compréhension en ce qui
> concerne la 
> configuration : il y a des fichiers partout et même des 
> fichiers vides 
> (difficiles à générer sous Windows).

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...

> Je sais bien que la doc est à
> venir, mais, dans cette perscpective, ne faudrait-il pas préciser la 
> terminologie dès maintenant ? On a apparemment un contexte de servlet 
> (tomcat/webapps),

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 sdx (tomcat/webapps/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...

> contexte de
> paramétrage Cocoon (tomcat/webapps/sdx/WEB-INF),

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.

> un contexte de
> paramétrage sdx (tomcat/webapps/sdx/WEB-INF/sdx),

Si tu veux appeler cela ainsi... ;-)

> des contextes
> d'application (tomcat/webapps/sdx/appli),

Contexte est ambigu. Je dirais des dossiers contenant (peut-être) des
applications SDX.

> des contextes de
> paramétrage 
> d'application (tomcat/webapps/sdx/appli/conf). Dur !

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.

> 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.

> 5) dernier point, connexe avec le précédent : le code fait un usage
> intensif d'appel de méthodes du genre 
> conf.getChild("X").getChildren("Y"). Ca pose le problème de 
> la validité 
> des fichiers de config : si "X" est absent, getChild("X") 
> renverra null 
> et on aura une belle NPE. Je ne sais pas trop quoi proposer 
> ici. Soit on 
> s'assure que tout est en ordre en testant null et en lnaçcant 
> éventuellement des exceptions, soit on confie en amont, par 
> un procédé 
> qui reste à définir, une validation des fichiers de config 
> par rapport à 
> une DTD/XSD.

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.

> Voilà pour ces quelques remarques. Ignorez les purement et
> simplement si 
> elles sont sur votre liste de TODO.

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.

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.

Et on termine cela en septembre.

A bientôt,

Martin Sévigny