Cantharella-devel

Download

cantharella-devel@list.forge.codelutin.com

February 2013

5 participants
42 discussions

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Adrien Cheype 04 Feb '13

04 Feb '13

Bonjour, Comme Mickaël l'a expliqué, l'intérêt de LogTools#getLog() est de pouvoir déclarer un logger avec un simple copier-coller. Je ne saurais dire pourquoi cette idée, a priori bonne, n'est pas plus répandue. J'imagine que c'est lié aux inconvénients introduits pour récupérer la classe de la méthode appelante. Au départ, il y avait effectivement un mécanisme de lever d'exception qui nous permettait de récupérer le bon nom de classe. Cette façon de faire n'étant pas très performante, j'avais pris la décision de régler le problème de performance en utilisant la classe Sun.reflect.Reflection. La contre-partie est que la classe n'existe que dans certaines jvm (sun et openjdk par ex.) et qu'il est imposible de l'exécuter dans certains environnements de sécurité restreinte (applets notamment). OK pour revenir à une déclaration plus classique en écrivant à la main le nom de classe. Pour ne pas avoir à changer plus d'une ligne, vous pouvez garder le nom de variable LOG. Adrien Le 02/02/2013 05:10, Mickaël Tricot a écrit : > Bonsoir, > > J'ai écrit l'implémentation initiale de LogTools#getLog(), qui a > apparemment évoluée depuis. > > L'unique avantage est de pouvoir copier-coller cette ligne d'une > classe à l'autre sans risque d'erreur. > > C'est moins performant que la méthode classique — > LoggerFactory.getLogger(HelloWorld.class) — puisqu'il s'agit de > générer une exception, d'analyser la stacktrace pour récupérer la > classe appelante et enfin de générer le logger adéquate. Générer une > exception est coûteux et généralement déconseillé, mais j'avais jugé > ce surcoût négligeable dans une telle application. > > Revenir à la méthode plus conventionnelle est une bonne idée, car plus > compréhensible pour les autres développeurs. Concernant le nom de la > variable, j'ai une préférence pour le nom concis (LOG), mais il s'agit > seulement là d'une habitude ou d'une question de goût. > > Cordialement, > Mickaël > > On 01/02/2013 18:13, Eric Chatellier wrote: >> Actuellement nous avons: >> private static final Log LOG = LogTools.getLog(); >> >> La convention slf4j est plutôt: >> >> private static final Logger logger = >> LoggerFactory.getLogger(HelloWorld.class); >> Ce qui implique de renommer aussi la variable "LOG" en LOGGER dans toute >> la classe également. >> >> La modification est plus importante que modifier une seule ligne >> dans chaque classe. >> >> >> Une autre question. C'est la première fois que je vois la déclaration >> des logs de façon générique: >> private static final Log LOG = LogTools.getLog(); >> qui récupère un Log sur la classe en haut de la stack actuelle. >> >> Je suis curieux de savoir si c'est performant et s'il y a une source >> qui explique les avantages (voire pourquoi ce n'est pas plus répandu). >> >> Ce mécanisme utilise, de plus, un import "sun.reflect.Reflection" >> (dans nc.ird.module.utils.GenericsTools) qui est déconseillé. > _______________________________________________ > Cantharella-devel mailing list > Cantharella-devel(a)list.forge.codelutin.com > http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 1

Re: [Cantharella-devel] CR Réunion Cantharella du 29/01/2013
by Adrien Cheype 04 Feb '13

04 Feb '13

Bonjour, Quelques petites corrections de ma part par rapport à ce qui a été dit. Dans la partie molécule, ajout du point : * le dessin de la molécule affiché dans la liste de molécules et dans la consultation est tronquée de sur la droite (atomes manquants pour certaines molécules !) + modification de Sylvain Modification le point 3 de la partie Document : * l'IRD fait les page de CRUD des types de documents (pour la partie configuration). Code Lutin devra s'occuper des interfaces liées aux documents. Ci-dessous le CR mis à jour (modification en gras). CR Réunion Cantharella du 29/01/2013 ==================================== Molécules --------- * Liste des molécules: les molécules doivent être dupliqué pour chaque provenance * édition des molécules: aligner sur les champs, manque la recherche de molécule, et la calculatrice * champs obligatoire qui ne sont pas requis: nom commun, famille chimique, nom iupac. * Identifiée par, mettre en plus les organismes lié aux personnes * problème le message "... car vous n'avez pas les droits nécessaires" est toujours affiché (voir exemple dans test biologique) (a regarder la meilleurs solution comment faire) * Les champs campagne et espèce ne fonctionne pas encore * Les droits utilisateurs ne sont pas encore complètement géré * double sur la page d'affichage de la molécule (même taille que l’édition) * si on clique sur l'image, il faut pouvoir la sauver. (ça marche sur firefox mais pas sous webkit, donc prévoir que si on clique sur l'image, on ouvre une nouvelle fenêtre avec une vraie image * changer "est-ce une nouvelle molécule ?" en "nouvelle molécule ?" * en visu, ajouter un icône fichier avec mol à coté du dessin de la molécule. * Molécule provenance: On peut rattacher plusieurs fraction et non pas une seule, a priori seul le MCD est faux. Dans le code ça doit être possible* * en visu, ajouter un icône fichier avec mol à coté du dessin de la molécule.* ** le dessin de la molécule affiché dans la liste de molécules et dans la consultation est tronquée de sur la droite (atomes manquants pour certaines molécules !)* slf4j contre commons-logging ---------------------------- * Log: pas de plus value à migrer, mais il faut tout de même corrige le problème actuel. * Une migration slf4j avec une impl log4j est tout de même demandée. Configuration et suppression des profiles ----------------------------------------- * On passe par ApplicationConfig, qui peut changer de fichier de config sur la ligne de commande Gestion des dépenandances maven ------------------------------- * double déclaration des dépendances pom.xml parent et enfant * c'est une convention maven * CodeLutin se renseigne sur la vrai plus value à faire cela et renvoi un mail sur la liste Convention de codage -------------------- * il y a un mélange historique de commentaire anglais/francais, mais les commentaires javadoc doivent tous être en anglais. * manque des commentaires javadoc (classe, attributs, méthodes) * utiliser la convention d'indentation avec 4 espaces (faire un commit pour remplacer les tabulations) * limiter la taille des lignes à 120 caractères (une limite de 80 caractères aurait pu être plus pratique pour les petits écrans) Documents --------- * On ajoute les colonnes dans l’entité Document (au lieu de multiples table de jointure non performantes) * On fait la liaison Document ↔ Entite avec une stratégie cascade on delete **l'IRD fait les page de CRUD des types de documents (pour la partie configuration). Code Lutin devra s'occuper des interfaces liées aux documents.* * Ajout de pièce jointe, après un ajout, il faut revenir sur l'ancienne page d'édition

1 0