- Cantharella-devel - mailman.cloud.codelutin.com

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

Externalisation de la configuration et suppression des profils
by Eric Chatellier 29 Jan '13

29 Jan '13

Bonjour, J'envoie un mail sur la liste pour présenter le points avant discussion lors de la réunion de demain. Dans cantharella, la configuration des tous les environnements d'utilisation de l'application est présente dans le projet, et donc dans le war produit. Ce qui implique de construire le war avec toujours un profil activé et de disposer des sources pour reconfigurer l'application. Nous avons une approche différente à CodeLutin. Les applications ne dispose pas de profiles et dispose le plus souvent d'une configuration par défaut correspondant suivant les cas: * à une configuration par défaut d'une installation typique de l'application * à une configuration pour les tests unitaires. Dans tous les cas, le war produit est unique et nous utilisons un mecanisme de surcharge de la configuration à l'extérieur du war. Le war lit sa configuration par defaut, et d'autres fichiers de configuration dans certains emplamcement définis (par exemple) : - /etc/cantharella.conf - $HOME/.config/cantharella.conf - ./cantharella.conf - ... Cette gestion de la configuration est gérée par une classe dédiée: http://maven-site.nuiton.org/nuiton-utils/nuiton-utils/ApplicationConfig.ht… http://maven-site.nuiton.org/nuiton-utils/nuiton-utils/apidocs/index.html?o… Nous souhaiterons vous proposer d'utiliser également ce mécanisme également dans cantharella en supprimant les profiles et a allant lire une surcharge de la configuration dans ces emplacements à déterminer. Concretement, cela reviendrait à ajouter dans la configuration de spring un nouveau placeholder basé sur ApplicationConfig qui ferait le travail. Cordialement, Eric Chatellier. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

2 2

Re: [Cantharella-devel] Externalisation de la configuration et suppression des profils
by Adrien Cheype 29 Jan '13

29 Jan '13

Bonjour, Complètement d'accord avec vous, mieux vaut laisser tomber les environnements Maven (vestige hérité des premiers développement du projet comme le précise Mickaël) et passer à une configuration par fichiers externalisés. Votre proposition d'utiliser à la place la classe ApplicationConfig semble bien convenir aux besoins du projet. Adrien Le 28/01/2013 21:16, Mickaël Tricot a écrit : > Bonjour, > > Introduire des profils Maven par environnement était une fausse bonne > idée ! Avoir une archive unique pour tous les environnements et une > configuration externe est en effet la bonne façon de faire. > > Personnellement, j'aime autant que faire se peut utiliser des > ressources JNDI sur le serveur d'applications (puisque c'est une API > standard), à défaut un fichier de configuration passé en option > (exemple : -Dconfiguration=/path/to/cantharella.properties). Par > ailleurs, si les options de configuration vont au-delà d'une liste de > clés-valeurs (properties), j'aime assez le format YAML qui offre une > flexibilité et simplicité intéressantes. > > Cordialement, > Mickaël > > > _______________________________________________ > 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

1 0

Test du moteur de recherche et export CSV
by Sylvain PETEK 28 Jan '13

28 Jan '13

Bonjour, Je viens de refaire des tests aujourd’hui. - Au niveau du moteur de recherche : Je ne sais pas si c’est une conséquence du dernier paramétrage de l’indexation ou un oubli, mais je n’ai pas de résultat quand je fais des recherches sur des données se trouvant dans les champs « Embranchement » et « Genre ». - Au niveau de l’export CSV : Concernant les différents tableaux, l’export se fait TB, à part pour le tableau « Extraction », où il manque la colonne « Extraits ». Voilà voilà, A Mardi, bon WE, Sylvain <http://cantharella.ird.nc/> cid:image003.jpg@01CD89CA.344245D0 Dr Sylvain PETEK Porteur du projet & administrateur de Cantharella IRD BP529, 98713 PAPEETE – Tahiti – Polynésie Française ) +(689) 47 42 14 (GMT -11h) - 7 +(689) 42 95 55 <mailto:anneetsylvainpetek@free.fr> sylvain.petek(a)ird.fr <http://www.ird.fr/informatique-scientifique/projets/cantharella/> cid:image004.jpg@01CD89CA.344245D0 <http://forge.codelutin.com/projects/cantharella> lutin-orange-sans-ombre

2 1

Re: [Cantharella-devel] Test du moteur de recherche
by Adrien Cheype 24 Jan '13

24 Jan '13

Bonjour, Il est également possible d'importer des fichiers d'un encodage différent dans Excel. L'accès à cette fonctionnalité ne se fait par contre pas automatiquement comme on peut le voir à l'ouverture d'un fichier avec OpenOffice. Il faut plutôt partir d'un nouveau fichier et aller à l'onglet "Données" et cliquer sur le bouton "à partir du texte" (sur Excel 2012, l'équivalent doit exister avec les versions précédentes). L'encodage utilisé est alors demandé ainsi que d'autres paramètres comme le délimiteur notamment. Le 08/01/2013 18:17, Benjamin POUSSIN a écrit : > On Mon, 07 Jan 2013 11:44:43 +0100 > Eric Chatellier <chatellier(a)codelutin.com> wrote: > >>> Dans UniteConcMasse, apparemment µ est transformé en Î¼, et î en ÃŽ, je ne >>> sais pas si il y a un réglage à faire pour les caractères spéciaux… >>> >> Comme pour le séparateur, il faut certainement spécifié que l'encodage du >> fichier est "UTF-8" (unicode). > Il me semble (mais je peux me tromper, car je n'ai pas Excel) qu'Excel > n'est pas capable de gérer les différents encodage. Par contre > LibreOffice ou OpenOffice permettent lors de l'import de choisir > l'encodage du fichier. > -- 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

