*Les nouveautés de SDX 2.4*

Les modifications de SDX 2.4 par rapport à la version 2.3 sont essentiellement
la mise à jour des librairies Lucene, Cocoon et Saxon. Pour Lucene, SDX 2.4 utilise
désormais la version 2.2.0 (au lieu de la version 1.5). Pour Cocoon, SDX 2.4
utilise désormais la version 2.1.10 (au lieu de la version 2.1.5.1). Pour Saxon,
SDX 2.4 utilise toujours Saxon 6.5.3 par défaut, mais il est possible d'utiliser
Saxon 8.9.0.4.


*1) Cocoon*
La mise à jour de Cocoon est importante : SDX passe de la version 2.1.5.1 à la
version 2.1.10. Lors de migration d'ancienne application SDX de versions
antérieures, les plus poblèmes les plus important viendront sans doute de cette
mise à jour. Les problèmes peuvent être des composants Java de Cocoon qui
n'existent plus, ou plutôt qui ont changé de nom. Ces composants sont déclarés
dans les Sitemap (fichiers *.xmap) et le fichier de configuration Cocoon
(WEB-INF/cocoon.xconf).


*2) Lucene*
La mise à jour de Lucene est également importante : SDX passe de la version 1.5
à la version 2.2.0. SDX profite ainsi des optmisations du code de Lucene et des
améliorations quand à la stabilité de Lucene. Il y a encore du travail pour que
SDX profite pleinement des optmisations de Lucene.

A noter, une très grande différence du parseur de requête de Lucene (depuis la
version (1.9) : l'utilisation de la troncature "?" ne signifie plus "un
caractère ou pas de caractère", mais "un caractère obligatoirement et n'importe
lequel". Cela veut dire que "communication?" ne renvoie plus "communication",
uniquement "communications". Le mécanisme précédent est considéré comme un bogue
par l'équipe de développeur de Lucene (cf. bogue LUCENE-306).


*3) Saxon 8 et XSLT 2.0*
SDX 2.4 intègre Saxon 8 qui permet l'utilisation de XSLT 2.0. Parce que
la politique de contrôle de Saxon 8 est moins permisive que Saxon 6, Saxon 8
n'est pas branché par défaut. On peut utiliser Saxon 8 à partir du
transformateur "xslt2" :
	<map:transform type="xslt2" src="[...]/>


*4) Entrepôt OAI*
*4.1) Validation*
L'entrepôt OAI de SDX a été corrigé de manière à être complètement valide. Il
existait principalement des problèmes au niveau de la gestion des erreurs (très
stricte en OAI).

*4.2) Plusieurs entrepôts OAI pour une base de documents*
SDX 2.4 permet de déclarer plusieurs entrepôts OAI pour une unique base de
documents :

	<sdx:documentBase id="mabase" [...]>
		<sdx:oai-repository id="default" default="true"
			baseURL="http://{serveur}/sdx/oai/monapplicationsdx/mabase" [...]>
			[...]
		</sdx:oai-repository>
		<sdx:oai-repository id="images" default="false"
			baseURL="http://{serveur}/sdx/oai/monapplicationsdx/mabase/oairepo-images" [...]>
			[...]
		</sdx:oai-repository>
	</sdx:documentBase>

Ci-dessus, on déclare 2 entrepôts OAI pour la base de documents "mabase" de
l'appplication SDX "monapplicationsdx". Les attributs "id" et "default" sont
maintenant obligatoires pour l'élément <sdx:oai-repository>. L'URL ancienne
http://{serveur}/sdx/oai/{application sdx}/{base de documents} est toujours
valable. Le nouveau patron est celui :
http://{serveur}/sdx/oai/{application sdx}/{base de documents}/oairepo-{id entrepôt OAI}


*4.3) Changer le préfixe des identifiants OAI*
SDX 2.4 permet de modifier le préfixe des identifiants OAI "sdx" par défaut. Par
exemple :

	<record>
		<header>
			<identifier>
				sdx:mon.domaine.com:80:monapplicationsdx/mabase/identifiant-sdx
			</identifier>
			[...]
		</header>
		[...]
	</record>


