Re: [sdx-users] Pb de moisson OAI

[Pierrick Brihaye]

Salut,

address@hidden wrote:

> > La date du build ne veut pas dire grand chose en elle-même car c'est la 
> > date des sources qui compte. Cependant, un build 2005082201 n'aurait pas 
> > été mal :-)
>
> Presque ! Voici : SDX - version:2.2.1, build:2005070801 (Merci Pierre).

Je suis sûr que tu peux faire mieux :-)

> Voici une autre problème : je cherche à moissonner en entrepôt (non SDX).
> Avec un navigateur, l'URL
> http://172.16.32.241/exl-php/oai/serveur/oai2.php?verb=ListRecords&metadataP
> refix=oai_dc me donne ce qu'il faut (fichier joint).
>
> Lorsque c'est une appli SDX qui moissonne, j'obtiens l'exception en fichier
> joint, dont voici un aperçu :
>
> ERROR   (2005-08-25) 18:43.39:071   [sdx.framework.moissonneur.notices]
> (Unknown-URI) Unknown-thread/OAIUtilities:
> http://172.16.32.241/exl-php/oai/serveur/oai2.php?verb=ListRecords&metadataP
> refix=oai_dc
> java.lang.NullPointerException

> Etonnant, ma foi.

Mmmh...

Ce qui nous intéresse, c'est ça :
at 
fr.gouv.culture.oai.AbstractOAIHarvester.endElement(AbstractOAIHarvester.java:336)

Allons voir la ligne 336 :
http://savannah.nongnu.org/cgi-bin/viewcvs/sdx/sdx_v2/src/java/fr/gouv/culture/oai/AbstractOAIHarvester.java?annotate=1.29.2.8

Elle ne fait que rejeter une exception survenue dans le bloc situé juste 
avant... Or, ce bloc, relativement ténu, ne peut renvoyer de NPE qu'à 
partir de :

storeHarvestedData (qui peut "normalement" lancer ProcessingException, 
IOException, SDXException, SAXException)
saveCriticalFields (qui peut lancer SAXException)
handleResumptionToken (qui est prévu pour ne rien lancer)

Note : il eût été IMHO plus judicieux d'individualiser les types 
exceptions et de logger en conséquence du côté de la ligne 336.

Tout se passe donc dans :
http://savannah.nongnu.org/cgi-bin/viewcvs/sdx/sdx_v2/src/java/fr/gouv/culture/sdx/oai/AbstractDocumentBaseOAIHarvester.java?annotate=1.24.2.16

storeHarvestedData est à la ligne 644
handleResumptionToken est à la ligne 762
saveCriticalFields est à la ligne 1063

A priori saveCriticalFields est hors de cause car elle relance une 
SAXException quoi qu'il arrive. Ce n'est pas forcément la meilleure 
idée, surtout pour traquer une NPE, mais bon...

Les 2 autres, ne relançant pas d'exception, une NPE peut donc tout à 
fait être transmise dans la pile.

Ne sachant si tu as testé une moisson sur des repos fournissants des 
resumptionTokens, j'ignore la fiabilité de la méthode 
handleResumptionToken mais, a priori, elle semble assez robuste 
puisqu'elle est même prévue pour avaler les NPE :-)

La meilleure candidate serait donc storeHarvestedData. Un bloc catch 
requi relancerait l'exception avec un petit message de log permetrait de 
confirmer.

Merci de votre attention. A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78