[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sdx-developers] Sorties des versions 2.3 et 2.4 finales
|
From: |
Malo Pichot |
|
Subject: |
[sdx-developers] Sorties des versions 2.3 et 2.4 finales |
|
Date: |
Tue, 29 Sep 2009 12:31:05 +0200 |
|
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
Bonjour,
Ce devait être au printemps, ça arrive à l'automne :-) Nous sommes très
contents de vous annoncer les sorties des versions stables de SDX 2.3 et
SDX 2.4. Vous pouvez récupérer ces versions sur le site du projet sur
Savannah :
https://savannah.nongnu.org/files/?group=sdx
Pourquoi 2 versions ? Il n'y avait pas de versions stables de SDX 2.3 et
avant cela est venu très vite le besoin de faire une mise à jour des
librairies Java qui sont au coeur de SDX : Lucene et Cocoon. Cette mise
à jour est importante : SDX 2.4 utilise désormais Lucene 2.2.0 et Cocoon
2.1.10 ; SDX 2.3 est toujours basé sur Lucene 1.5 et Cocoon 2.1.5.1.
Joint à ce message, un fichier texte expose les principales
modifications et les ajouts des versions 2.3 et 2.4. Prenez soin de le
lire avant de vous lancer dans une éventuelle mise à jour de vos
applications.
PS: Nous en profitons pour sortir une version 2.2.2 pour maintenance
uniquement. Cette version intègre la mise à jour du connecteur JDBC de
manière à supporter les dernières versions de MySQL. Ceci suit la
discussion sur liste "sdx-users" :
http://lists.gnu.org/archive/html/sdx-users/2008-08/msg00011.html
A bientôt,
Malo Pichot
*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).
--
Malo Pichot (address@hidden)
2009-09-25
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [sdx-developers] Sorties des versions 2.3 et 2.4 finales,
Malo Pichot <=