peut devenir :

	<record>
		<header>
			<identifier>
				mon.prefix:mon.domaine.com:80:monapplicationsdx/mabase/identifiant-sdx
			</identifier>
			[...]
		</header>
		[...]
	</record>

Pour cela, il faut utiliser le paramètre de configuration suivant :

	<sdx:oai-repository oai-id-prefix="mon.prefix" [...]>


*5) Un journal d'indexation*
SDX 2.4 intègre désormais un journal spécifique à l'indexation. Ce journal est
dans WEB-INF/logs/indexation-*.log. La rotation par défaut est journalière. Le
niveau de verbosité est défini dans le fichier de configuration des journaux
(WEB-INF/logkit.xconf). Les niveaux utilisables sont :
- FATAL_ERROR
	Début et fin d'indexation

- ERROR (niveau par défaut)
	Idem FATAL_ERROR plus :
	Ecriture dans l'index Lucene
	Optimisation de la base de documents

- WARN
	Idem ERROR plus :
	Début et fin d'indexation de chaque document

- INFO
	Idem WARN plus :
	Transformation de chaque document
	Attribution d'identifiant pour chaque document
	Stokage de chaque document dans l'entrepôt
	Ajout de chaque document attaché et/ou sous-document
	Ajout de chaque document dans l'index Lucene temporaire
	Mise à jour des métadonnées de chaque document
	Ajout ou suppression de chaque document dans l'entrepôt OAI

- DEBUG
	Idem INFO plus :
	Début et fin de transformation de chaque document
	Début et fin de traitement de chaque document attaché et/ou sous-document

Pour des questions de rétro-compatibilité, seules les applications SDX activant
la prise en charge du log auront un journal effectivement utilisé :
	<sdx:application indexation-logging-level="1" [...]>


*6) Pouvoir déplacer les index Lucene et entrepôts de documents*
SDX 2.4 permet maintenant d'indiquer où placer le "datadir" :
	<sdx:application datadir="file:///usr/share/sdx/datadir" [...]>


*7) Débogage de la fusion d'index Lucene sur certaines plateformes*
En environnement Windows x64 bits, la fusion des index Lucene qui intervient en
fin d'indexation pouvait échoué en raison de la réservation des fichiers ou du
dossier par le système Windows.


*8) Nouvel opérateur de requête "$"*
Le QueryParser est capable d'utiliser la troncature avec l'opérateur "$"
(opérateur forçant l'utilisation de l'analyseur du champ de recherche).


*9) Traitement des mots vides avant la suppression des diacritiques*
SDX 2.4 traite maintenant les mots vides avant la suppression des diacritiques.
De cette manière, on peut rechercher "maïs" qui n'est plus confondu avec le mot
vide "mais".

*10) Surlignage des expressions recherchées*
SDX 2.4 surligne maintenant les expressions recherchées.


*Les nouveautés de SDX 2.3.0*


*1) Désactivation de la création systématique d'une session*
La taglib de SDX créait systématiquement une session utilisateur. Ceci
pouvait faire défaillir le serveur d'application J2EE (Tomcat, Jetty, JBoss,
etc.) lors du passage de moteur d'indexation tels que GoogleBot. La cause était
simplement le trop grand nombre de sessions (plusieurs centaines) créées.
Désormais, la taglib de SDX ne crée plus systématiquement de session. Il faut le
demander explicitement via l'attribut :
	<sdx:page create-session="true" [...]"

*2) Traiter plusieurs requêtes OAI à la fois*
Les entrepôts OAI de SDX 2.3 corrigent un gros problème d'accès concurrent au
service de requête OAI qui faisant en sorte que l'entrepôt ne pouvait pas
traiter plus qu'une requête à la fois. Dans le cas de requêtes concurrentes, une
seule recevait un résultat correcte, les autres recevaient un message d'erreur.

*3) Le panier de documents*

