Logs, logs, logs...

[Emmanuel Lécharny]

Salut !

ça fait longtemps, mais je pense que passé septembre, tout le monde est
en pleine brasse coulée...

On discutait récemment des loggers, un serpent de mer(de) qui revient
souvent dans les conversations. Log4j, JUL, JULI, slf4j, logback,
log4j2, clog, tinylog, on a un chiée de loggers existants et plus
personne ne sait ou donner de la tête, c'est style pire que les nouveaux
langages qui fleurissent tous les jours. Sans compter les ceusses qui ne
jurent que par System.out( "ta gueule, log4j !" );

Vous utilisez quoi, et pourquoi ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Nicolas Delsaux]

2012/12/4 Emmanuel Lécharny <elec...@gmail.com>:

> Salut !
>
> ça fait longtemps, mais je pense que passé septembre, tout le monde est
> en pleine brasse coulée...
>
> On discutait récemment des loggers, un serpent de mer(de) qui revient
> souvent dans les conversations. Log4j, JUL, JULI, slf4j, logback,
> log4j2, clog, tinylog, on a un chiée de loggers existants et plus
> personne ne sait ou donner de la tête, c'est style pire que les nouveaux
> langages qui fleurissent tous les jours. Sans compter les ceusses qui ne
> jurent que par System.out( "ta gueule, log4j !" );
>
> Vous utilisez quoi, et pourquoi ?
>

Personnellement, j'utilise java.util.logging (celui que t'appelle
jules, donc), essentiellement parce que
- il est disponible dans le JDK sans dépendance de merde qui risque
de créer des conflits pas possibles (pour info notre projet a dans ses
dépendances maven 3 dépendances indirectes vers des versions
différentes de log4j. C'est assez pour me dissuader de m'en servir)
- comme je ne fais pour l'instant pas d'analyse poussée des logs, je
n'ai pas vraiment ressenti l'utilité de changer quoi que ce soit aux
logs produits par mon logger quand il est utilisé dans Glassfish ou en
application standalone - mon appli cliente est dans ce cas)

Du basique, quoi (et je conchie GMail qui passe son temps à vouloir
que je réponde avant le message auquel je répond. A croire que Google
méprise aimablement 20 de netiquette usenet ... grmbl).
--
Nicolas Delsaux

[Nicolas Labrot]

De mon coté slf4j pour justement sa capacité à fédérer la pléthore de système de logging.

2012/12/4 Nicolas Delsaux <nicolas...@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Emmanuel Lécharny]

Le 12/4/12 3:41 PM, Nicolas Delsaux a écrit :

Mais ton appli n'est pas embeddable, non ? Sinon, comment tu gères
l'intégration dans les systèmes qui t'embeddent ?

[Nicolas Delsaux]

2012/12/4 Emmanuel Lécharny <elec...@gmail.com>:

>
> Mais ton appli n'est pas embeddable, non ? Sinon, comment tu gères
> l'intégration dans les systèmes qui t'embeddent ?
>

La partie serveur est une appli JavaEE totallement classique, exécutée
dans un Glassfish, qui récupère mes logs et les écrit dans le fichier
standard de Glassfish (server.log).
La partie client écrit ses logs dans un fichier dans le HOME de
l'utilisateur, à la fois toute seule (via un FileAppender) et dans le
fichier de ... nos logs de notre code C++ (mais me laissez pas parler
plus ça va vous rendre malade) via, apparement, une récupération de
System.out.

--
Nicolas Delsaux

[Sebastien Bordes]

+1 pour slf4j (30ko / 13ko avec pack200) avec logback (630 / 193) comme choix par défaut (pour les projets perso et ceux qui démarrent)

log4j malheureusement pour les projets 'alimentaires' figés dans le marbre....

slf4j propose la possibilité de plugger :

• un vieux log4j
• un logger qui fait rien NOP
• un logger syserr
• un Jakarta Commons Logging
• du JUL ( que je trouve long à paramètrer)
• logback en natif !
  

Logback permet de s'affranchir des fameux isTraceEnabled pour avoir un code plus véloce.
La suppression du niveau fatal est aussi une bonne chose car toute error devrait corrigé

Seb

[tvi...@onyme.com]

On Tue, 04 Dec 2012 17:58:45 +0100, Emmanuel Lécharny
<elec...@gmail.com> wrote:
>
> Mais ton appli n'est pas embeddable, non ? Sinon, comment tu gères
> l'intégration dans les systèmes qui t'embeddent ?
>

OMG !
T'es enrhumbé? Si y a un système qui t'embedde du le jedde à la
boubelle et bis c'est dou.

(Désolé: je suis en congés c'est comme le vendredi du coup dans ma
tête)

[Olivier Lamy]

Le 4 décembre 2012 19:56, Sebastien Bordes
<sebastie...@gmail.com> a écrit :

> +1 pour slf4j (30ko / 13ko avec pack200) avec logback (630 / 193) comme
> choix par défaut (pour les projets perso et ceux qui démarrent)
>
> log4j malheureusement pour les projets 'alimentaires' figés dans le
> marbre....
>
> slf4j propose la possibilité de plugger :
>
> un vieux log4j
> un logger qui fait rien NOP
> un logger syserr
> un Jakarta Commons Logging
> du JUL ( que je trouve long à paramètrer)
> logback en natif !

Tu as oublié le log4j2. si si :-)
cf comparaison de performance:
http://logging.apache.org/log4j/2.x/performance.html

>
> Logback permet de s'affranchir des fameux isTraceEnabled pour avoir un code
> plus véloce.
> La suppression du niveau fatal est aussi une bonne chose car toute error
> devrait corrigé
>
> Seb
>
>
> Le mardi 4 décembre 2012 18:08:57 UTC+1, Nicolas Delsaux a écrit :
>>
>> 2012/12/4 Emmanuel Lécharny <elec...@gmail.com>:
>> >
>> > Mais ton appli n'est pas embeddable, non ? Sinon, comment tu gères
>> > l'intégration dans les systèmes qui t'embeddent ?
>> >
>> La partie serveur est une appli JavaEE totallement classique, exécutée
>> dans un Glassfish, qui récupère mes logs et les écrit dans le fichier
>> standard de Glassfish (server.log).
>> La partie client écrit ses logs dans un fichier dans le HOME de
>> l'utilisateur, à la fois toute seule (via un FileAppender) et dans le
>> fichier de ... nos logs de notre code C++ (mais me laissez pas parler
>> plus ça va vous rendre malade) via, apparement, une récupération de
>> System.out.
>>
>> --
>> Nicolas Delsaux
>

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> lescastcodeurs.

> Cette discussion peut être lue sur le Web à l'adresse
> https://groups.google.com/d/msg/lescastcodeurs/-/mxEhviKmv78J.

>
> Pour envoyer un message à ce groupe, adressez un e-mail à
> lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

[Sebastien Bordes]

Log4j 2 le retour à l'air pas mal ?
Quelqu'un l'a déjà utilisé de manière intensive ?

Il a l'air rapide d'après leurs chiffres (mais est-ce remarquable), en plus les jars on l'air d'être un poil plus petit

Seb

[Nicolas Delsaux]

2012/12/4 Sebastien Bordes <sebastie...@gmail.com>:

> Log4j 2 le retour à l'air pas mal ?
> Quelqu'un l'a déjà utilisé de manière intensive ?
>
> Il a l'air rapide d'après leurs chiffres (mais est-ce remarquable), en plus
> les jars on l'air d'être un poil plus petit
>

C'est marrant que tu sois concerné par la taille des jars comme
critère de choix.
Tu bosses sur une appli embarquée ? Parce que bon, c'est quand même le
seul cas où la taille compte, non ? Et encore, parce que se battre à
coups de Ko sur une appli installée même sur un Android avec quelques
Go de mémoire ... ben c'est un combat pied à pied quand même.

--
Nicolas Delsaux

[Antonio Goncalves]

Au fait, ça interesse qqu'un de participer à ça, on recherche des volontaires ;o) http://antoniogoncalves.org/2012/09/06/i-need-you-for-logging-api-spec-lead/

Nous essayons de monter un "groupe d'interessés" pour faire en sorte qu'Oracle prenne en compte cette requête et revoir sa copie. C'est pas gagné (ils ne veulent pas de nous ni dans le JCP ni dans les JEP, arguant qu'il existe déjà une API de log dans le JDK)

2012/12/4 Nicolas Delsaux <nicolas...@gmail.com>

--
Nicolas Delsaux

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

[Julien Ponge]

> C'est marrant que tu sois concerné par la taille des jars comme
> critère de choix.

À propos de logging en avec un jar de taille réduite et sans
dépendances je recommande TinyLog http://www.tinylog.org

Pas de fichier XML étrange, une API sans fioritures, une configuration
flexible. Parfait, surtout quand il ne faut pas s'intégrer avec des
loggers de meta-loggers de loggers par dessus les loggers.

- Julien

[Emmanuel Lécharny]

Le 12/4/12 8:09 PM, tvi...@onyme.com a écrit :

> On Tue, 04 Dec 2012 17:58:45 +0100, Emmanuel Lécharny
> <elec...@gmail.com> wrote:
>> Mais ton appli n'est pas embeddable, non ? Sinon, comment tu gères
>> l'intégration dans les systèmes qui t'embeddent ?
>>
> OMG !
> T'es enrhumbé? Si y a un système qui t'embedde du le jedde à la
> boubelle et bis c'est dou.

:) Ca m'a fait sourire, ce qui est toujours agréable !

[Remi Forax]

On 12/04/2012 10:38 PM, Julien Ponge wrote:
>> C'est marrant que tu sois concern� par la taille des jars comme
>> crit�re de choix.
> � propos de logging en avec un jar de taille r�duite et sans
> d�pendances je recommande TinyLog http://www.tinylog.org
>
> Pas de fichier XML �trange, une API sans fioritures, une configuration
> flexible. Parfait, surtout quand il ne faut pas s'int�grer avec des

> loggers de meta-loggers de loggers par dessus les loggers.
>
> - Julien
>

tinylog d�marre une thread en tache de fond qui fait les �critures,
c'est rapide mais quand la VM crash tu as perdu les derniers logs, ceux
qui sont int�ressant. donc c'est vraiment moyen en production, enfin
peut-�tre que je suis le seul � faire crasher la VM assez r�guli�rement*

R�mi
*ok, ok, souvent c'est de ma faute.

[Quang Hung]

Hello, 

Est ce que quelqu'un a déjà testé en PROD ça https://github.com/Netflix/blitz4j/wiki/Blitz4j-at-a-glance ? 

@]++
QHung

2012/12/5 Remi Forax <fo...@univ-mlv.fr>

On 12/04/2012 10:38 PM, Julien Ponge wrote:

C'est marrant que tu sois concerné par la taille des jars comme
critère de choix.

À propos de logging en avec un jar de taille réduite et sans
dépendances je recommande TinyLog http://www.tinylog.org

Pas de fichier XML étrange, une API sans fioritures, une configuration
flexible. Parfait, surtout quand il ne faut pas s'intégrer avec des

loggers de meta-loggers de loggers par dessus les loggers.

- Julien

tinylog démarre une thread en tache de fond qui fait les écritures, c'est rapide mais quand la VM crash tu as perdu les derniers logs, ceux qui sont intéressant. donc c'est vraiment moyen en production, enfin peut-être que je suis le seul à faire crasher la VM assez régulièrement*

Rémi

*ok, ok, souvent c'est de ma faute.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Emmanuel Lécharny]

Le 12/5/12 1:01 AM, Quang Hung a écrit :

> Hello,
>
> Est ce que quelqu'un a déjà testé en PROD ça
> https://github.com/Netflix/blitz4j/wiki/Blitz4j-at-a-glance ?

C'est intéressant. C'est juste dommage qu'au lieu de bosser dans leur
coin, ils n'aient pas poussé leurs idées chez log4j.

Et quand je dis que c'est dommage, je pense que c'est juste complètement
con.

[Olivier Lamy]

Ben ouais mais netflix n'aurait pas pu buzzer ainsi ni "s'approprier" le code...

--
Olivier

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Julien Ponge]

Très juste. Après tu peux aussi désactiver le thread de log : http://www.tinylog.org/user-manual

On Wednesday, December 5, 2012, Remi Forax wrote:

On 12/04/2012 10:38 PM, Julien Ponge wrote:

C'est marrant que tu sois concerné par la taille des jars comme
critère de choix.

À propos de logging en avec un jar de taille réduite et sans
dépendances je recommande TinyLog http://www.tinylog.org

Pas de fichier XML étrange, une API sans fioritures, une configuration
flexible. Parfait, surtout quand il ne faut pas s'intégrer avec des

loggers de meta-loggers de loggers par dessus les loggers.

- Julien

tinylog démarre une thread en tache de fond qui fait les écritures, c'est rapide mais quand la VM crash tu as perdu les derniers logs, ceux qui sont intéressant. donc c'est vraiment moyen en production, enfin peut-être que je suis le seul à faire crasher la VM assez régulièrement*

Rémi

*ok, ok, souvent c'est de ma faute.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

[Remi Forax]

On 12/05/2012 08:42 AM, Julien Ponge wrote:
> Tr�s juste. Apr�s tu peux aussi d�sactiver le thread de log
> :http://www.tinylog.org/user-manual

oui, mais activer la thread de log par d�faut pour pouvoir dire mon
framework est plus rapide que les votres alors qu'en prod il faut le
d�sactiver me semble limite intelectuellement parlant.

R�mi

>
> On Wednesday, December 5, 2012, Remi Forax wrote:
>
> On 12/04/2012 10:38 PM, Julien Ponge wrote:
>

> C'est marrant que tu sois concern� par la taille des jars
> comme

> crit�re de choix.
>
> � propos de logging en avec un jar de taille r�duite et sans

> d�pendances je recommande TinyLog http://www.tinylog.org
>
> Pas de fichier XML �trange, une API sans fioritures, une
> configuration
> flexible. Parfait, surtout quand il ne faut pas s'int�grer

> avec des
> loggers de meta-loggers de loggers par dessus les loggers.
>
> - Julien
>
>

> tinylog d�marre une thread en tache de fond qui fait les
> �critures, c'est rapide mais quand la VM crash tu as perdu les
> derniers logs, ceux qui sont int�ressant. donc c'est vraiment
> moyen en production, enfin peut-�tre que je suis le seul � faire
> crasher la VM assez r�guli�rement*
>
> R�mi

> *ok, ok, souvent c'est de ma faute.
>
> --

> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail �
> lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse

> lescastcodeur...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
>

> --
> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse

[ehsavoie]

Mon appli plante plus souvent que la vm (oups) ;)

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/12/5 Remi Forax <fo...@univ-mlv.fr>

On 12/05/2012 08:42 AM, Julien Ponge wrote:

Très juste. Après tu peux aussi désactiver le thread de log :http://www.tinylog.org/user-manual

oui, mais activer la thread de log par défaut pour pouvoir dire mon framework est plus rapide que les votres alors qu'en prod il faut le désactiver me semble limite intelectuellement parlant.

Rémi

On Wednesday, December 5, 2012, Remi Forax wrote:

    On 12/04/2012 10:38 PM, Julien Ponge wrote:

            C'est marrant que tu sois concerné par la taille des jars
            comme
            critère de choix.

        À propos de logging en avec un jar de taille réduite et sans
        dépendances je recommande TinyLog http://www.tinylog.org

        Pas de fichier XML étrange, une API sans fioritures, une
        configuration
        flexible. Parfait, surtout quand il ne faut pas s'intégrer

        avec des
        loggers de meta-loggers de loggers par dessus les loggers.

        - Julien

    tinylog démarre une thread en tache de fond qui fait les
    écritures, c'est rapide mais quand la VM crash tu as perdu les
    derniers logs, ceux qui sont intéressant. donc c'est vraiment
    moyen en production, enfin peut-être que je suis le seul à faire
    crasher la VM assez régulièrement*

    Rémi

    *ok, ok, souvent c'est de ma faute.

    --     Vous recevez ce message, car vous êtes abonné au groupe Google
    Groupes lescastcodeurs.

    Pour envoyer un message à ce groupe, adressez un e-mail à
    lescastcodeurs@googlegroups.com.

    Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
    lescastcodeurs+unsubscribe@googlegroups.com.

    Pour plus d'options, consultez la page de ce groupe :
    http://groups.google.com/group/lescastcodeurs?hl=fr

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.

Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.

Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Julien Ponge]

Il faudrait voir TinyLog sans thread vs un bon vieux logger à la Log4J. Côté API + config je le trouve néanmoins très sympa. 

Le mercredi 5 décembre 2012, Remi Forax a écrit :

On 12/05/2012 08:42 AM, Julien Ponge wrote:

Très juste. Après tu peux aussi désactiver le thread de log :http://www.tinylog.org/user-manual

oui, mais activer la thread de log par défaut pour pouvoir dire mon framework est plus rapide que les votres alors qu'en prod il faut le désactiver me semble limite intelectuellement parlant.

Rémi

On Wednesday, December 5, 2012, Remi Forax wrote:

    On 12/04/2012 10:38 PM, Julien Ponge wrote:

            C'est marrant que tu sois concerné par la taille des jars
            comme
            critère de choix.

        À propos de logging en avec un jar de taille réduite et sans
        dépendances je recommande TinyLog http://www.tinylog.org

        Pas de fichier XML étrange, une API sans fioritures, une
        configuration
        flexible. Parfait, surtout quand il ne faut pas s'intégrer

        avec des
        loggers de meta-loggers de loggers par dessus les loggers.

        - Julien

    tinylog démarre une thread en tache de fond qui fait les
    écritures, c'est rapide mais quand la VM crash tu as perdu les
    derniers logs, ceux qui sont intéressant. donc c'est vraiment
    moyen en production, enfin peut-être que je suis le seul à faire
    crasher la VM assez régulièrement*

    Rémi

    *ok, ok, souvent c'est de ma faute.

    --     Vous recevez ce message, car vous êtes abonné au groupe Google
    Groupes lescastcodeurs.

    Pour envoyer un message à ce groupe, adressez un e-mail à
    lescast...@googlegroups.com.

    Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse

    lescastcodeur...@googlegroups.com.
    Pour plus d'options, consultez la page de ce groupe :
    http://groups.google.com/group/lescastcodeurs?hl=fr

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.

Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.

Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Julien Ponge]

Comment ça Silverpeas ne génère pas son propre bytecode à la volée ? :-)

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Damien B]

Le 04/12/2012 21:49, Nicolas Delsaux a �crit :
> 2012/12/4 Sebastien Bordes <sebastie...@gmail.com>:
>> Log4j 2 le retour � l'air pas mal ?
>> Quelqu'un l'a d�j� utilis� de mani�re intensive ?
>>
>> Il a l'air rapide d'apr�s leurs chiffres (mais est-ce remarquable), en plus
>> les jars on l'air d'�tre un poil plus petit
>>
> C'est marrant que tu sois concern� par la taille des jars comme
> crit�re de choix.
> Tu bosses sur une appli embarqu�e ? Parce que bon, c'est quand m�me le
> seul cas o� la taille compte, non ?

