Discussion :

[Cissine]

Bonjour,

j'essaie de développer un ensemble de classes (Framework) de Log pour l'intégrer à des application web en se basant sur Logback.
La logique des chose est de :
Couche 1 : Créer une interface avec des méthodes de traces, voir méthode Trace() , Warn(), Info() ...etc.
Couche 2 : une implémentation de cette interface (Comme couche d'abstraction entre l'application et Logback)
Couche 3 : l'ensemble de classes Logback pour la gestion des log.
J'aimerai savoir s'il y a quelqu'un avec qui je peux échanger pour plus de détails et explications coté modélisation et dév.
Je vous remercie.

[CyberChouan]

Pourquoi veux-tu réinventer quelque chose qui existe déjà ?

Une couche d'abstraction au dessus de Logback (ou d'autres frameworks de logging), c'est SLF4J.

Maintenant, si tu veux essayer de faire la même chose pour apprendre, tu peux justement regarder comment ce projet est conçu : il est Opens Source.

[Cissine]

Bonjour,
Merci pour votre réponse, mais en fait, je ne veux rien inventer pour ce qui est Log ( Framewrok Logback + Couche d'abstraction SLF4J ) je veux juste les utiliser mais ajouter une couche supérieur ( Interface + InterfaceImpl + Implementation Logback...) pour que si aujourd'hui on travaille avec Logback on créer juste une instance de "Logback_impl" et si on veut basculé vers log4j on créer une instance de "log4j_impl" sans modifier au code qui utilise ces framework de Log.

Dans le code utilisateur il n'a qu'a récupérer un nouvelle instance et avoir un log du genre :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
InterfaceImpl.getInstance.Debug(" Msg1 ");
InterfaceImpl.getInstance.Info(" Msg2 ");

J'espère que j'étais claire !

[tchize_]

Vous êtes occupé d'ajouter des couches, des tartines et du nutella inutile sur votre application. Le jour où vous vous débarasserez de logback pour une raison X ou Y, vous irez dans votre code, et en une journée ce sera pliée. La vous allez passer plusieur jours à mettre en place un truc qui, selon mon expérience, ne sera jamais utilisé (je n'ai eu en 5 ans aucun projet où on a dut changer la couche logging). Si vous voulez vraiment etre versatile dans votre méthode de logging, il existe déjà des couche intermédiaires comme commons-logging, par exemple.

Vous ne créez pas votre surcouche sur spring en disant "en jour j'utiliserais peut etre autre chose que spring" ni au dessus de hibernate en disant "un jour j'utiliserait peut etre un autre orm", ... Ne compliquez pas votre application pour des fonctionnalité dont il est très peu probable que vous en auraez besoin, concentrez vous sur les fonctionnalités dont le client a réellement besoin (Qu'est-ce que ca peux lui faire que ce soit logbak, log4j, slf4j, ou java logging que vous utilisez )

[Cissine]

Je te remercie pour ces conseils précieux mais ce que je cherche c'est de l'aide pour pouvoir avancer sur mon projet (Ce n'est pas dans le but de m'amuser).
Ces couche ne seront pas si compliqués que ca, c'est une interface avec implémentation, lié a une implémentation de Logback.
Une journée c'est sur !! si tu as une application de taille normal. Si t'as une grosse application c'est plus facile de changer l'implémentation en instanciant le nouveau composant et l'application continue à récupérer l'instance, et rien ne change au code.

[tchize_]

avec quelques commandes sed bien placées, 99% des appels logger sont remplacés par un autre, reste les quelques cas borderline à faire à la main. J'ai déjà fait (c'était pas pour des logger) des changement similaire dans une grosse application (une api X à remplacer par api Y aux fonctionnalités similaires), quand le code a été rigoureux, le changement est automatique.

De plus, comme déjà dit, et pas seulement par moi, ce genre d'implémentation existe déjà et ca reste idiot à mettre en place pour une application (c'est destinée à des librairies réutilisable qui ne savent pas à quel logger elles vont être mangées).

Enfin, faire une interface sur un logger n'est pas si simple que ça y parait . Les loggers sont profondément ancré dans l'application et se doivent d'être rapides sous peine de la plomber. Les api de logging ont donc beaucoup de fonctionnalités destinées à éviter les pertes de performances. Des fonctionnalités permettant de passer une chaine non formattée, pour ne faire le formattage que si nécessaire, des fonctionnalités permettant de savoir si un niveau de logging est activé, etc. Bref, c'est bien plus qu'une interface. Par exemple, ce genre de code en logging:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for (.......){
    .....
    log.debug("objet "+x+" sélectionné pour traitement avec "+y.getTreatment(x));
}

est une catastrophe coté performances, et votre "couche" doit pouvoir y fournir des solution, tout comme les loggers le font.


Vous voulez des explications coté modélisation et dev, on vous en a donné:
coté dév: ca existe déjà vous réinventez la roue
coté modélisation: c'est très fort probablement inutile de faire ça