Interface de Log et implementation

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.

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.

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:

---

1 2 3

InterfaceImpl.getInstance.Debug(" Msg1 "); InterfaceImpl.getInstance.Info(" Msg2 ");

---

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

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 ;) )

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.

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:

---

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

bonjour,

J'ai fait un petit test hier avec ce que j'ai développé, je n'ai rien inventé coté Logback + SLF4j j'ai juste utilisé ces deux composants pour être intégré a mon Framework.

J'ai une Interface où y a définit des méthodes de trace :

Code:

---

1 2 3 4 5 6

public interface InterfaceUserLog {   InterfaceUserLogImpl _InterfaceUserLogImpl = null ;   public void trace(String message); ...

---

Une classe (Singleton) qui implémente mon interface :

Code:

---

1 2 3 4 5 6 7 8

public class InterfaceUserLogImpl implements InterfaceUserLog{   MyLogger myLogger = new MyLogger(); public void trace(String message){   myLogger.trace(message); } ...

---

une Classe MyLogger, là où y a définit mon Logger et le formatage des traces.

Code:

---

1 2 3 4 5 6 7 8 9

public class MyLogger {   Logger rootLogger =(Logger)LoggerFactory.getLogger(this.getClass()); LoggerContext loggerContext = rootLogger.getLoggerContext(); public void trace(String message){   init_Logback(); rootLogger.trace(message); }

---

Dans nos application il faut maintenant juste faire :

Code:

---

InterfaceUserLogImpl.getInstance().trace("..");

---

pour tracer et plus besoin de declarer de logger.


Ma question est la suivante :
Lors de l'affichage de mon enregistrement, je n'ai pas le nom de la classe responsable du log mais celle qui définit le log, Cad MyLogger;
Comment puis-je faire pour avoir le nom de la classe responsable de l'enregistrement ?

Je suis bloqué Ici :( !! si vous pouvez m'aider.

Je vous remercie d'avance.

Ben vous devez la passer à InterfaceUserLogImpl pour qu'il instancie la classe MyLogger qui lui correspond qui elle même instanciera la classe rootLogger.

Bref si vous espériez faire de InterfaceUserLogImpl un singleton, c'est pas partis.

J'ai pas très compris " passer à InterfaceUserLogImpl qui instanciera MyLogger qui lui correspond qui elle même insanciera (Un Object de type Logger) rootLogger "

Dans un exemple ca ressemblera à quoi cette doubles ou triples instanciation ?

à ça en gros

Code:

---

1 2 3 4 5

private InterfaceUserLog log = new InterfaceUserLogImpl(this.class); .... log.isTraceEnabled(){ log.trace(message); }

---

Effectivement, le Singleton ne sers plus à rien si je fais cela, le but quand même est de creer une seule instance et la récupérer à chaque fois...
Cette solution résout mon problème et en crée un autre.
J'ai pensé à ajouter un argument à ma méthode trace qui contient le nom de la classe mais là encore l'utilisateur de mon Framework perdra cette définition de Log, qui est de laissé que le message à enregistré comme argument.

Alalala C'est pas Facile !! :calim2: