Java >> Java tutorial >  >> Tag >> Log4j

Sådan implementeres Log4j-audit i Java/GWT webapp

Arbejder i øjeblikket på at implementere revisionslogning til en webapp og vil gerne bruge log4j-audit. Appen er skrevet ved hjælp af OpenJDK 8 og GWT 2.7 hostet af Jboss 6.4 og bygget ved hjælp af Ant 1.10.5. Mit spørgsmål er, hvordan implementerer man log4j-audit frameworket i vores nuværende struktur? Jeg har arbejdet mig igennem afsnittet Kom godt i gang og læst dokumentationen udtømmende, men min manglende Maven-erfaring gør det svært at transportere den til vores stak.

Min nuværende forståelse er, at jeg skal oprette et anmodningsfilter, der instansierer en RequestContext objekt, der gemmer variabler i en ThreadContext kort. Det, jeg har brug for at vide, er, hvordan jeg bruger min catalog.json at generere de grænseflader, som jeg kan referere til i min kode.

Tak!

EDIT:

Takket være oplysningerne i afsnittet 1. af det markerede svar nedenfor var jeg i stand til at oprette en brugerdefineret Ant-opgave med en POM svarende til den i eksempelappen, der bygger audit-service-api.jar og refererer til de genererede kilder i min kodebase.

Svar

RequestContextFilter er en udvidelse af Log4j ThreadContext, der giver dig mulighed for at konvertere overskrifter, der sendes i REST-anmodninger, til ThreadContext-attributter. Dette er vigtigt for revision, så du kan videregive brugerens loginId, IP-adresse, kontonummer osv., så de kan indgå i alle revisionsbegivenheder (samt alle de andre logs). Selvom det ikke nødvendigvis er vigtigt for revisionslogning, er inklusive et requestId og "sessionId" vigtigt for diagnosticerings- og fejlretningslogfiler for at korrelere logfiler på tværs af tjenester og servere.

catalog.json-filen bruges til at definere revisionsbegivenheder og attributter. Normalt ville du oprette et projekt, der ligner log4j-audit-sample. Dette projekt indeholder 3 ting:

  1. Revisionsservice-API'en – catalog.json findes i src/main/resources og indeholder definitionerne af dine hændelser og attributter. Når du kører "mvn clean package", "mvn clean install" eller "mvn clean deploy" på dette projekt, vil det læse kataloget og generere alle Java-grænseflader til de hændelser, du har defineret. Du vil derefter inkludere jar konstrueret fra dette projekt i dine applikationer sammen med log4j-audit-api jar for at logge begivenhederne.
  2. Revisionstjenesten – En REST-tjeneste, der kan bruges til at logge hændelser fra ikke-Java-applikationer. Tjenesten vil validere begivenhederne i forhold til dit katalog.

Log4j-audit kommer med en Spring Boot-app, der kan bruges som editor til kataloget, da redigering af JSON kan være besværlig og udsat for fejl. Når det er sagt, skal Spring Boot-appen køres som en enkelt bruger desktop-app, hvilket er lidt mærkeligt, så en desktop-editor baseret på ElectronJS er ved at blive udviklet.

Log4j-audit understøtter i øjeblikket to formater til kataloget; catalog.json-filen gemt i git eller et RDMS-katalog, der tilgås via JPA. Normalt bruges kataloget, der er gemt i git, til at generere Java-grænseflader, fordi de kun skal ændres normalt under den normale udviklingsproces, og du vil gerne administrere disse definitioner med en normal udgivelsescyklus. Spring Boot-katalogeditoren læser json-kataloget fra git og indlæser det derefter i en database i hukommelsen, så editoren kan drage fordel af den referenceintegritet, som databasen giver. Revisionstjenesten kan konfigureres til at bruge en database til at gemme et "dynamisk katalog". Ingen Java-grænseflader er tilgængelige for disse katalogposter, og applikationer, der ønsker at udføre revision ved hjælp af disse hændelsesdefinitioner, skal gøre det gennem revisionstjenesten.

Forhåbentlig giver det de oplysninger, du leder efter, men hvis du udførte trinene på siden Kom godt i gang og ser på eksempelapplikationen, burde du have en idé om, hvad du skal gøre. Hvis ikke, følg venligst op med flere spørgsmål.


Java tag