Ce cas l� et quand on fait des livraisons sur un r�seau qui n'est pas
tip-top niveau d�bit. Quand tu dois livrer de mani�re r�p�t�e un EAR de
5Mo d'un c�t�, et un EAR de 25Mo de l'autre qui fait grosso-modo la m�me
chose, (sauf que les d�veloppeurs ont d�cid� d'embarquer toutes les
d�pendances sans rien nettoyer (en se fichant au passage du fait qu'il
n'est destin� � �tre ex�cut� que sur un serveur d'appli particulier dont
la configuration est d�di�e � l'appli)), � force, c'est quand m�me une
perte de temps, minime � chaque fois certe, mais c'est un confort � ne
pas n�gliger.

Damien B

[Cédric Champeau]

Le 05/12/2012 10:49, Damien B a �crit :

A ce sujet, j'ai d�j� eu le cas avec des WAR d'une centaine de m�gas et
un upload pourri. Pour faciliter �a, j'avais mis en place un truc tout
b�te: un rsync. Du coup, seule la diff �tait upload�e et les mises �
jours ne prennaient plus qu'une poign�e de secondes :) Ca marche
vraiment bien !
> Damien B
>


--
C�dric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau

[Emmanuel Lécharny]

Le 12/5/12 10:49 AM, Damien B a écrit :

> Le 04/12/2012 21:49, Nicolas Delsaux a écrit :
>> 2012/12/4 Sebastien Bordes <sebastie...@gmail.com>:

>>> Log4j 2 le retour à l'air pas mal ?
>>> Quelqu'un l'a déjà utilisé de manière intensive ?
>>>
>>> Il a l'air rapide d'après leurs chiffres (mais est-ce remarquable),
>>> en plus

>>> les jars on l'air d'être un poil plus petit
>>>
>> C'est marrant que tu sois concerné par la taille des jars comme
>> critère de choix.
>> Tu bosses sur une appli embarquée ? Parce que bon, c'est quand même le

>> seul cas où la taille compte, non ?
>
> Ce cas là et quand on fait des livraisons sur un réseau qui n'est pas
> tip-top niveau débit. Quand tu dois livrer de manière répétée un EAR
> de 5Mo d'un côté, et un EAR de 25Mo de l'autre qui fait grosso-modo la
> même chose, (sauf que les développeurs ont décidé d'embarquer toutes
> les dépendances sans rien nettoyer (en se fichant au passage du fait
> qu'il n'est destiné à être exécuté que sur un serveur d'appli
> particulier dont la configuration est dédiée à l'appli)), à force,
> c'est quand même une perte de temps, minime à chaque fois certe, mais
> c'est un confort à ne pas négliger.

log4j.jar fait 489ko. Disons 0,5 Mo. C'est 10% de ton premier EAR, et 2%
de ton second EAR. Sur un réseau capilaire à 10 Mo, c'est 25 secondes au
lieu de 5 secondes. Pas franchement la mort. D'autant que log4j va
représenter une demi seconde...

[Thibaud Vibes]

Le 04/12/2012 15:26, Emmanuel Lécharny a écrit :
> Salut !
>
> ça fait longtemps, mais je pense que passé septembre, tout le monde est
> en pleine brasse coulée...
>
> On discutait récemment des loggers, un serpent de mer(de) qui revient
> souvent dans les conversations. Log4j, JUL, JULI, slf4j, logback,
> log4j2, clog, tinylog, on a un chiée de loggers existants et plus
> personne ne sait ou donner de la tête, c'est style pire que les nouveaux
> langages qui fleurissent tous les jours. Sans compter les ceusses qui ne
> jurent que par System.out( "ta gueule, log4j !" );
>
> Vous utilisez quoi, et pourquoi ?
>

Sujet un peu connexe:
est-ce que y a des solutions pour déporter les logs sur un serveur syslog?
Est-ce que vous avez déjà fait ça?
A priori ça me parait bien de centraliser quand on a plusieurs applis.
ça évite de rappatrier les logs éclatés un peu partout quand on doit
analyser/retrouver la cause d'un problème (Des fois je suis tellement
lazy que je grep direct sur le serveur de prod, je sais saymal).

J'ai googlé vite fait et j'ai trouvé des lib telles que syslog4j.
Il semble exister des appender Log4j pour balancer vers le serveur syslog.


Alors FBI* ou pas?

(*Fausse Bonne Idée)

[Laurent Forêt]

Pour le sujet connexe j'ai en mon temps utilisé l'appender log4j syslog et ça avait fait le boulot, c'est à dire faire de la trace fonctionnelle.

Simple à configurer et efficace, en plus log4j était le système de logging utilisé dans l'appli. 

Laurent Forêt

@laurentforet
http://www.devcoop.fr

2012/12/5 Thibaud Vibes <tvi...@onyme.com>

[ehsavoie]

Si mais on le fait bien ;o)

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/12/5 Julien Ponge <julien...@gmail.com>

[Damien B]

Le 05/12/2012 11:04, Emmanuel L�charny a �crit :
> Le 12/5/12 10:49 AM, Damien B a �crit :
>> Le 04/12/2012 21:49, Nicolas Delsaux a �crit :
>>> 2012/12/4 Sebastien Bordes <sebastie...@gmail.com>:

>>>> Log4j 2 le retour � l'air pas mal ?

>>>> Quelqu'un l'a d�j� utilis� de mani�re intensive ?
>>>>
>>>> Il a l'air rapide d'apr�s leurs chiffres (mais est-ce remarquable),
>>>> en plus

>>>> les jars on l'air d'�tre un poil plus petit
>>>>
>>> C'est marrant que tu sois concern� par la taille des jars comme
>>> crit�re de choix.
>>> Tu bosses sur une appli embarqu�e ? Parce que bon, c'est quand m�me le
>>> seul cas o� la taille compte, non ?
>> Ce cas l� et quand on fait des livraisons sur un r�seau qui n'est pas
>> tip-top niveau d�bit. Quand tu dois livrer de mani�re r�p�t�e un EAR
>> de 5Mo d'un c�t�, et un EAR de 25Mo de l'autre qui fait grosso-modo la
>> m�me chose, (sauf que les d�veloppeurs ont d�cid� d'embarquer toutes
>> les d�pendances sans rien nettoyer (en se fichant au passage du fait
>> qu'il n'est destin� � �tre ex�cut� que sur un serveur d'appli
>> particulier dont la configuration est d�di�e � l'appli)), � force,

>> c'est quand m�me une perte de temps, minime � chaque fois certe, mais
>> c'est un confort � ne pas n�gliger.

> log4j.jar fait 489ko. Disons 0,5 Mo. C'est 10% de ton premier EAR, et 2%

> de ton second EAR. Sur un r�seau capilaire � 10 Mo, c'est 25 secondes au

> lieu de 5 secondes. Pas franchement la mort. D'autant que log4j va

> repr�senter une demi seconde...
L� tu regardes l'impact d'*un* jar sur *un* transfert. Je r�pondais plus
globalement, et mon EAR n'est pas copi� qu'une fois : il commence sa vie
copi� de l'esclave Hudson/Jenkins vers le ma�tre, il est recopi� vers le
stockage des livrables (quel qu'il soit, et potentiellement avec un truc
aussi aussi nul que wagon-http), il est recopi� chez le client par un
VPN r�guli�rement satur�, il est recopi� n fois chez le client entre les
4 environnements et les divers serveurs correspondants de la r�ception �
la production. Un minimum d'attention aux jars embarqu�s dans le
livrable et � leur taille (m�me si je reconnais que la v�rification des
jars embarqu�s repr�sente un gain plus important), �a apporte quand m�me
un certain confort quand tu es en livraison r�p�t�e.

Damien B

[Arnaud Héritier]

logback sait le faire je crois mais je n'ai pas testé.

2012/12/5 Thibaud Vibes <tvi...@onyme.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Emmanuel Lécharny]

Le 12/5/12 11:42 AM, Damien B a écrit :
> Le 05/12/2012 11:04, Emmanuel Lécharny a écrit :
>> Le 12/5/12 10:49 AM, Damien B a écrit :

>>> Le 04/12/2012 21:49, Nicolas Delsaux a écrit :
>>>> 2012/12/4 Sebastien Bordes <sebastie...@gmail.com>:

>>>>> Log4j 2 le retour à l'air pas mal ?
>>>>> Quelqu'un l'a déjà utilisé de manière intensive ?
>>>>>
>>>>> Il a l'air rapide d'après leurs chiffres (mais est-ce remarquable),
>>>>> en plus

>>>>> les jars on l'air d'être un poil plus petit
>>>>>
>>>> C'est marrant que tu sois concerné par la taille des jars comme
>>>> critère de choix.
>>>> Tu bosses sur une appli embarquée ? Parce que bon, c'est quand même le
>>>> seul cas où la taille compte, non ?
>>> Ce cas là et quand on fait des livraisons sur un réseau qui n'est pas
>>> tip-top niveau débit. Quand tu dois livrer de manière répétée un EAR
>>> de 5Mo d'un côté, et un EAR de 25Mo de l'autre qui fait grosso-modo la
>>> même chose, (sauf que les développeurs ont décidé d'embarquer toutes
>>> les dépendances sans rien nettoyer (en se fichant au passage du fait
>>> qu'il n'est destiné à être exécuté que sur un serveur d'appli
>>> particulier dont la configuration est dédiée à l'appli)), à force,

>>> c'est quand même une perte de temps, minime à chaque fois certe, mais
>>> c'est un confort à ne pas négliger.

>> log4j.jar fait 489ko. Disons 0,5 Mo. C'est 10% de ton premier EAR, et 2%

>> de ton second EAR. Sur un réseau capilaire à 10 Mo, c'est 25 secondes au

>> lieu de 5 secondes. Pas franchement la mort. D'autant que log4j va

>> représenter une demi seconde...
> Là tu regardes l'impact d'*un* jar sur *un* transfert. Je répondais
> plus globalement, et mon EAR n'est pas copié qu'une fois : il commence
> sa vie copié de l'esclave Hudson/Jenkins vers le maître, il est
> recopié vers le stockage des livrables (quel qu'il soit, et

> potentiellement avec un truc aussi aussi nul que wagon-http), il est

> recopié chez le client par un VPN régulièrement saturé, il est recopié

> n fois chez le client entre les 4 environnements et les divers

> serveurs correspondants de la réception à la production. Un minimum
> d'attention aux jars embarqués dans le livrable et à leur taille (même
> si je reconnais que la vérification des jars embarqués représente un
> gain plus important), ça apporte quand même un certain confort quand
> tu es en livraison répétée.

Le problème n'est pas la taille des jars embarqués... Le pb, c'est que
vous diffusez un package à trop d'endroit, sur un réseau trop serré.

C'est comme acheter de plus grandes bassines parce que tu as une fuite
chez toi...

[Emmanuel Lécharny]

Le 12/5/12 11:45 AM, Arnaud Héritier a écrit :

> logback sait le faire je crois mais je n'ai pas testé.

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/SyslogAppender.html

http://wiki.apache.org/logging-log4j/syslog

[Damien B]

Le 05/12/2012 11:50, Emmanuel L�charny a �crit :
> Le 12/5/12 11:42 AM, Damien B a �crit :
>> Le 05/12/2012 11:04, Emmanuel L�charny a �crit :
>>> Le 12/5/12 10:49 AM, Damien B a �crit :
>>>> Le 04/12/2012 21:49, Nicolas Delsaux a �crit :
>>>>> 2012/12/4 Sebastien Bordes <sebastie...@gmail.com>:

>>>>>> Log4j 2 le retour � l'air pas mal ?

>>>>>> Quelqu'un l'a d�j� utilis� de mani�re intensive ?
>>>>>>
>>>>>> Il a l'air rapide d'apr�s leurs chiffres (mais est-ce remarquable),
>>>>>> en plus

>>>>>> les jars on l'air d'�tre un poil plus petit
>>>>>>
>>>>> C'est marrant que tu sois concern� par la taille des jars comme
>>>>> crit�re de choix.
>>>>> Tu bosses sur une appli embarqu�e ? Parce que bon, c'est quand m�me le

>>>>> seul cas o� la taille compte, non ?
>>>> [...]Ce cas l� et quand on fait des livraisons sur un r�seau qui n'est pas

>>>> tip-top niveau d�bit. Quand tu dois livrer de mani�re r�p�t�e un EAR
>>>> de 5Mo d'un c�t�, et un EAR de 25Mo de l'autre qui fait grosso-modo la
>>>> m�me chose, (sauf que les d�veloppeurs ont d�cid� d'embarquer toutes
>>>> les d�pendances sans rien nettoyer (en se fichant au passage du fait
>>>> qu'il n'est destin� � �tre ex�cut� que sur un serveur d'appli
>>>> particulier dont la configuration est d�di�e � l'appli)), � force,

>>>> c'est quand m�me une perte de temps, minime � chaque fois certe, mais
>>>> c'est un confort � ne pas n�gliger.

>>> log4j.jar fait 489ko. Disons 0,5 Mo. C'est 10% de ton premier EAR, et 2%

>>> de ton second EAR. Sur un r�seau capilaire � 10 Mo, c'est 25 secondes au

>>> lieu de 5 secondes. Pas franchement la mort. D'autant que log4j va

>>> repr�senter une demi seconde...
>> L� tu regardes l'impact d'*un* jar sur *un* transfert. Je r�pondais
>> plus globalement, et mon EAR n'est pas copi� qu'une fois : il commence
>> sa vie copi� de l'esclave Hudson/Jenkins vers le ma�tre, il est

>> recopi� vers le stockage des livrables (quel qu'il soit, et

>> potentiellement avec un truc aussi aussi nul que wagon-http), il est

>> recopi� chez le client par un VPN r�guli�rement satur�, il est recopi�

>> n fois chez le client entre les 4 environnements et les divers

>> serveurs correspondants de la r�ception � la production. Un minimum
>> d'attention aux jars embarqu�s dans le livrable et � leur taille (m�me
>> si je reconnais que la v�rification des jars embarqu�s repr�sente un

>> gain plus important), �a apporte quand m�me un certain confort quand
>> tu es en livraison r�p�t�e.
> Le probl�me n'est pas la taille des jars embarqu�s... Le pb, c'est que
> vous diffusez un package � trop d'endroit, sur un r�seau trop serr�.

>
> C'est comme acheter de plus grandes bassines parce que tu as une fuite
> chez toi...

Ben justement : je ne suis pas chez moi :-) Apr�s on peut toujours
discuter de la n�cessit� d'avoir le package � "trop" d'endroits (et tous
les liens ne sont pas serr�s, mais il y a des goulots c'est s�r),
toujours est-il que dans une approche d'am�lioration continue, c'est
bien que chacun y mette du sien et enl�ve le gras, c'est aussi �a
l'approche lean :-)

[Emmanuel Lécharny]

Le 12/5/12 12:07 PM, Damien B a écrit :
> Le 05/12/2012 11:50, Emmanuel Lécharny a écrit :
>> Le problème n'est pas la taille des jars embarqués... Le pb, c'est que
>> vous diffusez un package à trop d'endroit, sur un réseau trop serré.

>>
>> C'est comme acheter de plus grandes bassines parce que tu as une fuite
>> chez toi...
>

> Ben justement : je ne suis pas chez moi :-) Après on peut toujours
> discuter de la nécessité d'avoir le package à "trop" d'endroits (et
> tous les liens ne sont pas serrés, mais il y a des goulots c'est sûr),
> toujours est-il que dans une approche d'amélioration continue, c'est
> bien que chacun y mette du sien et enlève le gras, c'est aussi ça
> l'approche lean :-)

En modifiant ta livraison pour "résoudre" les pb réseau, tu modifies le
comportement de ton appli : maintenant, elle dépend de packages fournis
par ton serveur d'application, au lieu d'être standalone. C'est quand
même la garantie de pb potentiels le jour où tu bascules vers une
nouvelle version/ un autre serveur.

Contourner un pb n'est pas le résoudre...

[Damien B]

Le 05/12/2012 12:20, Emmanuel L�charny a �crit :
> Le 12/5/12 12:07 PM, Damien B a �crit :

>> Le 05/12/2012 11:50, Emmanuel L�charny a �crit :

>>> Le probl�me n'est pas la taille des jars embarqu�s... Le pb, c'est que
>>> vous diffusez un package � trop d'endroit, sur un r�seau trop serr�.
>>>

>>> C'est comme acheter de plus grandes bassines parce que tu as une fuite
>>> chez toi...

>> Ben justement : je ne suis pas chez moi :-) Apr�s on peut toujours

>> discuter de la n�cessit� d'avoir le package � "trop" d'endroits (et
>> tous les liens ne sont pas serr�s, mais il y a des goulots c'est s�r),
>> toujours est-il que dans une approche d'am�lioration continue, c'est
>> bien que chacun y mette du sien et enl�ve le gras, c'est aussi �a
>> l'approche lean :-)
> En modifiant ta livraison pour "r�soudre" les pb r�seau, tu modifies le
> comportement de ton appli
Je ne modifie pas ma livraison pour r�soudre les probl�mes r�seau : je
construis (m�me si le plus souvent c'est de la reprise et pas de la
construction) une application qui d�pend d'un socle, et plut�t que de
dire "ouais, encore un truc de niaiseux, je vais tout embarquer au cas
o�", je dis "profitons-en, et en plus �a r�duit la taille du livrable,
tout b�nef".

> : maintenant, elle d�pend de packages fournis
> par ton serveur d'application, au lieu d'�tre standalone.
Il faut tracer une ligne quelque part : quel besoin d'embarquer JTA,
Mail, JAX-WS, etc.. exactement ? "Standalone" �a n'est pas un absolu, tu
d�pends toujours d'une version minimale du JRE (et ce n'est pas quelque
chose de mineur en terme de complexit�), et dans le cas pr�sent, d'un
serveur d'application avec un certain niveau de compatibilit� avec une
version sp�cifique de JavaEE (ce qui est loin d'�tre mineur aussi). Et
puis pourquoi �viter cette d�pendance quand, dans ce contexte toujours,
c'est un entrant du syst�me et pas une variable ?

> C'est quand m�me la garantie de pb potentiels le jour o� tu bascules vers une

> nouvelle version/ un autre serveur.

Dans ce cas-l� on embarque le serveur d'application, et la JVM aussi au
passage ? Ha non on ne peut pas, �a met une d�pendance sur l'OS. Et la
bascule vers une nouvelle version / un autre serveur, dans ce contexte,
c'est un chantier autrement plus important que r�soudre les probl�mes de
descripteur de d�ploiement sp�cifiques ou de mont�e de version des
d�pendances ou comportement "exotiques" des classloaders.

> Contourner un pb n'est pas le r�soudre...
Pour �a il faudrait commencer par �noncer le probl�me :-D Je commentais
par rapport � une interrogation g�n�rique par rapport � la taille des
jars, et c'est toi qui r�duit �a � une probl�matique de lien r�seau :-)
On peut parler aussi de la vitesse de d�marrage serveur, de la facilit�
de d�bogage, de l'empreinte m�moire de l'appli, de l'entr�e d'un nouveau
d�veloppeur sur l'appli, etc...

[Sebastien Bordes]

Quand je parlais de taille minimale ce n'était pas pour diminuer la taille d'un WAR/EAR
Vous auriez presque pu deviner mon but quand j'ai évoqué pack200 qui est une obscure facon de compresser un jar avant de le passer à la moulinette de Gzip, les gains sont conséquents (/4).
Dans mon cas c'est pour être diffuser avec JWS.
Comme je fourni un framework sensé être léger (<50ko avec pack200) et qui doit pouvoir permettre de créer des applications online et standalone je n'ai pas envie d'imposer des dépendances trop lourde ou trop peu configurable.
C'est pour ça que j'ai opté pour slf4j avec optionnellement logback pour du standalone et nada pour du pur web.

Concernant la log dans le syslog, pour moi c'est une pas très bonne idée :
je m'explique je dois souvent lire beaucoup de logs d'un système embarqué avec plusieurs applications Java tournant dessus (15app java sur 3 ordis),

Quand chaque app a sa log on peut se concentrer plus facilement sur ces problèmes. Par contre il est plus difficile de mettre tout en ligne sur le plan temporel (surtout quand les différents ordi n'ont pas la même heure; très fréquent en phase d'intégration :( ... )
Tout écrire dans le syslog va produire un volume enorme de log pouvant être filtré certes mais compliquant la tache.

Donc je préfère largement lire des log à plat (a bas la bonne blague de logger en xml !!)

Seb




Le mercredi 5 décembre 2012 12:52:45 UTC+1, Damien B a écrit :

Le 05/12/2012 12:20, Emmanuel L�charny a �crit :
> Le 12/5/12 12:07 PM, Damien B a �crit :
>> Le 05/12/2012 11:50, Emmanuel L�charny a �crit :
>>> Le probl�me n'est pas la taille des jars embarqu�s... Le pb, c'est que
>>> vous diffusez un package � trop d'endroit, sur un r�seau trop serr�.

>>>
>>> C'est comme acheter de plus grandes bassines parce que tu as une fuite
>>> chez toi...

>> Ben justement : je ne suis pas chez moi :-) Apr�s on peut toujours
>> discuter de la n�cessit� d'avoir le package � "trop" d'endroits (et
>> tous les liens ne sont pas serr�s, mais il y a des goulots c'est s�r),
>> toujours est-il que dans une approche d'am�lioration continue, c'est
>> bien que chacun y mette du sien et enl�ve le gras, c'est aussi �a
>> l'approche lean :-)
> En modifiant ta livraison pour "r�soudre" les pb r�seau, tu modifies le
> comportement de ton appli
Je ne modifie pas ma livraison pour r�soudre les probl�mes r�seau : je
construis (m�me si le plus souvent c'est de la reprise et pas de la
construction) une application qui d�pend d'un socle, et plut�t que de

dire "ouais, encore un truc de niaiseux, je vais tout embarquer au cas

o�", je dis "profitons-en, et en plus �a r�duit la taille du livrable,
tout b�nef".

>   : maintenant, elle d�pend de packages fournis
> par ton serveur d'application, au lieu d'�tre standalone.

Il faut tracer une ligne quelque part : quel besoin d'embarquer JTA,

Mail, JAX-WS, etc.. exactement ? "Standalone" �a n'est pas un absolu, tu
d�pends toujours d'une version minimale du JRE (et ce n'est pas quelque
chose de mineur en terme de complexit�), et dans le cas pr�sent, d'un
serveur d'application avec un certain niveau de compatibilit� avec une
version sp�cifique de JavaEE (ce qui est loin d'�tre mineur aussi). Et
puis pourquoi �viter cette d�pendance quand, dans ce contexte toujours,
c'est un entrant du syst�me et pas une variable ?

> C'est quand m�me la garantie de pb potentiels le jour o� tu bascules vers une

> nouvelle version/ un autre serveur.

Dans ce cas-l� on embarque le serveur d'application, et la JVM aussi au
passage ? Ha non on ne peut pas, �a met une d�pendance sur l'OS. Et la

bascule vers une nouvelle version / un autre serveur, dans ce contexte,

c'est un chantier autrement plus important que r�soudre les probl�mes de
descripteur de d�ploiement sp�cifiques ou de mont�e de version des
d�pendances ou comportement "exotiques" des classloaders.

> Contourner un pb n'est pas le r�soudre...
Pour �a il faudrait commencer par �noncer le probl�me :-D Je commentais
par rapport � une interrogation g�n�rique par rapport � la taille des
jars, et c'est toi qui r�duit �a � une probl�matique de lien r�seau :-)
On peut parler aussi de la vitesse de d�marrage serveur, de la facilit�
de d�bogage, de l'empreinte m�moire de l'appli, de l'entr�e d'un nouveau
d�veloppeur sur l'appli, etc...

[Emmanuel Lécharny]

Le 12/5/12 1:32 PM, Sebastien Bordes a écrit :

> Quand je parlais de taille minimale ce n'était pas pour diminuer la taille
> d'un WAR/EAR
> Vous auriez presque pu deviner mon but quand j'ai évoqué pack200 qui est
> une obscure facon de compresser un jar avant de le passer à la moulinette
> de Gzip, les gains sont conséquents (/4).

Je suis *très* étonné qu'on puisse compresser un jar d'un facteur 4. Un
jar est *déjà* compressé, j'ai du mal à imaginer qu'on puisse gagner
pkus que quelques % en le recompressant... Ou alors, il s'agit de qqhose
de tout à fait différent (style, nettoyage des classes et des jars avant
recompression).

Tu peux nous en dire plus ?

> Dans mon cas c'est pour être diffuser avec JWS.
> Comme je fourni un framework sensé être léger (<50ko avec pack200) et qui
> doit pouvoir permettre de créer des applications online et standalone je
> n'ai pas envie d'imposer des dépendances trop lourde ou trop peu
> configurable.
> C'est pour ça que j'ai opté pour slf4j avec optionnellement logback pour du
> standalone et nada pour du pur web.

Ok, raisonnable.

>
> Concernant la log dans le syslog, pour moi c'est une pas très bonne idée :
> je m'explique je dois souvent lire beaucoup de logs d'un système embarqué
> avec plusieurs applications Java tournant dessus (15app java sur 3 ordis),

Syslog, c'est généralement une demande de l'équipe système, qui met en
place une administartion des logs centralisée. On est obligé de s'y plier :/

[Damien B]

Le 05/12/2012 14:33, Emmanuel L�charny a �crit :
> Le 12/5/12 1:32 PM, Sebastien Bordes a �crit :
>> Quand je parlais de taille minimale ce n'�tait pas pour diminuer la taille
>> d'un WAR/EAR
>> Vous auriez presque pu deviner mon but quand j'ai �voqu� pack200 qui est
>> une obscure facon de compresser un jar avant de le passer � la moulinette
>> de Gzip, les gains sont cons�quents (/4).
> Je suis *tr�s* �tonn� qu'on puisse compresser un jar d'un facteur 4. Un
> jar est *d�j�* compress�, j'ai du mal � imaginer qu'on puisse gagner

> pkus que quelques % en le recompressant... Ou alors, il s'agit de qqhose

> de tout � fait diff�rent (style, nettoyage des classes et des jars avant
> recompression).

Pack200 �a date du JRE 1.5 pour le support dans JWS, le seul truc c'est
que �a n'est pas support� en natif dans le JRE au niveau du classloader,
d'o� le fait que �a soit peu r�pandu (et que les gens ne s'int�ressent
plus aux tailles des jars non plus ;-P ). L'avantage du pack200 c'est
qu'il travaille en connaissant le bytecode et pas sur un paquet opaque
d'octets, d'o� l'efficait�. La doc de l'�poque l'explique pas mal :
http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html#pack200_compression

"Pack200 works most efficiently on Java class files. It uses several
techniques to efficiently reduce the size of JAR files:
It merges and sorts the constant-pool data in the class files and
co-locates them in the archive.
It removes redundant class attributes.
It stores internal data structures.
It use delta and variable length encoding.
It chooses optimum coding types for secondary compression."

Et ils mettent un petit comparatif sur un exemple :
Notepad.jar 987.47 kb // pas de compression interne
Notepad.jar 46.25 kb // avec compression jar normale
Notepad.jar.gz 43.00 kb // avec compression interne + gzip
Notepad.jar.gz 32.47 kb // sans compression interne + gzip
Notepad.jar.pack.gz 22.58 kb // avec pack200 (qui implique un gzippage)

[Julien Gaucher]

Question subsidiaire sur pack2000 vu que je vois qu'il y a des connaisseurs : quelqu'un arrive a faire ses jar avec ET avec maven (sans monter un plugin a gaz) ? (j'avais cherché et rien trouvé)

2012/12/5 Damien B <night...@gmail.com>

Pack200 ça date du JRE 1.5 pour le support dans JWS, le seul truc c'est que ça n'est pas supporté en natif dans le JRE au niveau du classloader, d'où le fait que ça soit peu répandu (et que les gens ne s'intéressent plus aux tailles des jars non plus ;-P ). L'avantage du pack200 c'est qu'il travaille en connaissant le bytecode et pas sur un paquet opaque d'octets, d'où l'efficaité. La doc de l'époque l'explique pas mal :

[Remi Forax]

On 12/05/2012 02:33 PM, Emmanuel L�charny wrote:
> Le 12/5/12 1:32 PM, Sebastien Bordes a �crit :
>> Quand je parlais de taille minimale ce n'�tait pas pour diminuer la taille
>> d'un WAR/EAR

>> Vous auriez presque pu deviner mon but quand j'ai �voqu� pack200 qui est
>> une obscure facon de compresser un jar avant de le passer � la moulinette
>> de Gzip, les gains sont cons�quents (/4).
> Je suis *tr�s* �tonn� qu'on puisse compresser un jar d'un facteur 4. Un

> jar est *d�j�* compress�, j'ai du mal � imaginer qu'on puisse gagner

> pkus que quelques % en le recompressant... Ou alors, il s'agit de qqhose

> de tout � fait diff�rent (style, nettoyage des classes et des jars avant

> recompression).
>
> Tu peux nous en dire plus ?

pack200 (doit compresser 200 fois si on se fit au nom) est un algo de
compression � la gzip
mais le dictionnaire utilis� est globale � tout le jar, alors que zip
utilise un dictionnaire par classe
et l'algo a �t� �crit sp�cifiquement pour compresser des .class, donc y
a plein de ruses pour sauvegarder quelques bits par �i, par l�.

Le format de sortie n'est donc pas un jar lisible avec winzip,
basiquement cela veut dire qu'il existe deux formats de jar, mais pack200
est capable de transformer du format jar classique vers le format
pack200 et vice-versa.

R�mi

>
>> Dans mon cas c'est pour �tre diffuser avec JWS.
>> Comme je fourni un framework sens� �tre l�ger (<50ko avec pack200) et qui
>> doit pouvoir permettre de cr�er des applications online et standalone je
>> n'ai pas envie d'imposer des d�pendances trop lourde ou trop peu
>> configurable.
>> C'est pour �a que j'ai opt� pour slf4j avec optionnellement logback pour du

>> standalone et nada pour du pur web.
> Ok, raisonnable.

>> Concernant la log dans le syslog, pour moi c'est une pas tr�s bonne id�e :
>> je m'explique je dois souvent lire beaucoup de logs d'un syst�me embarqu�

>> avec plusieurs applications Java tournant dessus (15app java sur 3 ordis),

> Syslog, c'est g�n�ralement une demande de l'�quipe syst�me, qui met en
> place une administartion des logs centralis�e. On est oblig� de s'y plier :/
>
>

[Sebastien Bordes]

Pour Pack200
Voici la doc officielle (nouveauté Java5 si je ne me trompes pas) : http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/pack200.html

Voici un exemple de compression, on oscille entre /2 et /3.5 => http://apps.jrebirth.org/lightningtalk/1.0.0/lib/ (jar raw et jar.pack.gz)
((désolé mais le code est une appli #JavaFX :) http://www.jrebirth.org/lightningtalk.html ))
Dans ce cas on passe de 4.45 => 3.03Mo car les png inclus ne se recompressent pas eux ...
Sans eux on passe de 1.97 à 0.607ko donc un ratio de 1 / 3.2

Pour le syslog, si c'est eux qui les lisent qui font le diagnostic ou qui fournissent une extraction 'propre' des log utiles , pourquoi pas
Il ne faut confondre centralisation et mélange des logs car au bout du chemin il y a toujours un pauvre gars qui doit se les palucher pour expliquer la cause du problème et lire des dizaines de Mo de log c'est vraiment pas marrant.

Après ça dépend beaucoup du système a surveiller.
Un serveur web n'aura pas les mêmes besoins qu'une appli standalone et qu'un système multi-appli ...
Mais l'interet de tout mettre dans le syslog et de pouvoir étudier les interactions entre plusieurs processus, ce qui n'est pas évident sans avoir un 'TimeMachine Loguilder' pour ordonner tout ca, les différents systèmes de logs pouvant induire un petit décalage faussant l'analyse.

Seb

[Emmanuel Lécharny]

Le 12/5/12 2:47 PM, Damien B a écrit :
> Le 05/12/2012 14:33, Emmanuel Lécharny a écrit :
>> Le 12/5/12 1:32 PM, Sebastien Bordes a écrit :
>>> Quand je parlais de taille minimale ce n'était pas pour diminuer la
>>> taille
>>> d'un WAR/EAR
>>> Vous auriez presque pu deviner mon but quand j'ai évoqué pack200 qui
>>> est
>>> une obscure facon de compresser un jar avant de le passer à la
>>> moulinette

>>> de Gzip, les gains sont conséquents (/4).
>> Je suis *très* étonné qu'on puisse compresser un jar d'un facteur 4. Un

>> jar est *déjà* compressé, j'ai du mal à imaginer qu'on puisse gagner

>> pkus que quelques % en le recompressant... Ou alors, il s'agit de qqhose

>> de tout à fait différent (style, nettoyage des classes et des jars avant
>> recompression).
>

> Pack200 ça date du JRE 1.5 pour le support dans JWS, le seul truc
> c'est que ça n'est pas supporté en natif dans le JRE au niveau du

> classloader, d'où le fait que ça soit peu répandu (et que les gens ne
> s'intéressent plus aux tailles des jars non plus ;-P ). L'avantage du

> pack200 c'est qu'il travaille en connaissant le bytecode et pas sur un

> paquet opaque d'octets, d'où l'efficaité. La doc de l'époque

> l'explique pas mal :
> http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html#pack200_compression
>

Intéressant...

Et les jars pack200tés restent compatibles ?

(comme le dit qqun sur la mailing list, ça pourrait déchirer de
pack200ter tous les jars dans Maven !)

[Sebastien Bordes]

Pour utiliser pack 200 avec maven il faut utiliser le plugin maven-webstart-plugin (ca s'invente pas !)

Voici un exemple => https://github.com/JRebirth/LightningTalk/blob/master/org.jrebirth.presentation.lightningtalk/pom.xml

				<groupId>org.codehaus.mojo</groupId>
				<artifactId>webstart-maven-plugin</artifactId>
				<version>1.0-beta-3</version>

				<executions>
					<execution>
						<phase>package</phase>
						<goals>
							<goal>jnlp</goal>
						</goals>
					</execution>
				</executions>

				<configuration>

					<jnlpFiles>${jrebirth.jnlp.filename}</jnlpFiles>
					<excludeTransitive>false</excludeTransitive>
					<libPath>lib</libPath>

					<resourcesDirectory>${project.basedir}/src/main/jnlp/resources</resourcesDirectory>
					<codebase>${deployUrl}/${deployPath}</codebase>

					<jnlp>
						<!-- <inputTemplateResourcePath>${project.basedir}</inputTemplateResourcePath> <inputTemplate>src/main/jnlp/template.vm</inputTemplate> -->
						<outputFile>${jnlpFilename}</outputFile>

						<mainClass>${appClass}</mainClass>
						<offlineAllowed>true</offlineAllowed>
					</jnlp>

					<sign>
						<keystore>${basedir}/jrebirth.jks</keystore>
						<keypass>${keypass}</keypass>
						<storepass>${storepass}</storepass>
						<!-- <storetype>fillme</storetype> -->
						<alias>jrebirth</alias>

						<validity>360</validity>
						<dnameCn>www.jrebirth.org</dnameCn>
						<dnameOu>None</dnameOu>
						<dnameO>JRebirth</dnameO>
						<dnameL>Toulouse</dnameL>
						<dnameSt>HG</dnameSt>
						<dnameC>FR</dnameC>

						<verify>true</verify>

						<keystoreConfig>
							<delete>true</delete>
							<gen>true</gen>
						</keystoreConfig>
					</sign>

					<pack200>true</pack200>
					<gzip>true</gzip>

					<outputJarVersions>false</outputJarVersions>
					<install>false</install>
					<verbose>true</verbose>
				</configuration>
			</plugin>

Info complémentaire: le chargement doit se faire d'une façon particulière par le client (Java), avec la JDk6 il y avait une DownloadServlet capable d'envoyer au client Webstart soit la version pack.gz soit le jar raw en fonction du MIME accepté.J'ai cru lire que dans les versions ultérieures le client Java faisait la double requête mais je n'ai pas encore vérifié...

Pack 200 a été un peu oublié suite à la fin des applets, mais va peut etre revenir avec JavaFX, quant à packer200 les jars dans Maven je ne sais pas si c'est faisable.... car il doit y avoir des infos qui se perde comme sans doute les numero de lignes utiles pour les stacktrace... je vais vérifier ca de ce pas

Seb

Le mardi 4 décembre 2012 15:26:11 UTC+1, Emmanuel Lecharny a écrit :

Salut !

ça fait longtemps, mais je pense que passé septembre, tout le monde est
en pleine brasse coulée...

On discutait récemment des loggers, un serpent de mer(de) qui revient
souvent dans les conversations. Log4j, JUL, JULI, slf4j, logback,
log4j2, clog, tinylog, on a un chiée de loggers existants et plus
personne ne sait ou donner de la tête, c'est style pire que les nouveaux
langages qui fleurissent tous les jours. Sans compter les ceusses qui ne
jurent que par System.out( "ta gueule, log4j !" );

Vous utilisez quoi, et pourquoi ?

[Nicolas Delsaux]

2012/12/5 Remi Forax <fo...@univ-mlv.fr>:

>
> pack200 (doit compresser 200 fois si on se fit au nom) est un algo de

> compression à la gzip
> mais le dictionnaire utilisé est globale à tout le jar, alors que zip

> utilise un dictionnaire par classe

> et l'algo a été écrit spécifiquement pour compresser des .class, donc y a
> plein de ruses pour sauvegarder quelques bits par çi, par là.

Sur un EAR de 50 Mo, ca pourrait faire du bien si ça marche - et que
ça s'intègre dans maven.

>
> Le format de sortie n'est donc pas un jar lisible avec winzip, basiquement
> cela veut dire qu'il existe deux formats de jar, mais pack200
> est capable de transformer du format jar classique vers le format pack200 et
> vice-versa.

Donc le "nouveau" jar n'est plus un fichier facile à ouvrir ... Ca
donne à réfléchir, je trouve, aprce que c'est uns acré avantage des
jars "normaux".
En bonus, pour que ce soit utile sur une appli comme la mienne, il
faut sans doute reprendre tous les JARs des dépendances pour les
ré-empaqueter, non ? Effectivement, ça sent le plugin-à-gaz (très
bonne expression).

--
Nicolas Delsaux

[Thibaud Vibes]

Le 05/12/2012 15:08, Emmanuel Lécharny a écrit :
> Intéressant...
>
> Et les jars pack200tés restent compatibles ?
>
> (comme le dit qqun sur la mailing list, ça pourrait déchirer de
> pack200ter tous les jars dans Maven !)

Personnellement je préfère pack2douzer
ça déchire bien aussi à la Leffe Triple

[Damien B]

Le 05/12/2012 15:08, Emmanuel L�charny a �crit :
> Le 12/5/12 2:47 PM, Damien B a �crit :
>> Le 05/12/2012 14:33, Emmanuel L�charny a �crit :
>>> Le 12/5/12 1:32 PM, Sebastien Bordes a �crit :
>>>> Quand je parlais de taille minimale ce n'�tait pas pour diminuer la
>>>> taille
>>>> d'un WAR/EAR
>>>> Vous auriez presque pu deviner mon but quand j'ai �voqu� pack200 qui
>>>> est
>>>> une obscure facon de compresser un jar avant de le passer � la
>>>> moulinette

>>>> de Gzip, les gains sont cons�quents (/4).
>>> Je suis *tr�s* �tonn� qu'on puisse compresser un jar d'un facteur 4. Un

>>> jar est *d�j�* compress�, j'ai du mal � imaginer qu'on puisse gagner

>>> pkus que quelques % en le recompressant... Ou alors, il s'agit de qqhose

>>> de tout � fait diff�rent (style, nettoyage des classes et des jars avant
>>> recompression).

>> Pack200 �a date du JRE 1.5 pour le support dans JWS, le seul truc
>> c'est que �a n'est pas support� en natif dans le JRE au niveau du

>> classloader, d'o� le fait que �a soit peu r�pandu (et que les gens ne
>> s'int�ressent plus aux tailles des jars non plus ;-P ). L'avantage du

>> pack200 c'est qu'il travaille en connaissant le bytecode et pas sur un

>> paquet opaque d'octets, d'o� l'efficacit�. La doc de l'�poque

>> l'explique pas mal :
>> http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html#pack200_compression
>>

> Int�ressant...
>
> Et les jars pack200t�s restent compatibles ?
Hmmm : http://jcp.org/en/jsr/detail?id=200

Pas de mise � jour depuis 2004. D'un autre c�t�, pour le format des
.class, �a se d�finit ici : http://www.jcp.org/en/jsr/detail?id=202 ,
pas de modification depuis 2006.

A priori, pour l'instant on est pas mal niveau compatibilit�.

Damien B

[Sebastien Bordes]

Je viens de faire le test en condition reelle

mon.jar => maven-webstart-plugin => mon.jar.pack.gz

mon.pack.gz => 7z => mon.jar.pack

mon.jar.pack => unpack200 => monbis.jar

J'ai comparé avec jd-gui mon.jar et monbis.jar et ils ont l'air identique en tout cas les numeros de lignes sont bons et le contenu compréhensible (même les classes internes)

[Emmanuel Lécharny]

Le 12/5/12 3:34 PM, Sebastien Bordes a écrit :

> Je viens de faire le test en condition reelle
>
> mon.jar => maven-webstart-plugin => mon.jar.pack.gz
>
> mon.pack.gz => 7z => mon.jar.pack
>
> mon.jar.pack => unpack200 => monbis.jar
>
> J'ai comparé avec jd-gui mon.jar et monbis.jar et ils ont l'air identique
> en tout cas les numeros de lignes sont bons et le contenu compréhensible
> (même les classes internes)

D'après la doc de pack200, tu as une option si tu veux supprimer les
numéros de ligne.

En prod, les numéros de ligne sont peu utiles (et pour ceux qui loggent
en demandant à log4j de rajouter les numéros de ligne, qu'ils sachent
que c'est plus que coûteux : grosso modo, log4j génère un stack trace et
récupère le nom de méthode et le numéro de ligne en parsant le stack
trace...), et ce pour chaque ligne loggé !

[Patrice Trognon]

du moment que c'est capable d'envoyer dans un syslog unix ça me convient.

pat

Le 4 déc. 2012 à 15:26, Emmanuel Lécharny <elec...@gmail.com> a écrit :

> Salut !
>
> ça fait longtemps, mais je pense que passé septembre, tout le monde est
> en pleine brasse coulée...
>
> On discutait récemment des loggers, un serpent de mer(de) qui revient
> souvent dans les conversations. Log4j, JUL, JULI, slf4j, logback,
> log4j2, clog, tinylog, on a un chiée de loggers existants et plus
> personne ne sait ou donner de la tête, c'est style pire que les nouveaux
> langages qui fleurissent tous les jours. Sans compter les ceusses qui ne
> jurent que par System.out( "ta gueule, log4j !" );
>
> Vous utilisez quoi, et pourquoi ?
>

> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Patrice Trognon]

oui appender syslog dans log4j et c'est réglé.
très bonne idée car ta config log4j est hyper basique, juste ton appender syslog a coller, et ensuite les règles de traitement
des logs (rotation, dispatch sur différents serveurs de log, etc) tout va se faire dans syslog, et ça comme je disais
les admin ils maitrisent.

Ensuite en terme de sécu c'est le mieux, tu as un serveur syslog qui ne va faire que ça, rien d'autre ouvert dessus,
donc vraiment très peu de risque qu'en cas de piratage le mec puisse effacer les logs.

Pat


>
> (*Fausse Bonne Idée)

[Patrice Trognon]

comme je disais dans une réponse précédente syslog est ton ami.

De ma petite expérience dans le développement de daemon principalement, que ceux ci
soient réalisés en java ou n'importe quel autre langage (Perl, C++, …) a un moment
donné ils vont se retrouver sur un serveur qui sera géré par un adminsys.

Un admin sait parfaitement jouer avec un syslog et lui faire faire ce qu'il veut (consolidation
des logs des n serveurs de prod sur un serveur de log, que sais je).

Bref ce qu'il va vouloir c'est que la "saloperie de boite noire" (c'est un peu comme ça qu'ils voient
un daemon dev en java :( ) soit capable de cracher ses logs dans son syslog.

Si tu lui colle un appender en fichier il hurle, en base de données il te prend pour un martien.

C'est pour cela que je n'ai jamais utilisé le log du JDK car un syslog étant osdependant ils ne l'ont pas intégré
(enfin perso j'en suis resté a java 5, apres je ne sais pas …) et le seul que j'ai trouvé à l'époque qui
faisait un append correct en syslog c'était Log4J.

Pat

Le 5 déc. 2012 à 09:52, Remi Forax <fo...@univ-mlv.fr> a écrit :

> On 12/05/2012 08:42 AM, Julien Ponge wrote:
>> Très juste. Après tu peux aussi désactiver le thread de log :http://www.tinylog.org/user-manual
>
> oui, mais activer la thread de log par défaut pour pouvoir dire mon framework est plus rapide que les votres alors qu'en prod il faut le désactiver me semble limite intelectuellement parlant.
>
> Rémi
>
>>
>> On Wednesday, December 5, 2012, Remi Forax wrote:
>>
>> On 12/04/2012 10:38 PM, Julien Ponge wrote:
>>

>> C'est marrant que tu sois concerné par la taille des jars
>> comme

>> critère de choix.
>>
>> À propos de logging en avec un jar de taille réduite et sans
>> dépendances je recommande TinyLog http://www.tinylog.org
>>
>> Pas de fichier XML étrange, une API sans fioritures, une
>> configuration
>> flexible. Parfait, surtout quand il ne faut pas s'intégrer
>> avec des
>> loggers de meta-loggers de loggers par dessus les loggers.
>>
>> - Julien
>>
>>
>> tinylog démarre une thread en tache de fond qui fait les
>> écritures, c'est rapide mais quand la VM crash tu as perdu les
>> derniers logs, ceux qui sont intéressant. donc c'est vraiment
>> moyen en production, enfin peut-être que je suis le seul à faire
>> crasher la VM assez régulièrement*
>>
>> Rémi
>> *ok, ok, souvent c'est de ma faute.
>>

[Emmanuel Lécharny]

Le 12/5/12 12:52 PM, Damien B a écrit :

> Le 05/12/2012 12:20, Emmanuel Lécharny a écrit :
>> Le 12/5/12 12:07 PM, Damien B a écrit :
>>> Le 05/12/2012 11:50, Emmanuel Lécharny a écrit :

>>>> Le problème n'est pas la taille des jars embarqués... Le pb, c'est que
>>>> vous diffusez un package à trop d'endroit, sur un réseau trop serré.

>>>>
>>>> C'est comme acheter de plus grandes bassines parce que tu as une fuite
>>>> chez toi...

>>> Ben justement : je ne suis pas chez moi :-) Après on peut toujours

>>> discuter de la nécessité d'avoir le package à "trop" d'endroits (et
>>> tous les liens ne sont pas serrés, mais il y a des goulots c'est sûr),
>>> toujours est-il que dans une approche d'amélioration continue, c'est
>>> bien que chacun y mette du sien et enlève le gras, c'est aussi ça
>>> l'approche lean :-)
>> En modifiant ta livraison pour "résoudre" les pb réseau, tu modifies le
>> comportement de ton appli
> Je ne modifie pas ma livraison pour résoudre les problèmes réseau : je
> construis (même si le plus souvent c'est de la reprise et pas de la
> construction) une application qui dépend d'un socle, et plutôt que de

> dire "ouais, encore un truc de niaiseux, je vais tout embarquer au cas

> où", je dis "profitons-en, et en plus ça réduit la taille du livrable,
> tout bénef".
Si ton socle contiens déjà un logger, pas de problème. Cela dit, tu peux
avoir quand même besoin d'une facade (slf4j), et c'est dommage de pas
l'embarquer.
>
>> : maintenant, elle dépend de packages fournis
>> par ton serveur d'application, au lieu d'être standalone.

> Il faut tracer une ligne quelque part : quel besoin d'embarquer JTA,

> Mail, JAX-WS, etc.. exactement ? "Standalone" ça n'est pas un absolu,
> tu dépends toujours d'une version minimale du JRE (et ce n'est pas
> quelque chose de mineur en terme de complexité), et dans le cas
> présent, d'un serveur d'application avec un certain niveau de
> compatibilité avec une version spécifique de JavaEE (ce qui est loin
> d'être mineur aussi). Et puis pourquoi éviter cette dépendance quand,
> dans ce contexte toujours, c'est un entrant du système et pas une
> variable ?

C'est une bonne question : que doit embarquer ton EAR? Cela dit,
normalement, la réponse c'est : tout ce dont tu as besoin...

>
>> C'est quand même la garantie de pb potentiels le jour où tu bascules

>> vers une
>> nouvelle version/ un autre serveur.

> Dans ce cas-là on embarque le serveur d'application, et la JVM aussi
> au passage ? Ha non on ne peut pas, ça met une dépendance sur l'OS. Et

> la bascule vers une nouvelle version / un autre serveur, dans ce

> contexte, c'est un chantier autrement plus important que résoudre les
> problèmes de descripteur de déploiement spécifiques ou de montée de
> version des dépendances ou comportement "exotiques" des classloaders.

Le truc est que si tu dépends d'un composants de ton serveur
d'application, alors tu dépends de ton serveur d'application. Ce n'est
pas une bonne idée...
>
>> Contourner un pb n'est pas le résoudre...
> Pour ça il faudrait commencer par énoncer le problème :-D Je
> commentais par rapport à une interrogation générique par rapport à la
> taille des jars, et c'est toi qui réduit ça à une problématique de
> lien réseau :-)
Parce que clairement, quand tu poses le pb de distribuer un jar de 500
Ko en terme de consommation de bande passante, c'est une problématique
réseau, non pas de taille de jar.

[Jean Paliès]

Il y a graylog2 aussi, avec les appenders gelf pour log4j, logback...

2012/12/5 Emmanuel Lécharny <elec...@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Jean Paliès

[Damien B]

Le 05/12/2012 13:21, Emmanuel L�charny a �crit :
> Le 12/5/12 12:52 PM, Damien B a �crit :

>> Le 05/12/2012 12:20, Emmanuel L�charny a �crit :
>>> Le 12/5/12 12:07 PM, Damien B a �crit :
>>>> Le 05/12/2012 11:50, Emmanuel L�charny a �crit :
>>>>> Le probl�me n'est pas la taille des jars embarqu�s... Le pb, c'est que
>>>>> vous diffusez un package � trop d'endroit, sur un r�seau trop serr�.
>>>>>

>>>>> C'est comme acheter de plus grandes bassines parce que tu as une fuite
>>>>> chez toi...

>>>> Ben justement : je ne suis pas chez moi :-) Apr�s on peut toujours

>>>> discuter de la n�cessit� d'avoir le package � "trop" d'endroits (et
>>>> tous les liens ne sont pas serr�s, mais il y a des goulots c'est s�r),
>>>> toujours est-il que dans une approche d'am�lioration continue, c'est
>>>> bien que chacun y mette du sien et enl�ve le gras, c'est aussi �a
>>>> l'approche lean :-)
>>> En modifiant ta livraison pour "r�soudre" les pb r�seau, tu modifies le
>>> comportement de ton appli

>> Je ne modifie pas ma livraison pour r�soudre les probl�mes r�seau : je
>> construis (m�me si le plus souvent c'est de la reprise et pas de la

>> construction) une application qui d�pend d'un socle, et plut�t que de

>> dire "ouais, encore un truc de niaiseux, je vais tout embarquer au cas

>> o�", je dis "profitons-en, et en plus �a r�duit la taille du livrable,
>> tout b�nef".
> Si ton socle contiens d�j� un logger, pas de probl�me. Cela dit, tu peux
> avoir quand m�me besoin d'une facade (slf4j), et c'est dommage de pas
> l'embarquer.




>
>>
>>> : maintenant, elle d�pend de packages fournis
>>> par ton serveur d'application, au lieu d'�tre standalone.

>> Il faut tracer une ligne quelque part : quel besoin d'embarquer JTA,

>> Mail, JAX-WS, etc.. exactement ? "Standalone" �a n'est pas un absolu,
>> tu d�pends toujours d'une version minimale du JRE (et ce n'est pas
>> quelque chose de mineur en terme de complexit�), et dans le cas
>> pr�sent, d'un serveur d'application avec un certain niveau de

>> compatibilit� avec une version sp�cifique de JavaEE (ce qui est loin
>> d'�tre mineur aussi). Et puis pourquoi �viter cette d�pendance quand,
>> dans ce contexte toujours, c'est un entrant du syst�me et pas une

>> variable ?
> C'est une bonne question : que doit embarquer ton EAR? Cela dit,

> normalement, la r�ponse c'est : tout ce dont tu as besoin...
Et ce dont j'ai besoin, c'est ce que mon socle ne fournit pas : on
tourne en rond.


>>
>>> C'est quand m�me la garantie de pb potentiels le jour o� tu bascules

>>> vers une
>>> nouvelle version/ un autre serveur.

>> Dans ce cas-l� on embarque le serveur d'application, et la JVM aussi

>> au passage ? Ha non on ne peut pas, �a met une d�pendance sur l'OS. Et

>> la bascule vers une nouvelle version / un autre serveur, dans ce

>> contexte, c'est un chantier autrement plus important que r�soudre les
>> probl�mes de descripteur de d�ploiement sp�cifiques ou de mont�e de

>> version des d�pendances ou comportement "exotiques" des classloaders.
> Le truc est que si tu d�pends d'un composants de ton serveur
> d'application, alors tu d�pends de ton serveur d'application. Ce n'est
> pas une bonne id�e...
C'est compl�tement contextuel. Je travaillais r�cemment (dans un autre
contexte) sur des applis avec du JAX-RPC : que la pile soit fournie par
le serveur d'appli ou embarqu�, c'est le m�me combat => � poubelliser.
Toujours dans ce contexte, il y a utilisation de JATMI pour r�aliser les
appels Tuxedo, qui est livr� en tant que connecteur JCA, propri�taire,
pr�install� sur le serveur : tu vas refaire toute l'int�gration pour
embarquer �a ou un �quivalent dans ton EAR, parce que "c'est une
d�pendance vers un composant du serveur d'application" ? Gratuitement
(vu que ce qui est int�gr� au serveur d'appli et pay�, ainsi que son
support, et que si tu mets en place une solution alternative il faut
pr�voir les co�ts suppl�mentaires associ�s � l'exploitation �videmment)
ou alors en justifiant un ROI sur une projection de co�t de changement
diff�rentiel du serveur d'exploitation (diff�rentiel parce que m�me en
embarquant tes d�pendances tu auras des probl�matiques de migration, cf.
JAX-RPC) ?

>>> Contourner un pb n'est pas le r�soudre...
>> Pour �a il faudrait commencer par �noncer le probl�me :-D Je
>> commentais par rapport � une interrogation g�n�rique par rapport � la
>> taille des jars, et c'est toi qui r�duit �a � une probl�matique de

>> lien r�seau :-)

> Parce que clairement, quand tu poses le pb de distribuer un jar de 500

> Ko en terme de consommation de bande passante, c'est une probl�matique
> r�seau, non pas de taille de jar.
>
Mon exemple de d�part c'�tait 20Mo d'�cart, pourquoi tu r�duis toujours
:-) (et je ne parle pas de certains livrables � 200Mo dont 20Mo utiles,
parce que la configuration est embarqu�e dans l'EAR et que tous les
environnements sont dans le m�me livrable... c'est un autre sujet).

[Nicolas Delsaux]

2012/12/5 Damien B <night...@gmail.com>:

>
> Et ce dont j'ai besoin, c'est ce que mon socle ne fournit pas : on tourne en
> rond.
>
>>

> Mon exemple de départ c'était 20Mo d'écart, pourquoi tu réduis toujours :-)
> (et je ne parle pas de certains livrables à 200Mo dont 20Mo utiles, parce
> que la configuration est embarquée dans l'EAR et que tous les environnements
> sont dans le même livrable... c'est un autre sujet).
>
C'est marrant, parce que quand j'ai lu ton histoire d'EAR copié dans
un paquet d'environements apparement différents, je me suis dit que tu
(un tu générique, hein, pas toi) avait peut-être mal analysé la
granularité de l'application. Ou, plus exactement, tu utilisais une
granularité très macroscopique (je livre tout d'un coup) quand tu
aurais peut-être préféré une granularité beaucoup plus fine (je livre
l'appli web, le back-end, le client java web start) qui, du coup,
t'aurait évité d'avoir des gros paquets à trimballer.
Dans le même ordre d'idée, j'ai bien envie de te dire que tu pourrais
utiliser maven comme outil de packaging opérationnel : chaque serveur
a son propre repository local, synchronisé grâce à maven vers un
repository d'entreprise et, quand tu installe ton application dans ton
environement, tu lance localement un mvn install qui crée le package
final selon des règles bien précises, qui garantissent que tes
téléchargements seront minimaux.
Sinon tu peux aussi remplacer le téléchargement http par du
téléchargement bittorrent ... un admin intelligent devrait comprendre
que, parfois, le torrent, c'est bien (tiens, regardez comment les
éditeurs de jeux - Blizzard en tête - font pour distribuer leurs
packages de plusieurs Go à des masses de joueurs).

--
Nicolas Delsaux

[ehsavoie]

Tiens ca ressemble à notre manière de déployer Silverpeas ;)
mvn clean install.
Bon entre temps on a fait aussi un rpm et un deb parce que faut pas déconner les admins ca ca leur parle.
Reste plus qu'à exploser notre rpm/deb en plusieurs pour ne pas tout tirer (serveur d'application notamment) et pour sélectionner la SGBD et son driver.
D'ailleurs s'il y a des volontaires/contributeurs ...
PS : comme indiqué slf4j c'est bien pour logger pas pour configurer à 'chaud' et ça c'est vraiment pénible.

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/12/5 Nicolas Delsaux <nicolas...@gmail.com>

[Emmanuel Lécharny]

Le 12/6/12 8:36 AM, ehsavoie a écrit :

> D'ailleurs s'il y a des volontaires/contributeurs ...
> PS : comme indiqué slf4j c'est bien pour logger pas pour configurer à
> 'chaud' et ça c'est vraiment pénible.

Le problème, c'est qu'il s'agit d'une facade qui fonctionne avec tous
les loggers, en prenant en compte le plus petite dénominateur. La
configuration à chaud ne fait pas partie de l'API.

Cela dit, un logger comme log4j dispose d'un mécanisme de rechargement
dynamique ( |configureAndWatch)|, configurable. Ok, c'est une solution
du pauvre, mais ça fonctionne...

[Marc Pasteur]

bonjour,

jmx permet de répondre a un certains nombre de besoin pour une config a chaud (mais pas tous hein pas taper !).

Ca marche bien sur log4j/logback/(...autre peut etre)

Sinon si la config le permet un petit DynamicThresholdFilter a la logback qui permet de configurer un niveau log à la volée selon une valeur dans le MDC ce n'est vraiment pas mal !

Le 6 décembre 2012 08:53, Emmanuel Lécharny <elec...@gmail.com> a écrit :

[...]

Cela dit, un logger comme log4j dispose d'un mécanisme de rechargement
dynamique ( |configureAndWatch)|, configurable. Ok, c'est une solution
du pauvre, mais ça fonctionne...

[...]

[Nicolas Labrot]

2012/12/6 Emmanuel Lécharny <elec...@gmail.com>

Et elle n'a pas à faire partie de l'API. Slf4j créé une facade sur la partie logging, pas sur la configuration. Pour configurer c'est derrière la façade.


 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ehsavoie]

Sauf que changer les niveaux des logger au runtime c'est pas forcément stupide de pouvoir le faire ni en dehors de la façade.
En gros j'ai une façade pour tracer mais je fais des appels directs à mon implémentation pour configurer : bref slf4j perd de son intérêt car je me retrouve toujours avec une dépendance directe dans mon code sur l'implémentation.
Et je ne trouve pas ce usecase à la marge de l'utilisation d'un logger.

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/12/6 Nicolas Labrot <nit...@gmail.com>

[Emmanuel Lécharny]

Le 12/6/12 9:40 AM, Nicolas Labrot a écrit :

> 2012/12/6 Emmanuel Lécharny <elec...@gmail.com>
>
>> Le 12/6/12 8:36 AM, ehsavoie a écrit :
>>> D'ailleurs s'il y a des volontaires/contributeurs ...
>>> PS : comme indiqué slf4j c'est bien pour logger pas pour configurer à
>>> 'chaud' et ça c'est vraiment pénible.
>> Le problème, c'est qu'il s'agit d'une facade qui fonctionne avec tous
>> les loggers, en prenant en compte le plus petite dénominateur. La
>> configuration à chaud ne fait pas partie de l'API.
>>
>> Cela dit, un logger comme log4j dispose d'un mécanisme de rechargement
>> dynamique ( |configureAndWatch)|, configurable. Ok, c'est une solution
>> du pauvre, mais ça fonctionne...
>>
>
> Et elle n'a pas à faire partie de l'API. Slf4j créé une facade sur la
> partie logging, pas sur la configuration. Pour configurer c'est derrière la
> façade.

Non, tu confonds. Si toutes les implémentations exposait un moyend e les
configurer, la facade offirait ce service. ce n'est pas le cas.

Le problème, c'est qu'on voudrait pouvoir configurer les logs sans
connaître l'implem, et que justement, ce n'est pas possible...

[Damien B]

Le 05/12/2012 18:06, Nicolas Delsaux a �crit :

> 2012/12/5 Damien B <night...@gmail.com>:
>> Et ce dont j'ai besoin, c'est ce que mon socle ne fournit pas : on tourne en
>> rond.
>>

>> Mon exemple de d�part c'�tait 20Mo d'�cart, pourquoi tu r�duis toujours :-)
>> (et je ne parle pas de certains livrables � 200Mo dont 20Mo utiles, parce
>> que la configuration est embarqu�e dans l'EAR et que tous les environnements
>> sont dans le m�me livrable... c'est un autre sujet).
>>
> C'est marrant, parce que quand j'ai lu ton histoire d'EAR copi� dans
> un paquet d'environements apparement diff�rents, je me suis dit que tu
> (un tu g�n�rique, hein, pas toi) avait peut-�tre mal analys� la
> granularit� de l'application.

Dans ce cas pr�cis, on ne parle pas de l'application, mais plut�t du
client derri�re et de son chantier d'industrialisation / rationalisation
des dizaines (centaines ?) d'applications qui sont d�ploy�es :-)

> Ou, plus exactement, tu utilisais une

> granularit� tr�s macroscopique (je livre tout d'un coup) quand tu
> aurais peut-�tre pr�f�r� une granularit� beaucoup plus fine (je livre

> l'appli web, le back-end, le client java web start) qui, du coup,

> t'aurait �vit� d'avoir des gros paquets � trimballer.
L� c'est plut�t une d�cision prise dans les limbes de l'histoire selon
le mantra "j'ai la flemme d'externaliser le param�trage de mon appli
Spring, du coup le manuel d'installation serait trop long � �crire, du
coup je r�cup�re toutes les configurations possibles (#fail) et je
construit toutes les possibilit�s, et comme je n'ai pas la main sur
quand l'appli va �tre d�ploy�e au niveau suivant, je livre tout d'un coup".

> Dans le m�me ordre d'id�e, j'ai bien envie de te dire que tu pourrais
> utiliser maven comme outil de packaging op�rationnel : chaque serveur
> a son propre repository local, synchronis� gr�ce � maven vers un

> repository d'entreprise et, quand tu installe ton application dans ton

> environement, tu lance localement un mvn install qui cr�e le package
> final selon des r�gles bien pr�cises, qui garantissent que tes
> t�l�chargements seront minimaux.
Pourquoi sortir le marteau-pilon Maven ? Dans ce contexte client
toujours, y'a d'autres solutions plus l�g�res au niveau exploitation
(parce que plus int�gr�es avec le serveur d'exploitation).
Quant � lancer un mvn install qui lance le build en local, �a ne cadre
de toute fa�on pas avec les isolations r�seau en place :-)


> Sinon tu peux aussi remplacer le t�l�chargement http par du
> t�l�chargement bittorrent ... un admin intelligent devrait comprendre

> que, parfois, le torrent, c'est bien

Le bittorrent ou autre protocole peer-to-peer (pourquoi pas du GNUtella
hein ?), c'est bien quand ta capacit� d'upload est tr�s limit�e par
rapport � la demande en download, et tu vas augmenter cette capacit� par
une aggr�gation de petits uploads distribu�. L� le tuyau de toute fa�on
il ne va pas bouger, que tu mettes 200 serveurs derri�re ou 1 seul :-)

Ce qui est bien dans tout �a c'est qu'on est parti de la notion de faire
attention aux d�pendances qu'on utilise, et on abouti � "pfff, on s'en
tape d'avoir des d�pendances propres et ma�tris�es, par contre mettre �
place des usines � gaz pour contourner les �ventuels probl�mes ponctuels
que �a peut causer, nous on aime" :-)

Damien B

[Nicolas Delsaux]

2012/12/6 Damien B <night...@gmail.com>:
>
> Dans ce cas précis, on ne parle pas de l'application, mais plutôt du client
> derrière et de son chantier d'industrialisation / rationalisation des
> dizaines (centaines ?) d'applications qui sont déployées :-)
>
Bref, le client a fait n'importe quoi, et toi tu bats "tout seul"
contre son architecture ?
>
> Là c'est plutôt une décision prise dans les limbes de l'histoire selon le
> mantra "j'ai la flemme d'externaliser le paramétrage de mon appli Spring, du
> coup le manuel d'installation serait trop long à écrire, du coup je récupère

> toutes les configurations possibles (#fail) et je construit toutes les

> possibilités, et comme je n'ai pas la main sur quand l'appli va être
> déployée au niveau suivant, je livre tout d'un coup".
>
T'es pas en train de me dire que tu utilise des techniques techniques
de sioux parce que l'architecture globale de ton application est pas
terrible ?
>
>> Dans le même ordre d'idée, j'ai bien envie de te dire que tu pourrais
>> utiliser maven comme outil de packaging opérationnel : chaque serveur
>> a son propre repository local, synchronisé grâce à maven vers un

>> repository d'entreprise et, quand tu installe ton application dans ton

>> environement, tu lance localement un mvn install qui crée le package
>> final selon des règles bien précises, qui garantissent que tes

>> téléchargements seront minimaux.

>
> Pourquoi sortir le marteau-pilon Maven ? Dans ce contexte client toujours,

> y'a d'autres solutions plus légères au niveau exploitation (parce que plus
> intégrées avec le serveur d'exploitation).

Comme par exemple ? Parce que je donnais maven comme exemple de ce
qu'une équipe de dev maîtrise. Si tes ops ne connaissent pas, ça va
moins bien. Par contre, effectivement, si quand ils font leur apt-get
install ca récupère le bon paquet de dépendances depuis un repository
quelconque ... eux seront contents parce que ça leur correspondra, et
tu seras content parce que tu n'enverras par la poste que les jars
modifiés, et leur application s'installera bien.

>
>> Sinon tu peux aussi remplacer le téléchargement http par du

>> téléchargement bittorrent ... un admin intelligent devrait comprendre

>> que, parfois, le torrent, c'est bien
>
> Le bittorrent ou autre protocole peer-to-peer (pourquoi pas du GNUtella hein

> ?), c'est bien quand ta capacité d'upload est très limitée par rapport à la
> demande en download, et tu vas augmenter cette capacité par une aggrégation
> de petits uploads distribué. Là le tuyau de toute façon il ne va pas bouger,
> que tu mettes 200 serveurs derrière ou 1 seul :-)

Sauf que les 200 serveurs, avec bittorrent, vont télécharger des
morceaux et se les partager, du coup le téléchargement global durera
netement moins longtemps que tous ces téléchargements parallèles. Et
rien que sur 200 clients, tu sentiras une différence.
>
> Ce qui est bien dans tout ça c'est qu'on est parti de la notion de faire
> attention aux dépendances qu'on utilise, et on abouti à "pfff, on s'en tape
> d'avoir des dépendances propres et maîtrisées, par contre mettre à place des
> usines à gaz pour contourner les éventuels problèmes ponctuels que ça peut

> causer, nous on aime" :-)

J'ai pas vraiment dit ça.
J'ai juste constaté que, apparement, l'architecture ne risque pas
d'évoluer. En revanche, le problème de lien DevOps demeure quelquesoit
la taille du livrable. Du coup cette approche de téléchargement mieux
distribué est valide, que ce soit pour un jar unique de 50 Ko ou un
méga-EAR de 50 Mo.


--
Nicolas Delsaux

[Damien B]

Le 06/12/2012 12:31, Nicolas Delsaux a �crit :
> 2012/12/6 Damien B <night...@gmail.com>:

>> Dans ce cas pr�cis, on ne parle pas de l'application, mais plut�t du client

>> derri�re et de son chantier d'industrialisation / rationalisation des
>> dizaines (centaines ?) d'applications qui sont d�ploy�es :-)

>>
> Bref, le client a fait n'importe quoi, et toi tu bats "tout seul"
> contre son architecture ?

Je ne me bats pas contre : je m'adapte aux contraintes ! C'est vous qui
�tes dans cette logique de lutte :-)

>> L� c'est plut�t une d�cision prise dans les limbes de l'histoire selon le
>> mantra "j'ai la flemme d'externaliser le param�trage de mon appli Spring, du
>> coup le manuel d'installation serait trop long � �crire, du coup je r�cup�re

>> toutes les configurations possibles (#fail) et je construit toutes les

>> possibilit�s, et comme je n'ai pas la main sur quand l'appli va �tre
>> d�ploy�e au niveau suivant, je livre tout d'un coup".

>>
> T'es pas en train de me dire que tu utilise des techniques techniques
> de sioux parce que l'architecture globale de ton application est pas
> terrible ?

?
Je d�cris un �tat initial, pour une appli qu'on reprend en maintenance.
Apr�s il y a plusieurs �ch�ances, et la plus urgente c'est de rendre
l'application proprement configurable pour faire sauter cette pratique.
Apr�s il faut voir les impacts sur la cha�ne aval, vu que �a implique
une redistribution des responsabilit�s. Je ne vois pas o� est "ma
technique de sioux".



>>> Dans le m�me ordre d'id�e, j'ai bien envie de te dire que tu pourrais
>>> utiliser maven comme outil de packaging op�rationnel : chaque serveur
>>> a son propre repository local, synchronis� gr�ce � maven vers un

>>> repository d'entreprise et, quand tu installe ton application dans ton

>>> environement, tu lance localement un mvn install qui cr�e le package
>>> final selon des r�gles bien pr�cises, qui garantissent que tes

>>> t�l�chargements seront minimaux.

>> Pourquoi sortir le marteau-pilon Maven ? Dans ce contexte client toujours,

>> y'a d'autres solutions plus l�g�res au niveau exploitation (parce que plus
>> int�gr�es avec le serveur d'exploitation).
> Comme par exemple ?
Par exemple il y a un repo RPM d'entreprise en place, mais qui n'est
pour l'instant ouvert que pour l'exploit' syst�me et pas pour l'exploit'
applicative : c'est une premi�re solution. Le serveur d'appli c'est du
JBoss, et ils ont les souscriptions JON, c'est une deuxi�me solution.
Les responsables du socle ont aussi leur roadmap interne... qui quand
elle aboutira deviendra la r�f�rence � utiliser.

> Parce que je donnais maven comme exemple de ce

> qu'une �quipe de dev ma�trise. Si tes ops ne connaissent pas, �a va

> moins bien. Par contre, effectivement, si quand ils font leur apt-get

> install ca r�cup�re le bon paquet de d�pendances depuis un repository
> quelconque ... eux seront contents parce que �a leur correspondra, et

> tu seras content parce que tu n'enverras par la poste que les jars

> modifi�s, et leur application s'installera bien.
Houl�, tu veux leur mettre du Debian ou de l'Ubuntu en plus ? :-)

>>> Sinon tu peux aussi remplacer le t�l�chargement http par du

>>> t�l�chargement bittorrent ... un admin intelligent devrait comprendre

>>> que, parfois, le torrent, c'est bien
>> Le bittorrent ou autre protocole peer-to-peer (pourquoi pas du GNUtella hein

>> ?), c'est bien quand ta capacit� d'upload est tr�s limit�e par rapport � la
>> demande en download, et tu vas augmenter cette capacit� par une aggr�gation

>> de petits uploads distribu�. L� le tuyau de toute fa�on il ne va pas bouger,
>> que tu mettes 200 serveurs derri�re ou 1 seul :-)
> Sauf que les 200 serveurs, avec bittorrent, vont t�l�charger des
> morceaux et se les partager, du coup le t�l�chargement global durera
> netement moins longtemps que tous ces t�l�chargements parall�les. Et
> rien que sur 200 clients, tu sentiras une diff�rence.
Nope : le seul goulot � l'heure actuelle c'est la VPN et la QOS qui est
dessus, �a ne changera rien. Le reste c'est du confort.

>> Ce qui est bien dans tout �a c'est qu'on est parti de la notion de faire
>> attention aux d�pendances qu'on utilise, et on abouti � "pfff, on s'en tape
>> d'avoir des d�pendances propres et ma�tris�es, par contre mettre � place des

>> usines � gaz pour contourner les �ventuels probl�mes ponctuels que �a peut

>> causer, nous on aime" :-)

> J'ai pas vraiment dit �a.
Tu te focalises depuis le d�but sur "le jar de 500ko" en disant "je vais
te montrer que ton probl�me est ailleurs" :-)


> J'ai juste constat� que, apparement, l'architecture ne risque pas
> d'�voluer. En revanche, le probl�me de lien DevOps demeure quelquesoit
> la taille du livrable.
Ca c'est s�r, mais de toute fa�on on n'a pas de lien entre la d�v et les
ops et on n'en aura pas, donc le probl�me est r�gl� :-)

[Nicolas Delsaux]

2012/12/6 Damien B <night...@gmail.com>:

> Le 06/12/2012 12:31, Nicolas Delsaux a écrit :
>
>
> Par exemple il y a un repo RPM d'entreprise en place, mais qui n'est pour

> l'instant ouvert que pour l'exploit' système et pas pour l'exploit'
> applicative : c'est une première solution. Le serveur d'appli c'est du
> JBoss, et ils ont les souscriptions JON, c'est une deuxième solution. Les

> responsables du socle ont aussi leur roadmap interne... qui quand elle

> aboutira deviendra la référence à utiliser.
>
Ah ouf !
>
>
> Houlà, tu veux leur mettre du Debian ou de l'Ubuntu en plus ? :-)
>
Je sentais bien que ça ferait sourire :-)
>
>>
>> Sauf que les 200 serveurs, avec bittorrent, vont télécharger des
>> morceaux et se les partager, du coup le téléchargement global durera
>> netement moins longtemps que tous ces téléchargements parallèles. Et
>> rien que sur 200 clients, tu sentiras une différence.
>
> Nope : le seul goulot à l'heure actuelle c'est la VPN et la QOS qui est
> dessus, ça ne changera rien. Le reste c'est du confort.
>
Le confort que tu cherche depuis le début (et pour lequel tu nous as
vendu pack2000 - qui est il est vrai une bonne idée) non ?
>
>>
>> J'ai pas vraiment dit ça.
>
> Tu te focalises depuis le début sur "le jar de 500ko" en disant "je vais te
> montrer que ton problème est ailleurs" :-)
>
C'est vrai (que ton problème est ailleurs :-)).

>
>
>> J'ai juste constaté que, apparement, l'architecture ne risque pas

>> d'évoluer. En revanche, le problème de lien DevOps demeure quelquesoit
>> la taille du livrable.
>
> Ca c'est sûr, mais de toute façon on n'a pas de lien entre la dév et les ops
> et on n'en aura pas, donc le problème est réglé :-)
>
Euh ... ok. Mais je me mords la joue pour ne pas dire qu'il y a
peut-être un rapport entre ce manque de lien et le fait que tu aie
soigné la taille de tes jars aux petits oignons :-)
Ca sent quand même la "tale from the big company trenches" tout ça :-)

--
Nicolas Delsaux

[Damien B]

Le 06/12/2012 13:41, Nicolas Delsaux a �crit :
> 2012/12/6 Damien B <night...@gmail.com>:
>> Le 06/12/2012 12:31, Nicolas Delsaux a �crit :

>>> Sauf que les 200 serveurs, avec bittorrent, vont t�l�charger des
>>> morceaux et se les partager, du coup le t�l�chargement global durera
>>> netement moins longtemps que tous ces t�l�chargements parall�les. Et
>>> rien que sur 200 clients, tu sentiras une diff�rence.

>> Nope : le seul goulot � l'heure actuelle c'est la VPN et la QOS qui est
>> dessus, �a ne changera rien. Le reste c'est du confort.
>>
> Le confort que tu cherche depuis le d�but (et pour lequel tu nous as
> vendu pack2000 - qui est il est vrai une bonne id�e) non ?
Pack200.
Ca apporte son lot de contraintes, parce que c'est juste un format de
transport. Mais � la base, mon confort intellectuel se situe dans le
fait que j'ai conscience que la cha�ne des d�pendances est ma�tris�e et
que ce n'est pas juste le r�sultat d'ajouts plus ou moins au petit
bonheur dans les ivy/pom. Le temps de transfert derri�re c'est une
r�sultante de ce confort, pas la source directe :-)
Et un jar non transf�r� parce que livr� sur le serveur d'appli, c'est un
jar qui co�tera toujours infiniment moins qu'un jar embarqu�, m�me pour
de bonnes raisons :-D (si on veut repartir sur les d�bits).

>>> J'ai juste constat� que, apparement, l'architecture ne risque pas

>>> d'�voluer. En revanche, le probl�me de lien DevOps demeure quelquesoit
>>> la taille du livrable.

>> Ca c'est s�r, mais de toute fa�on on n'a pas de lien entre la d�v et les ops

>> et on n'en aura pas, donc le probl�me est r�gl� :-)

>>
> Euh ... ok. Mais je me mords la joue pour ne pas dire qu'il y a

> peut-�tre un rapport entre ce manque de lien et le fait que tu aie
> soign� la taille de tes jars aux petits oignons :-)
Elle n'est pas "aux petits oignons", juste un peu surveill�e : les
indicateurs qualit�, c'est contextuel :-)


> Ca sent quand m�me la "tale from the big company trenches" tout �a :-)
Sans blague :-D

