- Nuiton-utils-devel - mailman.cloud.codelutin.com

java.io.FileNotFoundException (Access is denied)
by Eric Chatellier Jan. 20, 2012

Jan. 20, 2012

Bonjour, Sur une application cliente nous avons des erreurs aléatoire d'accès refusé à certains fichiers probablement a cause de windows (voire même windows 7). Par contre, là où je m'interroge, c'est que l'erreur est aléatoire et très rare, mais semble toujours survenir dans la même méthode : http://www.nuiton.org/projects/nuiton-utils/repository/revisions/2129/entry… Voici une trace : java.io.FileNotFoundException: xxx (Accès refusé) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(Unknown Source) at java.io.FileOutputStream.<init>(Unknown Source) at org.nuiton.util.ZipUtil.uncompressAndRename(ZipUtil.java:134) Le code ne me semble pas incorrect, mais est-ce seulement la faute de windows ? -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

2 4

[ANN] - Nuiton Utils 2.4.4 released
by nuiton.org Release Notification Jan. 17, 2012

Jan. 17, 2012

1 0

[ANN] - Nuiton Utils 2.4.3 released
by nuiton.org Release Notification Jan. 17, 2012

Jan. 17, 2012

1 0

Fonctionnement de l'option app.name
by Eric Chatellier Jan. 13, 2012

Jan. 13, 2012

Bonjour, Dans Applicationconfig, il y a une option speciale qui sert a prefixer les options par un prefix dans le cas ou plusieurs applications tourne dans un même conteneur. Exemple, dans tomcat, avec coser et wao -Dwao.config.file=xxx.properties -Dcoser.config.file=zzz.properties Coser utilisant un prefix "coser." il ne va lire que les options qui le concerne. Idem pour wao. Seulement, il y a plusieurs problèmes a ce fonctionnement: - les options par defaut sont positionnées sans le prefix, et le prefix est renseignés apres l'instanciation (ano : http://nuiton.org/issues/1862) - le code test pour 2 ou 3 options seulement ce mécanisme config.file et encoding (c'est donc limité en nombre d'option) - Vu le code ca n'a pas l'air très souple (codé à coup de if/else pour les 2/3 options, et si on voulait ajouter d'autre options ? http://nuiton.org/projects/nuiton-utils/repository/revisions/2251/entry/tru… Avez vous des idées pour améliorer ce fonctionnement ? -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

3 3

[ANN] - Nuiton Utils 2.4.2 released
by nuiton.org Release Notification Jan. 9, 2012

Jan. 9, 2012

1 0

[ANN] - Nuiton Utils 2.4.1 released
by nuiton.org Release Notification Dec. 14, 2011

Dec. 14, 2011

1 0

[nuiton-csv] ModelBuilder
by desbois Dec. 9, 2011

Dec. 9, 2011

Salut, J'ai continué les TU sur nuiton-csv, et notamment tester le ModelBuilder. Mais j'ai un doute de son utilité. En gardant l'idée de l'api, j'ai fais une implem un peu plus pousser avec une methode buildImportModel qui te renvoie directement un ImportModel avec les différentes colonnes construites. Finalement il serait plus simple que le ModelBuilder implémente les deux interfaces ImportModel et ExportModel, on pourrait le renommer en CsvModel. Pour les besoins spécifiques rien n'empêchera l'héritage. Ainsi pushCsvHeaderNames sera vide par défaut et étendu au besoin (d'ailleurs je la renommerais bien en onReadHeaders pour montrer son côté callback). Même chose pour le newInstance, en passant la classe au constructeur du modèle, on peut proposer une implem par défaut avec un myClass.newInstance. Libre à l'utilisateur de surcharger s'il veut un comportement plus pousser (utiliser sa propre factory). Une autre idée serait de proposer des contrats pour avoir un callback sur les headers et une factory pour l'instanciation. Je reviens aussi sur les interfaces ImportableColumn et ExportableColumn que je trouve inutiles. Il faut juste permettre le !mandatory & !ignored dans la classe Column. Pour l'Import je rajouterais bien aussi des méthodes qui l’exécute directement sans avoir besoin d'instance d'Import. Par exemple : public static <E> List<E> getResultAsList(ImportModel<E> model, Reader reader) { Import<E> instance = Import.newImport(model, reader); try { List<E> result = new ArrayList<E>(); for (E row : instance) { result.add(row); } return result; } finally { instance.close(); } } En pratique on pourrait avoir : CsvModel<Row> model = CsvModel.newModel(';', Row.class); model.addMandatoryColumn("TITLE", "title"); model.addMandatoryColumn("DATE", "date", new Common.DateValue("yyyy-MM-dd")); model.addMandatoryColumn("NUMBER", "number", Common.INTEGER); List<Row> results = Import.getResultAsList(model, reader); Qu'en pensez-vous ? je vais maintenant regarder l'Export voir si ça se goupille bien. Je pense qu'on peut avoir une api bien sympa en tout cas, mais ya encore pas mal de chose à voir pour simplifier/fignoler. --------------8<----------------8<--------------8<----------------- Exemple plus compliqué comme dans WAO : CSV: --- TITLE;01/2010;02/2010;03/2010 "Row1";1;2;3 "Row2";5;0;1 "Row3";4;1;0 Import: --- CsvModel<Row> builder = CsvModel.newModel(';', Row.class); builder.addMandatoryColumn("TITLE", "title"); builder.setHeadersCallback(new CsvModel.HeadersCallback() { @Override public void onReadHeaders(List<String> headerNames) { List<String> dynamicHeaders = headerNames.subList(1, headerNames.size()); for (String header : dynamicHeaders) { // Format header to have Date value Date month; try { month = DateUtils.parseDate(header, "MM/yyyy"); } catch (ParseException e) { throw new ImportRuntimeException("Parsing error of dynamic header " + header, e); } // Add the dynamic column using Row specified setter builder.addMandatoryColumn( header, Common.INTEGER, Row.getMonthValueSetter(month) ); } } }); List<Row> results = Import.getResultAsList(model, reader); Row : --- public class Row { private String title; private SortedMap<Date, Integer> monthValues; public Row() { this.monthValues = new TreeMap<Date, Integer>(); } public String getTitle() { return title; } public void setTitle(String title) { this.title = title; } public void addMonth(Date month, Integer value) { monthValues.put(month, value); } public Map<Date, Integer> getMonthValues() { return monthValues; } public static ValueSetter<Row, Integer> getMonthValueSetter(final Date month) { return new ValueSetter<Row, Integer>() { @Override public void set(Row object, Integer value) throws Exception { object.addMonth(month, value); } }; } }