- Panier SDX comprend maintenant de nouveaux éléments pour gérer un
 panier dans la session de l'utilisateur. Ces outils, à disposition du
 développeur, travaillent autour d'un objet de session "sdx_caddy" qui
 contient au moins l'identifiant d'un document. Le développeur à la
 possibilité d'ajouter d'autres paramètres à cet identifiant
 (obligatoire).

 <sdx:addToCaddy> Permet d'ajouter des documents dans le panier.
 Attributs :
	 - id : l'identifiant du document
	 - qid : l'identifiant de la requête
	 - limit : nombre maximal de document dans le panier
 Elements :
	 - <sdx:parameter>
	 - <sdx:fallBack>
	 - <sdx:success>

 Exemple :
 <sdx:addToCaddy idParam="id" qidParam="qid">
	 <sdx:parameter name="base" valueParam="base" />
 </sdx:addToCaddy>

 Pour l'URL : [...]/panier.html?id=000124545&base=maBase le panier
 contiendra une entrée : <sdx:document base="maBase" id="000124545" />


 Pour l'URL : [...]/panier.html?qid=sdx_q14&base=maBase le panier
 contiendra autant d'entrée que la requête "sdx_q14" possède de
 résultat.


 <sdx:deleteFromCaddy> Permet de retirer un document du panier.
 Attributs : - id : l'identifiant du document - limit : nombre maximal
 de document dans le panier

 Exemple : <sdx:deleteFromCaddy idParam="id" />

 Pour l'URL : [...]/panier.html?id=000124545 SDX retirera le document
 "000124545" du panier.

 Pour l'URL : [...]/panier.html?.id=all SDX videra entièrement le
 panier.


 <sdx:getCaddy> Permet de retourner des documents issus du panier. Il
 s'agit d'une requête au même titre que <sdx:executeListQuery>.
 <sdx:getCaddy> accepte donc tous les attributs et éléments fils que
 les autres actions d'exécution de requête (<sdx:base> par exemple).

 <sdx:showCaddy> Retourne une réprésentation XML du panier sous la
 forme :
 <sdx:caddy limit="1000" nb="1">
	 <sdx:document base="maBase" id="000124545" />
	 <sdx:document base="maBase" id="000124546" />
	 <sdx:document base="maBase" id="000124547" />
 </sdx:caddy>



*4) L'historique des requêtes*

- Historique de requêtes SDX possède maintenant de nouveaux éléments
 pour gérer un historique des requêtes. Ces éléments gèrent un objet
 de session "sdx_historic" contenant, pour chaque requête, la date
 d'exécution, la représentation Lucene de la requête et le nombre de
 documents retournés par la requête. Le développeur peut ajouter
 d'autres informations avec les <sdx:parameter>.

 <sdx:addToHistoric> Permet d'ajouter une requête dans l'historique.
 Attributs :
 - qid : l'identifiant de la requête
 - limit : nombre maximal de requêtes dans l'historique
 Elements :
 - <sdx:parameter>
 - <sdx:fallback>
 - <sdx:success>

 Exemple :
 <sdx:addToHistoric limit="10">
	 <sdx:parameter name="qid" valueParam="qid" />
	 <sdx:parameter name="base" valueParam="base" />
	 <sdx:fallback> L'historique est plein ! </sdx:fallback>
 </sdx:addToHistoric>

 Pour l'URL : [...]/historique.html?qid=sdx_q1&base=maBase
 l'historique contiendra une entrée :
 <sdx:search base="maBase" date="2005-11-08T13:15:06" id="1131452103450" lucene="+(sdxall:1)" nb="14788" qid="sdx_q1" />


 <sdx:deleteFromHistoric> Permet de supprimer une requête de
 l'historique. Attributs :
	 - id : l'identifiant de la requête

 Exemple : <sdx:deleteFromHistoric idParam="id" />

 Pour l'URL : [...]/historique.html?id=000124545 SDX retirera la
 requête "000124545" de l'historique.

 Pour l'URL : [...]/historique.html?.id=all SDX videra entièrement
 l'historique.


 <sdx:showHistoric> Retourne une réprésentation XML de l'historique
 sous la forme :
 <sdx:historic limit="1000" nb="1">
	 <sdx:search base="maBase" date="2005-11-08T13:15:06" id="1131452103450" lucene="+(sdxall:1)" nb="14788" qid="sdx_q1" />
	 <sdx:search base="maBase" date="2005-11-08T13:20:13" id="1131452103460" lucene="+(DOMAINE:urbanisme*)" nb="551" qid="sdx_q2" />
 </sdx:historic>