[Nicolas Delsaux]

2012/12/6 Damien B <night...@gmail.com>:

>
> Pack200.
> Ca apporte son lot de contraintes, parce que c'est juste un format de

> transport. Mais à la base, mon confort intellectuel se situe dans le fait
> que j'ai conscience que la chaîne des dépendances est maîtrisée et que ce
> n'est pas juste le résultat d'ajouts plus ou moins au petit bonheur dans les
> ivy/pom. Le temps de transfert derrière c'est une résultante de ce confort,

> pas la source directe :-)

J'en conviens sans problème, je suis un peu dans le même état d'esprit
: à surveiller soigneusement quelles sont les dépendances de mon
application pour éviter la gonflette.

> Et un jar non transféré parce que livré sur le serveur d'appli, c'est un jar
> qui coûtera toujours infiniment moins qu'un jar embarqué, même pour de
> bonnes raisons :-D (si on veut repartir sur les débits).
>
Ou même un jar non embarqué parce qu'en fait il ne sert que pendant la
phase de build.
>


--
Nicolas Delsaux

[Nicolas Labrot]

2012/12/6 Emmanuel Lécharny <elec...@gmail.com>

Le 12/6/12 9:40 AM, Nicolas Labrot a écrit :

> 2012/12/6 Emmanuel Lécharny <elec...@gmail.com>
>
>> Le 12/6/12 8:36 AM, ehsavoie a écrit :
>>> D'ailleurs s'il y a des volontaires/contributeurs ...
>>> PS : comme indiqué slf4j c'est bien pour logger pas pour configurer à
>>> 'chaud' et ça c'est vraiment pénible.
>> Le problème, c'est qu'il s'agit d'une facade qui fonctionne avec tous
>> les loggers, en prenant en compte le plus petite dénominateur. La
>> configuration à chaud ne fait pas partie de l'API.
>>
>> Cela dit, un logger comme log4j dispose d'un mécanisme de rechargement
>> dynamique ( |configureAndWatch)|, configurable. Ok, c'est une solution
>> du pauvre, mais ça fonctionne...
>>
>
> Et elle n'a pas à faire partie de l'API. Slf4j créé une facade sur la
> partie logging, pas sur la configuration. Pour configurer c'est derrière la
> façade.