2 4

[ANN] - Nuiton Utils 2.4 released
by nuiton.org Release Notification Nov. 30, 2011

Nov. 30, 2011

1 0

Nuiton-csv quelques retours
by desbois Nov. 30, 2011

Nov. 30, 2011

Salut, J'ai jeté un oeil sur nuiton-csv, et je vais en profiter pour rajouter des tests unitaires et de la doc. J'ai pour le moment juste tester l'Import. Quelques retours jusque là : - Je ne suis pas fan du Iterator anonyme au milieu de la méthode startImport. Je pense qu'il serait plus intéressant de le sortir en méthode iterator() et du coup faire que Import implémente Iterable. - Ma première utilisation de Import fut de l'utiliser tel quel en implémentant les ImportableColumn. Je me suis aperçu qu'il y avait une implémentation par défaut très intéressante qui est Column. Du coup je me pose la question de l'interface. A priori les méthodes static proposés suffisent pour instancier correctement le Column suivant le besoin (import, export ou les deux). Je simplifierais donc bien en utilisant tout le temps Column. (cela enlèverait donc trois interfaces). - La solution de mandatory/ignored est un peu confuse. L'implémentation dans Column suppose que mandatory = !ignored, ce qui finalement se tient. On aura jamais les deux à true ou les deux à false. A moins que j'ai zappé un cas, je pense qu'il faut supprimer l'un des deux. - La notion de readFirstLine pourrait être paramètrable via le modèle. A moins que ce soit un pré-requis obligatoire que la première ligne soit les HEADERS. (Ce qui sera ajouter explicitement à la doc) - J'ai du mal avec la notion de start/stop. Je garderais plutôt l'idée de read/close plus explicite sur ce qui se cache derrière (un fichier). L'iterator se chargera du parcours. A noter que le validateCsv ne valide que les headers et non l'intégralité des données (ce qui serait débile mais peut porter à confusion). Utilisation actuelle : Import<Row> importRow = Import.newImport(rowModel, stream); try { Iterator<Row> iterator = importRow.startImport(); // validate headers, read first line and return iterator while (iterator.hasNext()) { Row row = iterator.next(); // treatment } } finally { importRow.stopImport(); } Utilisation possible : Import<Row> importRow = Import.newImport(rowModel, stream); try { importRow.readHeaders(); // validate headers and read first line for (Row row : importRow) { // using importRow as Iterable // treatment } } finally { importRow.close(); } Voilà pour le moment, je n'ai pas encore regarder le ModelBuilder. Je vais commiter mon test d'Import (avec Model et ImportableColumn anonymes, avec Model et Column) Une autre idée en passant : Est-ce que ce serait pas plus intéressant d'avoir le choix entre un rapport d'erreurs ou des exceptions dans le cas d'un problème rencontré sur une ligne ? A l'heure actuelle il faut catcher les exceptions une par une pour toutes les avoirs. Ce sera probablement intéressant dans un deuxième temps si le besoin s'en fait sentir.

3 3

[ANN] - Nuiton Utils 2.3.1 released
by nuiton.org Release Notification Nov. 13, 2011

Nov. 13, 2011

1 0