*5) Fichier de configuration SDX dynamique*

- Fichier de configuration dynamique SDX tente maintenant de
 récupérer le fichier de configuration d'application
 (application.xconf) avec le protocole "cocoon:". Ceci donne la
 possibilité de générer ce fichier de configuration à l'aide du
 mécanisme de Pipeline de Cocoon. Ainsi, une entrée de Sitemap :
 <map:match pattern="**.xconf">
	 <map:generate src="{1}.xconf"/>
	 <map:transform type="xinclude" />
	 <map:serialize type="xml"/>
 </map:match>
 permet de retourner un fichier "application.xconf" via
 une URL "cocoon://maBase/conf/application.xconf".

 Le protocole "cocoon:" n'est utilisable qu'une fois l'environnement
 de Cocoon entièrement déployé. Ainsi, lors du démarrage de
 Tomcat/Cocoon, le protocole n'est pas utilisable. Dans un cas comme
 celui-ci, où le protocole "cocoon:" ne renvoie pas de fichier de
 configuration, SDX tente de récupérer ce fichier de configuration via
 le protocole habituel "file:".

 De nouvelles méthodes Java ont été ajoutées pour permettre la
 reconfiguration dynamique d'une application :
 fr.gouv.culture.sdx.framework.reconfigureApplicationByPath(String
 appPath)
 fr.gouv.culture.sdx.framework.reconfigureApplicationById(String
 appId)



*6) Rechargement dynamique d'une liste de champs (fieldList)*

 - Rechargement dynamique d'une liste de champs (fieldList) SDX permet
 maintenant de récupérer une liste de champs via le protocole
 "cocoon:", de la même manière que pour le fichier de configuration.

 De nouvelles méthodes Java ont été ajoutées pour permettre la
 reconfiguration dynamique de la liste de champs d'une application :

 fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.reloadFieldList(String
 appConfString) appConfString est le chemin retournant la liste des
 champs (eg., file:///mesFichiers/fieldList.xconf ou
 cocoon://monApp/conf/fieldList.xconf).

 fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.replaceFieldList(FieldList
 fieldList)



*7) Désactivation de l'optimisation automatique des index Lucene*

- Optimisation non automatique d'une base de documents Lucene
 L'implémentation de l'optimisation différée d'une base de documents
 Lucene a été complétée. Elle est opérationnelle dans la limite où la
 suppression d'entrée dans les index Lucene n'est pas visible tant que
 les index n'ont pas été optimisés.



*8) Désactivation de l'utilisation de métadonnées*

- Désactivation de l'utilisation des métadonnées d'une base de
 documents.
 L'élément <sdx:documentBase> possède désormais un nouvel attribut permettant de
 désactiver l'utilisation des métadonnées d'une base de documents. Ces
 métadonnées servent à stocker :
 - le lien d'un document avec ses sous-documents et vice-versa
 - le lien d'un document avec ses documents attachés
 - l'entrepôt dans lequel un document est stocké
 - les requêtes OAI pour un entrepôt OAI ou un moissonneur OAI
 - type de document (eg., xml)
 - longueur du document
 - version de SDX

 Il est donc possible de désactiver l'utilisation de ces métadonnées sans danger
 dans le cas où un base de documents :
 - n'utilise pas d'entrepôt
 - utilise un unique entrepôt ou pas d'entrepôt du tout
 - utilise un entrepôt de type autre que "FS" et "URL"
 - n'utilise pas de documents attachés
 - n'utilise pas de sous-documents

 Cela signifie que SDX peut fonctionner sans problème sans serveur SQL !