Non, tu confonds. Si toutes les implémentations exposait un moyend e les
configurer, la facade offirait ce service. ce n'est pas le cas.

Les loggers sérieux exposent des méthodes de configuration que ce soit programmatiquement ou par fichier de conf. Es tu l'un des créateurs ou as tu un lien pour te permettre de dire que la "facade offrirait ce service"? :)

 

Le problème, c'est qu'on voudrait pouvoir configurer les logs sans
connaître l'implem, et que justement, ce n'est pas possible...

Je ne vois que peux l’intérêt d'abstraire la partie configuration autant du point de vu des concepteurs de slf4j que de mon point de vu utilisateur. Je ne change pas de logger tous les jours et même si je devais en changer, la complexité de configuration est pour 90% des usages nuls. 10% pour des d'appender, logger spécifique qu'une simple abstraction ne permettait pas de simplifier.

Utiliser sans connaitre l'impl, ce n'est plus une facade, c'est une API, et la, cf. le mail d'Antonio.

[Nicolas Labrot]

2012/12/6 ehsavoie <emmanuel...@gmail.com>

Sauf que changer les niveaux des logger au runtime c'est pas forcément stupide de pouvoir le faire ni en dehors de la façade.
En gros j'ai une façade pour tracer mais je fais des appels directs à mon implémentation pour configurer : bref slf4j perd de son intérêt car je me retrouve toujours avec une dépendance directe dans mon code sur l'implémentation.
Et je ne trouve pas ce usecase à la marge de l'utilisation d'un logger.

