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

Problème avec la fonction Resource.getURLs(String pattern);
by Eric Chatellier 10 May '11

10 May '11

Bonjour, Dans une application, j'ai besoin de rechercher des resources en fonction d'un pattern, pour cela j'ai utilisé la fonction Resource.getURLs(String pattern) mais qui par défaut recherche dans le system classloader. De plus, ayant un class loader personnalisé, je ne peux pas utiliser la fonction Resource.getURLs(String pattern, URLClassLoader classLoader) car je ne suis pas sur que mon classloader: Thread.currentThread().getContextClassLoader() etend URLClassLoader. J'ai trouvé un autre code qui permet de recherche des patterns dans un simple ClassLoader dans... Spring. http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/co… Voici un exemple d'utilisation : PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(Thread.currentThread().getContextClassLoader()); Resource[] resources = resolver.getResources("classpath:/validators/fr/ifremer/coser/data/*.xml"); for (Resource resource : resources) { URL url = resource.getURL(); ... } Je n'ai pas trop regardé comment ils faisaient, mais ca a résolu le fonctionnement en local et en java web start sans trop de developpement. Mais j'ai une dépendance sur Spring :( -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

3 6

Petit tour sur les classes de nuiton-utils
by Benjamin POUSSIN 27 Apr '11

27 Apr '11

Salut, Il y a quelques classes qui posent interrogation: - CardinalityHelper: pourquoi pas CardinalityUtil (comme toutes les autres), et surtout ou est-ce utilisé. Quel est la syntaxe d'une cardinalité ? - DigestGenerator: a priori une veille classe util que dans SimExplorer. Sert-elle encore ? aurait-elle une utilité pour d'autre projet ? - HashList: pour une list sans doublon, le nom n'est pas super. A renomer (mais en quoi) - StreamKeywordTokenizer: est-ce qu'il est encore d'actualité (2004, sans javadoc) - Resource: pourquoi avoir les methodes isPrimitive et getPrimitiveClass dans cette classe ? Elle serait mieux dans un Util (object ou class) - FileCompletion: j'ai du mal a voir les cas d'utilisation -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

2 1

[ANN] - Nuiton Utils 2.1.2 released
by nuiton.org Release Notification 27 Apr '11

27 Apr '11

1 0

Evolution de ApplicationConfig pour la prochaine release
by Benjamin POUSSIN 13 Apr '11

13 Apr '11

Salut, Voila quelques modifications que je vois pour la prochaine release, mais certaines ont des impacts sur d'autres projets, il faut donc que ca ne pose pas de probleme: 1) mettre la classe en final pour proscrire la creation de sous classe (car pour elle c mal) 2) ajouter dans le contrat de OptionDef la methode getAliases():String[] 3) passer en public quelques methodes qui sont actuellement protected (installSaveUserAction, loadDefaultOptions, loadActions) 4) ajouter un joli constructeur qui prend tout en argument et lance aussi le parsing Les deux ajouts qui pose potentiellement probleme sont les 2 premiers. Le 2eme me parait important. Le 1er n'est pas obligatoire, mais forcerait les gens a ce poser la question de comment utiliser ApplicationConfig. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

1 1

Fw: [Nuiton-utils-commits] r2099 - trunk/nuiton-utils/src/main/java/org/nuiton/util
by Benjamin POUSSIN 11 Apr '11

11 Apr '11

Salut, Quand j'ai vu dans le changelog le getOptionAsProperties, je me suis interrogé comment c'etait possible ? Comment une valeur texte pouvait devenir un Properties ? Plusieurs choix me sont venu en tête: - on passe en fait un pattern en argument, et on retourne l'ensemble des cles qui correspondent - la valeur de la propriete est en fait un truc special de type key=valeur;key=valuer;... Mais a aucun moment j'ai passé a ce qui est implanter et la "Oh rage, Oh désespoir", la javadoc n'aide vraiment, mais vraiment pas a savoir comment utiliser la methode :( Donc il faut absolument faire attention a la javadoc :) ps: j'ai modifie la javadoc, mais ce que j'ai ecrit (en anglais) ne me convient pas, mais je ne pouvais pas laisse ca comme ca. ----- Message Transféré ----- Date: Fri, 1 Apr 2011 10:25:18 +0200 (CEST) De: sletellier(a)users.nuiton.org À: nuiton-utils-commits(a)list.nuiton.org Sujet: [Nuiton-utils-commits] r2099 - trunk/nuiton-utils/src/main/java/org/nuiton/util /** + * Get option value as {@link Properties}. + * + * @param key the option's key + * @return value as properties + * @throws java.io.IOException if exception occured on read file + */ + public Properties getOptionAsProperties(String key) throws IOException { + File file = getOptionAsFile(key); + Properties prop = new RecursiveProperties(); + prop.load(new FileReader(file)); + return prop; + } -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

1 0

[ANN] - Nuiton Utils 2.1.1 released
by nuiton.org Release Notification 11 Apr '11

11 Apr '11

1 0

Bonne utilisation de ApplicationConfig
by Benjamin POUSSIN 06 Apr '11

06 Apr '11

Salut, Ce document est la pour présenté la bonne utilisation de ApplicationConfig d'après moi. Il est la comme base de départ pour trouver la meilleur utilisation possible. Etendre la classe ApplicationConfig dans son programme ou sa librairie est une mauvaise idée, surtout lorsqu'on utilise cette classe en argument de méthode, car on va finir par avoir plusieurs types de ApplicationConfig incompatibles entre elles et on ne pourra plus utiliser ApplicationConfig car il faudra passer par de la recréation dans le bon enfant de ApplicationConfig a partir des properties d'une autre. Pour éviter cela, la bonne façon lorsqu'on utilise ApplicationConfig serait de créer un MesOptions.java et MesActions.java qui seraient des enumerations dans lequel on défini l'ensemble des caractéristiques (nom, description, valeur par defaut, type, alias, ...) Est-ce que quelqu'un voit un inconvénient à cette bonne pratique ? comment ca marcherait ? ======================= Ajout de méthode spécifique pour accéder facilement a une option ---------------------------------------------------------------- methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION); Les enum implanteraient des interfaces spécifiques -------------------------------------------------- L'enum pour les options devrait implanter une interface spécifique avec les méthodes: - getDescription(): String - getValue(ApplicationConfig): String - getAliases:String[] - ... Et le constructeur de l'enum aurait en argument: - String key - String description - String default value - Class type - boolean transient (indique que l'option ne sera jamais sauvé sur disque) - boolean readonly (indique que l'option ne peut pas changer de valeur) - String ... aliases Init de ApplicationConfig ------------------------- plusieurs constructeurs possibles: - new ApplicationConfig(); - new ApplicationConfig(MesOptions.class); - new ApplicationConfig(MesOptions.class, MesActions.class); ... ApplicationConfig config = new ApplicationConfig(...); config.parse(args); config.action(level); Lors du new si les enums sont passées en argument, l'ApplicationConfig les utilise pour s'initialiser Mise en commun de certains besoins ---------------------------------- Du coup, il est possible de mettre par exemple la methode Help dans ApplicationConfig qui retourne la chaine 'usage' a afficher. Ce qu'il reste a faire ---------------------- Il n'y a pas grand chose a faire, vu qu'on a déjà une interface existante pour les options (OptionDef), il manque juste les alias. Et il faut juste le mettre en place de cette façon dans les projets (surtout les libs) qui l'utilise et y penser pour les prochains. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

3 10