*9) Suppression de l'utilisation de Xalan*
- SDX 2.3 n'utilise plus Xalan (transformateur XSL d'Apache) mais Saxon.


*10) Nouvel algorythme de requête*
SDX 2.3 ajoute une nouvelle classe Java (donc seulement accessible via l'API)
: LinearComplexQueryBuilder. Qui gère de manière beaucoup efficace les requêtes
complexe avec multiples regroupement et opérateur.


*11) Activer la cache Cocoon sur les XSP*
SDX 2.3 apporte une belle optimisation des pages dynamiques dont le contenu change peu souvent, ou seulement lors de la modification des index de recherche. Par défaut, Cocoon ne cache pas l'XML généré par les pages XSP. SDX 2.3 implémente 2 nouvelles classes Java ApplicationSourceValidity et DocumentBaseSourceValidity qui permette d'activer la cache dans les XSP en se basant sur la date de la dernière modification des index d'une application ou d'une base de documents.
Pour activer cette cache Cocoon, il faut ajouter les lignes ci-après dans les XSP. La construction de la clé de cache est effectué par la méthode "getKey()". Dans l'exemple ci-après, la clé est destinée à cacher un document SDX. Tant que la base de documents à laquelle appartient ce document n'a pas été modifié (eg, une nouvelle indexation), Cocoon servira le document en cache. Ceci économise une connexion au serveur SQL si SDX en utilise un, et économise la lecture du fichier sur le système de fichiers ou le serveur SQL suivant le type d'entrepôt de documents choisi par la base de documents.

<sdx:page>
  <xsp:structure>
	  <xsp:include>org.apache.excalibur.source.SourceValidity</xsp:include>
  </xsp:structure>
	<xsp:logic>
    public Serializable getKey(){
		  String  noCache = parameters.getParameter("noCache", 
			                   request.getParameter("noCache")),
              docid   = parameters.getParameter("id", 
							           request.getParameter("id")),
              base    = parameters.getParameter("base", 
							           request.getParameter("base")),
              apppath = parameters.getParameter("path-sdxapp",
							           request.getParameter("app")),
              key = null;
      if ( noCache!=null ) { return null; }
      else {
          return ( (Utilities.checkString(apppath))?apppath:"" ) +
                 ( (Utilities.checkString(base))?base:"" ) +
                 ( (Utilities.checkString(docid))?docid:"" );
      }
    }
    public SourceValidity getValidity() {
      SourceValidity  sourceValidity = null;
      String  noCache = parameters.getParameter("noCache",
			                   request.getParameter("noCache")),
              base    = parameters.getParameter("base", 
							           request.getParameter("base")),
              apppath = parameters.getParameter("path-sdxapp",
							           request.getParameter("app"));
      if ( noCache != null ) { return null; }
      fr.gouv.culture.sdx.application.Application   app     = null;
      fr.gouv.culture.sdx.documentbase.DocumentBase docbase = null;
      try {
        /* Ici, de quoi recuperer l'application SDX. Il y a moyen de
        *  dynamiser tout ca en passant le parametre "path-sdxapp" depuis
        *  la Sitemap. [MP]*/
        app = ((FrameworkImpl)manager.lookup(Framework.ROLE)).getApplicationByPath( apppath );
        docbase = app.getDocumentBase( base );
        if ( docbase!=null )  sourceValidity = docbase.getSourceValidity();
        else if ( app!=null ) sourceValidity = app.getSourceValidity();
      }
      catch ( Exception e ) { logError( e ); }
      finally { return sourceValidity; }
    }

	</xsp:logic>


Est-il nécessaire d'ajouter que d'activer la cache Cocoon sur une XSP générant un résultat de recherche paginé est une très mauvaise idée ? ;-) Tout le contraire que d'activer la cache sur une XSP chargée de retrouner l'ensemble des valeurs d'un index (hpp=-1).:w

--
Malo Pichot (malo.pichot@ajlsm.com)
2009-09-25