L'interet majeur de slf4j c'est la façade au niveau log car c'est LA problématique majeur qu'il adresse et que la majorité de ses utilisateurs rencontrent. Abstraire la partie conf, serait certes intéressantes, mais aurait un ratio benef/cout je pense discutable.

Et c'est grave d'avoir une dépendance directe dans ton code ? Le choix d'un logger, de ses appenders et de tout ce qu'il y a derrière n'est généralement pas anodin et te liera de toute facon à ce logger.


 

[Emmanuel Lécharny]

Le 12/6/12 2:16 PM, Nicolas Labrot a écrit :

> 2012/12/6 Emmanuel Lécharny <elec...@gmail.com>
>
>> Le 12/6/12 9:40 AM, Nicolas Labrot a écrit :
>>> 2012/12/6 Emmanuel Lécharny <elec...@gmail.com>
>>>
>>>> Le 12/6/12 8:36 AM, ehsavoie a écrit :
>>>>> D'ailleurs s'il y a des volontaires/contributeurs ...
>>>>> PS : comme indiqué slf4j c'est bien pour logger pas pour configurer à
>>>>> 'chaud' et ça c'est vraiment pénible.
>>>> Le problème, c'est qu'il s'agit d'une facade qui fonctionne avec tous
>>>> les loggers, en prenant en compte le plus petite dénominateur. La
>>>> configuration à chaud ne fait pas partie de l'API.
>>>>
>>>> Cela dit, un logger comme log4j dispose d'un mécanisme de rechargement
>>>> dynamique ( |configureAndWatch)|, configurable. Ok, c'est une solution
>>>> du pauvre, mais ça fonctionne...
>>>>
>>> Et elle n'a pas à faire partie de l'API. Slf4j créé une facade sur la
>>> partie logging, pas sur la configuration. Pour configurer c'est derrière
>> la
>>> façade.
>> Non, tu confonds. Si toutes les implémentations exposait un moyend e les
>> configurer, la facade offirait ce service. ce n'est pas le cas.
>>
>
> Les loggers sérieux exposent des méthodes de configuration que ce soit
> programmatiquement ou par fichier de conf. Es tu l'un des créateurs ou as
> tu un lien pour te permettre de dire que la "facade offrirait ce service"?
> :)