1 0

Re: [Cantharella-devel] Utilisation de sjf4j ou de commons-logging
by Adrien Cheype 23 Jan '13

23 Jan '13

Bonjour, Je reviens de congés et me permet d'apporter mon grain de sable à cette discussion. Comme le rappelle Mickaël, l'application repose depuis ses débuts sur common-logging. Cependant puisque Hibernate utilise slf4j, le choix a été fait (par Mickaël notamment) d'utiliser la "bridging legacy API" jcl-over-slf4j. Ainsi, tous les logs peuvent être redirigés sur SLF4j et ce dernier est configuré avec l'implémentation log4j (slf4j-log4j12). Cette configuration fonctionnait correctement jusqu'à récemment. En effet Éric, il y a certainement un conflit de version dans les dépendances depuis que Cantharella est passé sur la forge de Code Lutin et qu'il a bénéficié par la même occasion de mises à jour sur un bon nombre de ses librairies. J'ai regardé un peu pour résoudre le problème mais j'arrive qu'à obtenir soit les logs qui proviennent du code source (commons-loggin), soit ceux qui proviennent d'hibernate (slf4j). Sinon, il est certain qu'on peut améliorer l'architecture, cela sera certainement plus rapide que de corriger le problème actuel. Bien que vos propositions me semblent toutes deux aller dans le bon sens, je serais plus d'avis à utiliser directement slf4j car elle a davantage de fonctionnalités, qu'elle me semble actuellement plus reconnue dans la communauté Java, et que cela permet de s'affranchir de common-logging (contrairement à l'autre cas, où l'on doit garder slf4j pour hibernate). Si cette solution est retenue, on peut alors soit continuer de garder log4j ou bien comme le suggère Mickaël migrer vers son "successeur" logback. Là, mon avis est plus mitigé, tout dépend du temps qu'on veut y passer. Log4j marche déjà bien mais logback peut avoir ses avantages... Et bienvenue à Mickaël dans la mailing-list ! N'hésite pas à participer de nouveau, on a toujours besoin l'avis d'un architecte Octo ;) Bonne journée, Adrien Le 22/01/2013 04:31, Eric Chatellier a écrit : >> Il me semble avoir fait l'erreur au départ du projet de baser les logs de >> l'application sur commons-logging, alors que slf4j est bien plus puissant et >> moins poussiéreux. Aujourd'hui, je partirais sur une solution slf4j >> <http://www.slf4j.org/> en façade + logback <http://logback.qos.ch/> en >> implémentation native (ces librairies ayant été développées par le créateur de >> log4j). >> Le projet log4j a été repris assez récemment et semble prometteur, néanmoins >> log4j2 <http://logging.apache.org/log4j/2.x/> n'est encore disponible qu'en beta. >> Dans tous les cas il faut rediriger les logs provenant d'API tierces vers la >> solution choisie (voir : bridging legacy APIs <http://www.slf4j.org/legacy.html>) > Je suis d'accord avec vous, je suis plus fan de slf4j que commons-logging > également. > > Mais, les avis divergent (même au sein de codelutin) quant à l'utiliser à la place > de commons-logging pour diverses raisons, la principale étant que > fondamentalement, slf4j et commons-logging font la même chose > (une interface sur une implémentation qui peut changer) > et que le remplacement n'est pas forcement justifié. > > Je serais tenté d'attendre au moins un avis de plus avant toute action :-) > -- 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

