Conversation
… par objet importé doProgressLog terminait par un Thread.sleep(1) placé hors du test de niveau de log, ce dernier étant fait à l'intérieur de doProgressLogWithoutInterruption. L'attente s'exécutait donc à chaque appel, y compris quand le message était filtré et n'était affiché nulle part. Or ce doProgressLog est appelé au niveau OBJECTS dans les boucles chaudes de l'import, alors que ImportThread règle le niveau à OBJECTS_GROUP en mode normal: une attente par fichier extrait du zip, par DataObjectGroup, par BinaryDataObject, par PhysicalDataObject et par ArchiveUnit. Sur un SIP de 50 000 AU et 50 000 binaires cela fait environ 200 000 attentes, soit 4 mn sous Linux et jusqu'à 50 mn sous Windows où un sleep d'1ms dure réellement 15,6ms. Pendant tout ce temps les menus Traiter et Export restent grisés, puisque setContextLoaded n'est appelé que depuis ImportThread.done(), d'où l'impossibilité de vérifier la conformité SEDA, de vérifier la conformité à un profil et d'exporter le SIP dans la demi-heure suivant l'ouverture. - SEDALibProgressLogger: les trois Thread.sleep(1) sont remplacés par checkInterruption(), qui lève InterruptedException si le drapeau d'interruption est posé. La sémantique d'annulation est identique, Thread.sleep ne faisant rien d'autre sur interruption, mais le coût est nul. - SEDALibProgressLoggerTest: non-régression sur la durée des appels filtrés (20 000 appels sous 2s, contre 23s avant correctif) et sur la propagation de l'annulation par doProgressLog et doProgressLogIfStep. Ce correctif couvre les trois tickets ouverts sur le même symptôme: #16842 pour la vérification de conformité au SEDA 2.1, #16843 pour la vérification de conformité au profil RNG des AN et #16845 pour l'export du SIP.
L'encodage des csv exportés était celui de la préférence d'import (importContext.csv.charsetName, onglet Import des préférences): ExportThread construisait le DataObjectPackageToCSVMetadataExporter avec un CSVImportContext. Un seul réglage ne peut pourtant pas satisfaire les deux sens, l'import devant suivre l'encodage du fichier source et l'export celui attendu par l'outil de destination. Régler l'import en UTF-8 pour lire un csv UTF-8 faisait donc passer tous les exports en UTF-8, et Excel sous Windows lit un csv UTF-8 sans BOM comme du windows-1252, d'où les accents remplacés par des caractères parasites. - ExportContext: nouvelle préférence exportContext.csvExport.charsetName, avec le même défaut qu'avant (windows-1252 sous Windows, UTF-8 ailleurs) et repli sur ce défaut pour les contextes sauvegardés avant l'existence du champ. Le comportement est donc inchangé tant que la préférence n'est pas modifiée. - ExportThread: l'export utilise cette préférence et non plus celle d'import. - PreferencesDialog, ExportContextDialog: choix de l'encodage du csv exporté dans l'onglet Export, à côté du format csv. La liste des encodages devient PreferencesDialog.CHARSET_STRINGS, partagée par les deux dialogues. - DataObjectPackageToCSVMetadataExporter: un csv UTF-8 est écrit avec son BOM, seule façon qu'Excel sous Windows le lise comme de l'UTF-8. Les autres encodages sont produits octet pour octet comme avant. - ByteOrderMarkUtil, CSVMetadataToDataObjectPackageImporter, CSVTreeToDataObjectPackageImporter: le BOM éventuel est retiré à la lecture, sans quoi il resterait dans la première cellule d'en-tête et rendrait la première colonne méconnaissable, cassant le ré-import des csv exportés. - Tests: présence du BOM en UTF-8 et absence en windows-1252, import d'un csv commençant par un BOM, aller-retour de la préférence d'encodage et repli sur le défaut, et cas limites de ByteOrderMarkUtil.
|
New Issues (55)Checkmarx found the following issues in this Pull Request
Fixed Issues (2)Great job! The following issues were fixed in this Pull Request
Use @Checkmarx to interact with Checkmarx PR Assistant. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
L'encodage des csv exportés était celui de la préférence d'import
(importContext.csv.charsetName, onglet Import des préférences): ExportThread
construisait le DataObjectPackageToCSVMetadataExporter avec un CSVImportContext.
Un seul réglage ne peut pourtant pas satisfaire les deux sens, l'import devant
suivre l'encodage du fichier source et l'export celui attendu par l'outil de
destination. Régler l'import en UTF-8 pour lire un csv UTF-8 faisait donc passer
tous les exports en UTF-8, et Excel sous Windows lit un csv UTF-8 sans BOM comme
du windows-1252, d'où les accents remplacés par des caractères parasites.
le même défaut qu'avant (windows-1252 sous Windows, UTF-8 ailleurs) et repli
sur ce défaut pour les contextes sauvegardés avant l'existence du champ. Le
comportement est donc inchangé tant que la préférence n'est pas modifiée.
dans l'onglet Export, à côté du format csv. La liste des encodages devient
PreferencesDialog.CHARSET_STRINGS, partagée par les deux dialogues.
seule façon qu'Excel sous Windows le lise comme de l'UTF-8. Les autres
encodages sont produits octet pour octet comme avant.
CSVTreeToDataObjectPackageImporter: le BOM éventuel est retiré à la lecture,
sans quoi il resterait dans la première cellule d'en-tête et rendrait la
première colonne méconnaissable, cassant le ré-import des csv exportés.
commençant par un BOM, aller-retour de la préférence d'encodage et repli sur
le défaut, et cas limites de ByteOrderMarkUtil.