Il n'y a pas de raison objectif pour que la facade n'expose pas cette
facilité, si tous les loggers disposent de cette facilité. C'est un gros
problème de slf4j, qui délègue ce travail au logger.

Il y a des cas de figure où tu veux configurer le niveau de log, sans
savoir quel est l'implementation sous-jacente, et là, tu ne peux pas le
faire.

>
>
>
>> Le problème, c'est qu'on voudrait pouvoir configurer les logs sans
>> connaître l'implem, et que justement, ce n'est pas possible...
>>
>
> Je ne vois que peux l’intérêt d'abstraire la partie configuration autant du
> point de vu des concepteurs de slf4j que de mon point de vu utilisateur. Je
> ne change pas de logger tous les jours et même si je devais en changer, la
> complexité de configuration est pour 90% des usages nuls. 10% pour des
> d'appender, logger spécifique qu'une simple abstraction ne permettait pas
> de simplifier.

Tu ne développes pas de composants embeddable, c'est tout. J'ai un use
case très simple : je développe Apache Directory Server, qui est un
serveur LDAP embeddable. Je veux gérer le niveau de logs que je produis
à partir de la configuration du serveur. Si je n'ai pas accès au logger
(et comme c'est embeddé, c'est effectivement ce qui se passe), je ne
peux pas le faire.Il faut donc que l'utilisateur qui embedde le serveur
décide de modifier son niveau de log à partir d'un fichier de
configuration. Pas hyper pratique. En fait, super chiant.