1 0

Utilisation de sjf4j ou de commons-logging
by Eric Chatellier 21 Jan '13

21 Jan '13

Bonjour, Dans l'application, les dependances de logging n'ont pas été configurée (ou elles ont changés lors du changement de forge). L'application à l'air d'être basée sur commons-logging, mais hibernate utilisant slf4j, on doit quand même le prendre en compte. La modification des fichiers log4j.xml n'est pas prise en compte actuellement (log verbeux de hibernate en debug). Actuellement la dépendance "jcl-over-slf4j" est présente dans le projet (c'est à dire redirection de commons-logging vers slf4j). Je serais plutôt tenté de faire l'inverse: * baser l'application sur commons-logging * utiliser l'impl slf4j qui redirige sur commons-logging (slf4j-jcl) * et utiliser l'implémentation log4j Êtes vous d'accord avec l'utilisation principale de commons-logging à la place de slf4j ? -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com

2 2

Re: [Cantharella-devel] Interface molécule
by Sylvain PETEK 18 Jan '13

18 Jan '13

-----Message d'origine----- De : cantharella-devel-bounces(a)list.forge.codelutin.com [mailto:cantharella-devel-bounces@list.forge.codelutin.com] De la part de Eric Chatellier Envoyé : vendredi 18 janvier 2013 02:55 À : cantharella-devel(a)list.forge.codelutin.com Objet : Re: [Cantharella-devel] Interface molécule Le 09/01/2013 04:00, Sylvain PETEK a écrit : > Bonjour, > > Je viens de regarder l'interface "Gestion d'une Molécule". > > Il faudrait indiquer que le champ "Masse molaire" est obligatoire Ok. > > Au niveau de l'encadrée Est-ce une nouvelle molécule ? > Le champ "Identifiée par" doit proposer une liste suggestive des organismes présents dans la base (à l'heure actuelle il s'agit de la liste des personnes). C'est bien comme l'interface Spécimen (une combo box Plante, Organisme Marin...)? Non non, il s'agit des organismes au sens "institution" comme Université X, Institut Y, ou Labo Z. Dans les spécifications, il y a un exemple pour ce champ. C’est un champ texte libre (textfield) avec une auto-complétion des valeurs déjà enregistrées dans la base de données (liste suggestive…). Dans cette interface ce champ s’appelle "Type d'organisme" et il y a aussi un champ "Identifié par" mais qui ici, liste des personnes. C'est ce qui m'a induit en erreur. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - <http://www.codelutin.com> http://www.codelutin.com _______________________________________________ Cantharella-devel mailing list <mailto:Cantharella-devel@list.forge.codelutin.com> Cantharella-devel(a)list.forge.codelutin.com <http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel> http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel

1 0

Re: [Cantharella-devel] Interface molécule
by Sylvain PETEK 18 Jan '13

18 Jan '13

Le 18/01/2013 13:54, Eric Chatellier a écrit : > Au niveau de l'encadrée Est-ce une nouvelle molécule ? > Le champ "Identifiée par" doit proposer une liste suggestive des organismes présents dans la base (à l'heure actuelle il s'agit de la liste des personnes). > C'est bien comme l'interface Spécimen (une combo box Plante, Organisme Marin...)? En fait, ça à plutôt l'air d'être un champs texte libre (textfield) avec une auto-complétion des valeurs déjà enregistrées dans la base de données. C'est bien ça ? Oui c'est ça, c'est ce que nous appelons "liste suggestive"... -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com _______________________________________________ Cantharella-devel mailing list Cantharella-devel(a)list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/cantharella-devel

1 0