SLF4J (Simple Logging Fa�ade til java) er en API designet til at give generisk adgang til mange logningsrammer, hvor log4j er en af ​​dem.

Det er dybest set et abstraktionslag. Det er ikke en logningsimplementering. Det betyder, at hvis du skriver et bibliotek, og du bruger SLF4J, kan du give det bibliotek til en anden at bruge, og de kan vælge, hvilken logningsimplementering, der skal bruges med SLF4J, f.eks. log4j eller Java-lognings-API'en. Det bruges til at forhindre, at applikationer er afhængige af forskellige lognings-API'er, ligesom de bruger biblioteker, der er afhængige af dem.

Vi uddyber dog forskellen mellem Log4J og SLF4J, der kun fortjener et linjesvar. dvs. selve spørgsmålet er forkert. SLF4J og Log4J er forskellige, eller de er ikke ens komponenter. Som navnet er angivet, er SLF4J en simpel log-facade til java. Det er ikke en logningskomponent, og selv den udfører ikke selve logningen. Det er kun et abstraktionslag til en underliggende logningskomponent.

I tilfælde af Log4j , det er en logningskomponent, og den udfører den logning, der er instrueret i. Så vi kan sige, at SLF4J og Log4J logisk set er to forskellige ting.

Nu skal du bare vælge, hvilken logningsramme du skal bruge i runtime. Til det skal du inkludere to jar-filer:

• SLF4J indbindingskrukkefil
• Ønskede logningsramme-jar-filer

For eksempel, for at bruge log4j i dit projekt, skal du inkludere følgende jar-filer:

• slf4j-log4j12-1.7.12.jar
• log4j-1.2.17.jar

Når du har placeret begge jar-filer i din applikationsklassesti, vil SLF4J automatisk finde den og begynde at bruge log4j til at behandle log-sætningerne baseret på den konfiguration, du har angivet i log4j-konfigurationsfilen.

Nedenstående kode kan du for eksempel skrive i din projektklassefil:

 import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class HelloWorld { public static void main(String[] args) { Logger logger = LoggerFactory.getLogger(HelloWorld.class); logger.info('Hello World'); } } 

Hvorfor er SLF4J bedre end Log4J?

Det er altid svært at foretrække en mellem SLF4J og Log4j. Hvis du har et valg, vil jeg foreslå dig; logningsabstraktion er altid at foretrække end logningsramme. Hvis du bruger en logningsabstraktion, især SLF4J, kan vi migrere til enhver logningsramme, vi har brug for på tidspunktet for implementeringen uden at vælge en enkelt afhængighed.

Følgende er grundene, som er gode nok til at vælge SLF4J frem for Log4j:

• Det er altid bedre at bruge abstraktion.
• SLF4J er et open source-bibliotek eller internt bibliotek, der gør det uafhængigt af enhver bestemt logningsimplementering, hvilket betyder, at der ikke er behov for at administrere flere logningskonfigurationer for flere biblioteker.
• SLF4J giver pladsholderbaseret logning, som forbedrer kodes læsbarhed ved at fjerne checks som isInforEnabled(), isDebugEnabled() osv.
• Ved at bruge logningsmetoden i SLF4J udskyder vi omkostningerne ved at konstruere logningsmeddelelser (streng), indtil du har brug for det, hvilket er både CPU- og hukommelseseffektivt.
• Da SLF4J bruger mindre antal midlertidige strenge, betyder det mindre arbejde for skraldeopsamleren, hvilket betyder bedre gennemløb og ydeevne for din applikation.

Så i det væsentlige erstatter SLF4J ikke log4j; de arbejder begge sammen. Det fjerner afhængigheden af ​​log4j fra din applikation og gør det nemt at erstatte det i fremtiden med det mere kompetente bibliotek.