[Emmanuel Lécharny]

Le 12/6/12 2:26 PM, Nicolas Labrot a écrit :

> 2012/12/6 ehsavoie <emmanuel...@gmail.com>
>
>> Sauf que changer les niveaux des logger au runtime c'est pas forcément
>> stupide de pouvoir le faire ni en dehors de la façade.
>> En gros j'ai une façade pour tracer mais je fais des appels directs à mon
>> implémentation pour configurer : bref slf4j perd de son intérêt car je me
>> retrouve toujours avec une dépendance directe dans mon code sur
>> l'implémentation.
>> Et je ne trouve pas ce usecase à la marge de l'utilisation d'un logger.
>>
>
> L'interet majeur de slf4j c'est la façade au niveau log car c'est LA
> problématique majeur qu'il adresse et que la majorité de ses utilisateurs
> rencontrent. Abstraire la partie conf, serait certes intéressantes, mais
> aurait un ratio benef/cout je pense discutable.

Que le benef soit faible, je n'en disconvient pas. Mais le coût, je ne
vois pas (à part pour l'implémenteur de SLF4j).

>
> Et c'est grave d'avoir une dépendance directe dans ton code ?

Oui, pour tout composant embeddable.

> Le choix d'un
> logger, de ses appenders et de tout ce qu'il y a derrière n'est
> généralement pas anodin et te liera de toute facon à ce logger.

Non. Justement, on ne veut pas être lié à un logger, quand on écrit des
composants embeddables.

[Nicolas Labrot]

Pourquoi un composant embeddable devrait pouvoir gérer le niveau de log qu'il produit ?

Quand j'utilise par exemple (attention les yeux, ca va piquer ;) ) Spring je ne m'attend pas à ce qu'il définisse son propre niveau. En tant qu'utilisateur cela ne me choque pas d'avoir à moduler le niveau attendu.

2012/12/6 Emmanuel Lécharny <elec...@gmail.com>

[ehsavoie]

Moi ce qui me surprend c'est que tu ne trouves pas normal de pouvoir moduler le niveau de log à chaud.
Pour moi c'est un cas usuel et si je dois le fiare selon mon implementation alors qu'apporte SL4J vu que je depends de mon implementation dans le code pourquoi me coltiner une API supplémentaire ?

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/12/6 Nicolas Labrot <nit...@gmail.com>

[Nicolas Labrot]

2012/12/6 ehsavoie <emmanuel...@gmail.com>

Moi ce qui me surprend c'est que tu ne trouves pas normal de pouvoir moduler le niveau de log à chaud.
Pour moi c'est un cas usuel et si je dois le fiare selon mon implementation alors qu'apporte SL4J vu que je depends de mon implementation dans le code pourquoi me coltiner une API supplémentaire ?

Je trouve normal de moduler le niveau à chaud. Slf4j apporte l'abstraction coté action de logger qui est la partie la plus invasive d'un système de loggeur.

D'ailleurs pour minimiser l'aspect invasif (enfin ca dépend des gouts), voir les annotations lombok @Slf4j, @Log4j et @Log

La partie conf se limitant dans la majorité des cas à un fichier XML (et Groovy pour logback) rechargeable à chaud.

 

[Emmanuel Lécharny]

Le 12/6/12 2:40 PM, Nicolas Labrot a écrit :

> Pourquoi un composant embeddable devrait pouvoir gérer le niveau de log
> qu'il produit ?

Simplement parce que cela correspond à un besoin : Si mon utilisateur,
qui ne connait rien à LDAP, veux de l'aide, je n'ai qu'à modifier le
niveau de log de mon serveur sans modifier son fichier de configuration,
et surtout sans arrêter son application, pour obtenir les logs que je
veux, temporairement.

Sinon, je suis obligé de tout arrêter... Pour de la prod, c'est juste
moyen moyen.

[Emmanuel Lécharny]

Le 12/6/12 2:55 PM, Nicolas Labrot a écrit :

> 2012/12/6 ehsavoie <emmanuel...@gmail.com>
>
>> Moi ce qui me surprend c'est que tu ne trouves pas normal de pouvoir
>> moduler le niveau de log à chaud.
>> Pour moi c'est un cas usuel et si je dois le fiare selon mon
>> implementation alors qu'apporte SL4J vu que je depends de mon
>> implementation dans le code pourquoi me coltiner une API supplémentaire ?
>>
> Je trouve normal de moduler le niveau à chaud. Slf4j apporte l'abstraction
> coté action de logger qui est la partie la plus invasive d'un système de
> loggeur.
>
> D'ailleurs pour minimiser l'aspect invasif (enfin ca dépend des gouts),
> voir les annotations lombok @Slf4j, @Log4j et @Log
>
> La partie conf se limitant dans la majorité des cas à un fichier XML (et
> Groovy pour logback) rechargeable à chaud.

En embedded, je ne maîtrise pas forcément le ficher de conf. Et perso,
je veux stocker ma config autrement que dans un fichier de conf : je
fais comment alors ?

[Nicolas Labrot]

C'est une question réthorique? ;)

2012/12/6 Emmanuel Lécharny <elec...@gmail.com>

[Emmanuel Lécharny]

Le 12/6/12 3:34 PM, Nicolas Labrot a écrit :

> C'est une question réthorique? ;)

C'est une question qui n'espère pas d'autre réponse que DTC, profond :/

Bref, je suis bien emmerdé, je ne peux pas faire ce que je veux avec
SLF4j, et je peux pas configurer les loggers que je ne maîtrise pas,
donc je n'ai pas de solution. C'est en ça que SLF4J est super limitant,
et je ne vois pas de lumière au bout du tunnel (qui de toutes façons est
généralement celle du train qui s'approche).
Le problème des logs, c'est que depuis que Sun a décidé d'intégrer sa
propre implémentation dans le JDK, cela a généré une chiée de facades,
ou d'implémentations, comme cet infâme CLOG (commons-logging), et
qu'aujourd'hui on est bridé par tous les trous. Sans compter ceux qui
pondent un nouveau LogInYourBack tous les ans...

A se demander si System.out.println n'est pas une bonne solution finalement.

Pour l'instant, chez moi, c'est log4j1.2 +slf4j, avec bascule vers
Log4j2 + slf4j prévu.

Ah, tiens, une super découverte aujourd'hui : je voulais logger avec un
contexte, et en log4j, il y avait NDC pour cela. Mais NDC en slf4j ? DTC
aussi... Ah, mais si, que je suis con, c'est dans le jar slf4j-ext
(premiere couche de vomi). J'essaye, ça marche pas (deuxième couche de
vomi. Bon, il reste MDC alors...

Non, MDC et NDC n'ont rien à voir avec DTC, pour ceux qui se posent la
question !

[Nicolas Labrot]

2012/12/6 Emmanuel Lécharny <elec...@gmail.com>

En embedded, je ne maîtrise pas forcément le ficher de conf. Et perso,
je veux stocker ma config autrement que dans un fichier de conf : je
fais comment alors ?

Qu'est ce que tu entends (techniquement) par cet "embed"?
 

[Emmanuel Lécharny]

Le 12/6/12 3:56 PM, Nicolas Labrot a écrit :

Une personne qui utilise mon projet à partir des jars qui sont dans
maven. Je ne maîtrise pas ce qu'il fait au niveau des loggers.

En pratique, ApacheDS est disponible sous deux formes :
- un executable, et tu disposes alors d'un serveur standalone
- ou des jars, que tu instancies dans ton code pour démarrer le serveur

L'exécutable, en fait, ne contient qu'une classe qui embedde le serveur...

[Nicolas Labrot]

2012/12/6 Emmanuel Lécharny <elec...@gmail.com>

Devant la somme d'inconnus vis à vis de l'usage que peut en faire un utilisateur qui souhaite l'embed, personnellement je me contenterais de rédiger dans la doc d'intégration un § sur les logs

Nominalement j'imagine qu'en mode embed, tu ne fournis pas de loggeur juste la facade?

 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Emmanuel Lécharny]

Le 12/6/12 4:28 PM, Nicolas Labrot a écrit :

> 2012/12/6 Emmanuel Lécharny <elec...@gmail.com>
>
>> Le 12/6/12 3:56 PM, Nicolas Labrot a écrit :
>>> 2012/12/6 Emmanuel Lécharny <elec...@gmail.com>
>>>
>>>> En embedded, je ne maîtrise pas forcément le ficher de conf. Et perso,
>>>> je veux stocker ma config autrement que dans un fichier de conf : je
>>>> fais comment alors ?
>>>>
>>> Qu'est ce que tu entends (techniquement) par cet "embed"?
>> Une personne qui utilise mon projet à partir des jars qui sont dans
>> maven. Je ne maîtrise pas ce qu'il fait au niveau des loggers.
>>
>> En pratique, ApacheDS est disponible sous deux formes :
>> - un executable, et tu disposes alors d'un serveur standalone
>> - ou des jars, que tu instancies dans ton code pour démarrer le serveur
>>
>> L'exécutable, en fait, ne contient qu'une classe qui embedde le serveur...
>>
>
> Devant la somme d'inconnus vis à vis de l'usage que peut en faire un
> utilisateur qui souhaite l'embed, personnellement je me contenterais de
> rédiger dans la doc d'intégration un § sur les logs

Certes. Mais ce serait tellement plus pratique de pouvoir dire à
l'utilisateur de pousser une requête LDAP pour basculer les logs en
DEBUG, de récuperer les logs, puis de repasser en mode normal, sans
tripoter de fichier..

C'est un use case, je pense qu'il y en a d'autres (cf Emmanuel S.)

>
> Nominalement j'imagine qu'en mode embed, tu ne fournis pas de loggeur juste
> la facade?

Voilà.