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

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

April 11, 2011

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 April 11, 2011

April 11, 2011

1 0

Bonne utilisation de ApplicationConfig
by Benjamin POUSSIN April 6, 2011

April 6, 2011

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

[ANN] - Nuiton Utils 2.1 released
by nuiton.org Release Notification March 24, 2011

March 24, 2011

1 0

"Projections" dans BeanUtils
by Brendan Le Ny March 21, 2011

March 21, 2011

Dans Wao (et dans T3) on a un code qui revient très souvent : On a un bean Bean avec une propriété "a" de type A, et on veut une Map<A, List<Bean>>, c'est à dire une map qui pour toutes les valeurs différentes de A, donne les listes des instances de Bean qui ont cette valeur. C'est juste une construction de Map, une boucle avec un getter + une lazy initialisation de la liste si besoin. C'est quelques lignes mais une fois factorisée ça allège le code. Autre cas, on sait que la valeur de "a" est unique pour chaque instance de Bean, donc on veut une Map<A, Bean>. Y'a sûrement un coup en perf mémoire / temps, mais je trouve que ça allège l'écriture du code. Dans Wao, je fais ça partout, tout le temps. J'ai déjà codé le truc, et en remontant ça dans BeanUtils, on va revoir l'implém pour être efficace. Reste à trouver des noms de méthodes explicites, pour le premier cas, y'aurait "groupByProperty",. -- Brendan Le Ny <bleny(a)codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com

1 0

Re: [Nuiton-utils-devel] [Nuiton-utils-commits] r2086 - trunk/nuiton-utils/src/main/java/org/nuiton/util
by chemit Feb. 23, 2011

Feb. 23, 2011

On Wed, 23 Feb 2011 17:39:40 +0100 (CET) bpoussin(a)users.nuiton.org wrote: Si je lis bien le commit la javadoc est pas bonne. Il faut faire attention si possible à ce que la javadoc soit correct. Dans tout IDE qui se respecte on peut paramétrer l'éditeur pour qu'il y ait du rouge quand il manque de la javadoc. C'est pas trop normal qu'on laisse des javadoc crado à notre époque :) Je dis ça comme ça... > Author: bpoussin > Date: 2011-02-23 17:39:40 +0100 (Wed, 23 Feb 2011) > New Revision: 2086 > > Url: http://nuiton.org/repositories/revision/nuiton-utils/2086 > > Log: > change bad return type void -> long > > Modified: > trunk/nuiton-utils/src/main/java/org/nuiton/util/TimeLog.java > > Modified: > trunk/nuiton-utils/src/main/java/org/nuiton/util/TimeLog.java > =================================================================== > --- > trunk/nuiton-utils/src/main/java/org/nuiton/util/TimeLog.java > 2011-02-23 12:00:57 UTC (rev 2085) +++ > trunk/nuiton-utils/src/main/java/org/nuiton/util/TimeLog.java > 2011-02-23 16:39:40 UTC (rev 2086) @@ -183,8 +183,9 @@ > * @param startNs time returned by {@link #getTime()} method > * @param methodName key name to store this time > */ > - public void log(long startNs, String methodName) { > - log(startNs, getTime(), methodName, ""); > + public long log(long startNs, String methodName) { > + long result = log(startNs, getTime(), methodName, ""); > + return result; > } -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

Re: [Nuiton-utils-devel] [Nuiton-utils-commits] r2080 - trunk/nuiton-utils/src/main/java/org/nuiton/util
by chemit Feb. 10, 2011

Feb. 10, 2011

On Thu, 10 Feb 2011 11:05:45 +0100 (CET) echatellier(a)users.nuiton.org wrote: > + * @param classLoader classloader to use (if null, use {@code > ClassLoader.getSystemClassLoader()} Pourquoi on n'utilise pas un {@link ?} plutôt qu'un {@code ?} ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

2 1

Version de ASM tirée par aspectwerkz
by Arnaud Thimel Feb. 4, 2011

Feb. 4, 2011

nuiton-profiling tire aspectwerkz 2.0 qui dépend de org.nuiton.thirdparty:asm:1.5.4-snapshot Dans mon projet là, j'utilise hibernate-core en 3.6.0.Final qui lui tire asm:asm:3.1 et les 2 cohabitent assez mal : java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.<init>(I)V Du coup je me demande ce qu'on peut faire ? - forcer aspectwerkz à fonctionner avec asm:3.1 ? (je doute que ça se passe sans douleur) - forcer hibernate à fonctionner avec asm:1.5.4 ? (downgrader, j'aime pas trop) - autre ?? Arnaud.

5 6

[ANN] - Nuiton Utils 2.0 released
by nuiton.org Release Notification Jan. 26, 2011

Jan. 26, 2011

1 0

Re: [Nuiton-utils-devel] [Nuiton-utils-commits] r2010 - in trunk: . nuiton-utils nuiton-utils/src/main/java/org/nuiton/util nuiton-utils/src/main/java/org/nuiton/util/rmi
by chemit Jan. 19, 2011

Jan. 19, 2011

On Wed, 12 Jan 2011 15:31:01 +0100 (CET) athimel(a)users.nuiton.org wrote: > Author: athimel > Date: 2011-01-12 15:31:01 +0100 (Wed, 12 Jan 2011) > New Revision: 2010 > > Url: http://nuiton.org/repositories/revision/nuiton-utils/2010 > > Log: > [FEATURE] Add classes to easily export and reuse services to a RMI > registry > > Added: > trunk/nuiton-utils/src/main/java/org/nuiton/util/rmi/ > trunk/nuiton-utils/src/main/java/org/nuiton/util/rmi/RemoteMethodExecutor.java > trunk/nuiton-utils/src/main/java/org/nuiton/util/rmi/RemoteMethodExecutorImpl.java > trunk/nuiton-utils/src/main/java/org/nuiton/util/rmi/RemoteProxyFactory.java > trunk/nuiton-utils/src/main/java/org/nuiton/util/rmi/ServiceExporter.java > trunk/nuiton-utils/src/main/java/org/nuiton/util/rmi/package-info.java > Modified: > trunk/ > trunk/nuiton-utils/changelog.txt > On a un peu abandonné l'utilisation du changelog.txt (faudrait peut-être en reparler ?) Par contre on utilise Redmine :) donc en gros tout commit devrait être lié à un ticket sur redmine. De mon avis, on fait le ticket avant le commit, comme ça on peut indiquer dans le message de commit le ticket lié :) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

2 2