# Logging (log4j) in JAVA EE application - WildFly



## beta20 (28. Aug 2018)

Hallo zusammen, 

meine Applikation verwendet aktuell noch nicht wirklich eine Loggingfunktionalität, was ich aber ändern will.
Ich verwende *Wildfly *als Applikationsserver.

Nun meine erste Frage:
- Wildfly erstellt ja selbst Logfiles, soll ich meine Logs meiner Applikation hier reinschreiben?
-> Was muss ich dann zusätzlich einstellen? Wie schreibe ich in dieses Logile herein?
- Oder: Soll ich neben den Wildfly Logs ein zusätzliches Logfile(s) erstellen?
-> Was muss ich dann zusätzlich einstellen? Wie schreibe ich in dieses Logile herein?

- Ich möchte ja nicht 10000 Logfiles erstellen, sondern ein Logfile soll nach 10x überschrieben werden (zum Beispiel)....
- Ich möchte nur WARN und ERROR in das Logfile schreiben - INFO brauche ich nicht... Wo kann ich das einstellen?

Vielen Dank für jede Hilfe


----------



## Flown (28. Aug 2018)

Was sagt die Entwicklerseite dazu?


----------



## beta20 (28. Aug 2018)

Von Log4j oder Wildfly?


----------



## Flown (28. Aug 2018)

Naja du willst Wildfly konfigurieren, also natürlich Wildfly.


----------



## beta20 (21. Nov 2018)

Prinzipiell gilt es mir erst mal Erfahrung zu bekommen, wie man das sonst in IT Projekte macht?
Nutzt man das Logfile von Wildfly oder erstellt man zusätzlich Logfiles?


----------



## kay73 (23. Aug 2019)

Hi @beta20,


beta20 hat gesagt.:


> Nutzt man das Logfile von Wildfly oder erstellt man zusätzlich Logfiles?


Die Idee der Applikationsserver ist, einer Anwendung möglichst alles an Infrastruktur und Ressourcen (Datenbanken, Netzwerkabstraktion usw.) zur Verfügung zu stellen. Dazu gehören auch Logger. Hier findest du diesen Code

```
@Produces
    Logger getLogger(InjectionPoint ip) {                         
        String category = ip.getMember()
                            .getDeclaringClass()
                            .getName();
        return Logger.getLogger(category);
    }
```
 dazu. Soll zeigen wie es sein soll und der Output landet im wildfly log. Änderungen an der Konfiguration sind nur im XML des Servers möglich; Neustart von Nöten.


beta20 hat gesagt.:


> Prinzipiell gilt es mir erst mal Erfahrung zu bekommen, wie man das sonst in IT Projekte macht?


Applikationsserver sind mausetot. Sie haben einen monströsen Footprint, skalieren schlecht, ihr Code ist veraltet beim Erscheinen und sind äußerst schwierig bis unmögich zu patchen. Sie sind das Gegenteil der Microservice-Idee, begünstigen den Bau von Monolithen und zwingen Dir eine Codebasis auf, die verschimmelt und beim Lebensende in Gänze fortgeworfen wird.

Spring Boot + SLF4j an Log4j2. Oder micronaut.io.


----------



## mrBrown (23. Aug 2019)

kay73 hat gesagt.:


> Applikationsserver sind mausetot. Sie haben einen monströsen Footprint, skalieren schlecht, ihr Code ist veraltet beim Erscheinen und sind äußerst schwierig bis unmögich zu patchen. Sie sind das Gegenteil der Microservice-Idee, begünstigen den Bau von Monolithen und zwingen Dir eine Codebasis auf, die verschimmelt und beim Lebensende in Gänze fortgeworfen wird.


Das ist allerdings sehr hart ausgedrückt bis sehr übertrieben...


----------



## kay73 (23. Aug 2019)

mrBrown hat gesagt.:


> Das ist allerdings sehr hart ausgedrückt bis sehr übertrieben...








						blog - devmio - Software Know-How
					

[...]Read More...




					jaxenter.com


----------



## mrBrown (23. Aug 2019)

Na gut, mit einem Artikel, der auf immerhin einen der von dir genannten Punkte eingeht, hast du natürlich jede Diskussion sofort gewonnen...


----------



## kay73 (23. Aug 2019)

Leider sind der Rest schmerzliche Erfahrungen... :-(


----------



## Flown (23. Aug 2019)

kay73 hat gesagt.:


> Applikationsserver sind mausetot.


Vielleicht in der Hipsterwelt. Application Server sind jetzt auch nur noch ein weiterer Container in der Cloud.


kay73 hat gesagt.:


> Sie haben einen monströsen Footprint, skalieren schlecht, ihr Code ist veraltet beim Erscheinen und sind äußerst schwierig bis unmögich zu patchen.


Vom welchem Jahr sprichst du denn? Also mein Kunde arbeitet derzeit mit JBoss EAP 7.x.x im Openshift. Konfiguriert wird über Docker und Patch ist beim nächsten Deployment dabei.


kay73 hat gesagt.:


> Sie sind das Gegenteil der Microservice-Idee, begünstigen den Bau von Monolithen und zwingen Dir eine Codebasis auf, die verschimmelt und beim Lebensende in Gänze fortgeworfen wird.


Sie sind jetzt Teil des (Bullshitbingo) Microservice Gedanken. Weil man kann Microservices auch mit AS bauen. Monolithen sind Designentscheidungen und kein fester Weg. Mittlerweile sind die AS so gut, dass die nur noch on-demand starten und der Footprint ca. gleich viel hat, wie der von Spring, et al.

Wobei reden wir von Spring. Das zwingt dir keine Codebasis auf? Ich finde beide Seiten (AS und Microservice Frameworks) sind mittlerweile gleichwertig und bieten in etwa die gleichen Funktionalitäten. Vielleicht gibt es für Spring mehr fancy-pansy Libraries und Communityunterstützung. Aber wenn man bedenkt, wie stabil und sicher (ich rede jetzt von einem ordentlichen AS und nicht Glassfish) sich EE/AS im Laufe der Jahre gezeigt hat.

Aber gut das ist mal wieder Geschmacksthema und wie ich aus Erfahrung sagen kann, sind Microservices in seltensten Fällen applikabel bei den Anforderungen meiner Kunden.


----------



## mrBrown (23. Aug 2019)

kay73 hat gesagt.:


> Sie haben einen monströsen Footprint


https://middlewareblog.redhat.com/2...-a-platform-for-current-and-future-workloads/ und http://www.adam-bien.com/roller/abien/entry/memory_footprint_of_java_ee sind dazu ganz interesssant



kay73 hat gesagt.:


> skalieren schlecht


Nicht schlechter als monolithische Spring-Applications. Und richtig umgesetzt auch nicht deutlich schlechter als Microservices au Spring-Boot-Basis.



kay73 hat gesagt.:


> ihr Code ist veraltet beim Erscheinen


Ne, nicht wirklich. Genauso könnte man sagen "Spring ist veraltet beim erscheinen".



kay73 hat gesagt.:


> äußerst schwierig bis unmögich zu patchen


Kenn's nur vom Wildfly, da ist einzelne Libs patchen ziemlich einfach. Mit Spring ist das nicht deutlich einfacher...



kay73 hat gesagt.:


> Sie sind das Gegenteil der Microservice-Idee, begünstigen den Bau von Monolithen


Microservices haben nicht nur Vorteile (die die wenigsten brauchen), genauso wie Monolithen nicht nur Nachteile haben.



kay73 hat gesagt.:


> eine Codebasis auf, die verschimmelt und beim Lebensende in Gänze fortgeworfen wird


Wenn man sich an den Standard hält eine Codebasis, die man auch in X Jahren noch dem Standard entspricht und auf entsprechenden Servern läuft.
Anders als bei Alternativen, wo man sich an keinen Standard hält und beim nächsten Update schon mal aufgeschmissen ist...


----------



## kay73 (23. Aug 2019)

Flown hat gesagt.:


> Application Server sind jetzt auch nur noch ein weiterer Container in der Cloud.


Wo ich sie deploye ist ja Nebensache.


Flown hat gesagt.:


> Vom welchem Jahr sprichst du denn?


Den letzten habe ich vor 3,4 Jahren unter den Fingern gehabt. EAP6, wenn ich mich nicht irre.


Flown hat gesagt.:


> Also mein Kunde arbeitet derzeit mit JBoss EAP 7.x.x im Openshift. Konfiguriert wird über Docker und Patch ist beim nächsten Deployment dabei.


IMHO ein Antipattern. Wozu dann Docker? ASse haben den "Anspruch" alles zu besitzen. Gerade EAP7....


Flown hat gesagt.:


> Weil man kann Microservices auch mit AS bauen.


Und wozu dann der AS?


Flown hat gesagt.:


> Monolithen sind Designentscheidungen und kein fester Weg.


Sorry, hier gibt es keinen Konsens. Habe zuviel Schlimmes gesehen in der Richtung.


Flown hat gesagt.:


> Wobei reden wir von Spring. Das zwingt dir keine Codebasis auf?


Die werfe ich dort weg, wenn sie mir an einer Stelle nicht gefällt. Dank sauberer Trennung der meiner Domänen.


Flown hat gesagt.:


> Ich finde beide Seiten (AS und Microservice Frameworks) sind mittlerweile gleichwertig


Sorry, auch hier kein Konsens.


mrBrown hat gesagt.:


> https://middlewareblog.redhat.com/2...-a-platform-for-current-and-future-workloads/


Das ist Werbung vom Hersteller.


mrBrown hat gesagt.:


> http://www.adam-bien.com/roller/abien/entry/memory_footprint_of_java_ee sind dazu ganz interesssant


Der argumentiert einseitig. (Wolff auch. Ich auch ;-)) Aber der zeigt auf seinen Talks Microservices, die er in Wildfly deployt und in 700 MB Dockerimages packt und findet das toll.


mrBrown hat gesagt.:


> Nicht schlechter als monolithische Spring-Applications.


Wer macht denn sowas?


mrBrown hat gesagt.:


> Ne, nicht wirklich. Genauso könnte man sagen "Spring ist veraltet beim erscheinen".


Release-Zyklen von 3 Jahren vs. 3 Monaten? Und dann wurde bei EE 6 noch hastig Dependency Injection hineingeworfen. Implementiert von Spring-Leuten... Erinnere mich noch eine kaputtes Jackson-JAR im JBoss 6 oder so, das total Nerven kostete. Das nochmal zum Thema patchen.


mrBrown hat gesagt.:


> Kenn's nur vom Wildfly, da ist einzelne Libs patchen ziemlich einfach. Mit Spring ist das nicht deutlich einfacher...


Das kann man kaum vergleichen: Server runterfahren und JARs in einen Modulpfad kopieren, xml-Descriptor anpassen und alles  hochfahren? Bei Spring Versionsnummer im VCS ändern, releasen und ausrollen. Wenn verteilt, sogar ohne Downtime. Und vor allem dies direkt im Quellcode. Ohne ein einen Server in einem Configuration Management zu konfektionieren.


mrBrown hat gesagt.:


> Microservices haben nicht nur Vorteile (die die wenigsten brauchen), genauso wie Monolithen nicht nur Nachteile haben.


Ok, darauf lasse ich mich ein. 


mrBrown hat gesagt.:


> Wenn man sich an den Standard hält eine Codebasis, die man auch in X Jahren noch dem Standard entspricht und auf entsprechenden Servern läuft.


Das ist eine Milchmädchenrechnung: Spring Anwendungen laufen auch "nach Jahren" noch. Nur ohne aufgezwungenes Produkt, das nicht mehr gepflegt wird. Und vor allem: Der "Standard" ist vom Hersteller auf den Eclipse Foundation Gnadenhof verklappt worden und die ehemalige Referenzimplementierung (Glassfish) hat den kommerziellen Support abgekündigt bekommen. Und alle "Evangelisten" haben RedHat verlassen. Ist das ein Standard, auf den man guten Gewissens aufsetzen will?


mrBrown hat gesagt.:


> Anders als bei Alternativen, wo man sich an keinen Standard hält und beim nächsten Update schon mal aufgeschmissen ist...


Jetzt widersprichst Du dir: Du kannst nicht  mit"Update" argumentieren und im Satz davor sagen, dass alles noch nach Jahren läuft. Das, was da "nach Jahren läuft", ist nie geupdatet worden. Sondern verschimmelt. ;-)

Java hat heutzutage das Problem, sich fragen lassen zu müssen, warum eine Hallo-Welt-Mini-Webanwendung selbst als "Microservice" noch zwischen 12-20 MB gross sein muss (Spring Boot) und 3-5 Sekunden zum Hochfahren braucht. Wo funktionale Ansätze fast statisch schnell sind. Es sind native Images auf Basis der GraalVM im Kommen oder 7MB Container mit einem Go-Binary. Und dann kommen die *Hippster* mit node.js. Und das sind Dinge, die sich direkt auf Kosten auswirken.

Das ist ein wenig der Hintergrund, der mich antreibt, so auf ASsen zu schimpfen. *Bitte fühlt Euch nicht angegriffen!*


----------



## Flown (23. Aug 2019)

kay73 hat gesagt.:


> Wo ich sie deploye ist ja Nebensache.


Nicht WO, sondern WAS ist Nebensache im Cloudumfeld.


kay73 hat gesagt.:


> IMHO ein Antipattern. Wozu dann Docker? ASse haben den "Anspruch" alles zu besitzen. Gerade EAP7....


Äh what? Alles im Openshift läuft in einem Container sprich Docker ...
AS ist ein Bundle an Implementierungen für die EE API und Konfigurationsmöglichkeiten nicht mehr und nicht weniger


kay73 hat gesagt.:


> Und wozu dann der AS?


Weil er z.B. den JAX-RS und Webserver bundled?


kay73 hat gesagt.:


> Sorry, hier gibt es keinen Konsens. Habe zuviel Schlimmes gesehen in der Richtung.


Wow ich hab auch schon alles gesehen und mitgemacht. Aber es ist und bleibt ein Consulting und Architekturproblem und wie @mrBrown schon geschrieben hat, hat es auch seine Daseinsberechtigung.


kay73 hat gesagt.:


> Sorry, auch hier kein Konsens.


Hmmm ... Ich würde sagen, dass Microservices ein Subset von AS bilden (es gibt zwar keine klare Definition, aber jeder möchte JAX-RS, CDI/EJB, JPA haben). Daher kann man super mit AS auch Microservices bauen.


kay73 hat gesagt.:


> Der argumentiert einseitig. (Wolff auch. Ich auch ;-)) Aber der zeigt auf seinen Talks Microservices, die er in 700MB Dockercontainer mit Wildfly packt und findet das toll.


Wie startest du ohne OS jetzt dein Java/Spring? Was sind dann schon ~200 MB AS Server schon? Ahja und was glaubst du was Spring Boot so im Uberjar mit Tomcat-WS etc. gepackt groß ist? Also ich hab auch schon Spring Anwendungen mit 250 MB gesehen. Und auch schon WARs die nur ~1MB groß waren mit voller business Logik. Also ist das jetzt schon mal kein PRO und kein CONTRA für beide Seiten. Sie machen beide das Gleiche, bieten die gleiche Infrastruktur, nur wie man was, wann, wo, wie deployed/startet ist anders.


kay73 hat gesagt.:


> Wer macht denn sowas?


Nicht alles lässt sich mit Microservices abbilden (ohne riesigen Overhead)


kay73 hat gesagt.:


> Das kann man kaum vergleichen: Server runterfahren und JARs in einen Modulpfad kopieren, xml-Descriptor anpassen und alles hochfahren? Bei Spring Versionsnummer im VCS ändern, releasen und ausrollen. Wenn verteilt, sogar ohne Downtime. Und vor allem dies direkt im Quellcode. Ohne ein einen Server in einem Configuration Management zu konfektionieren.


Docker Config anpassen. Fertig. Funktioniert gleich.


kay73 hat gesagt.:


> Jetzt widersprichst Du dir: Du kannst nicht mit"Update" argumentieren und im Satz davor sagen, dass alles noch nach Jahren läuft. Das, was da "nach Jahren läuft", ist nie geupdatet worden. Sondern verschimmelt. ;-)


Was er gemeint hat ist, dass man eine EE 5 auf EE 8 deployen kann


----------



## mrBrown (23. Aug 2019)

Was für Unsinns-Argumente sind denn das? 'Mit AS entwickelt ja jeder falsch und wenn er Spring benutzen würde, würde er es besser machen'.

Wer mit AS riesige, unhaltbare Monolithen entwickelt, macht das mit Spring nicht anders. Wer mit Spring sauber entwickelt, macht das auch mit AS.
Wenn du mit AS keine saubere Trennung von Domänen hinbekommst, schaffst du das mit Spring auch nicht.

Und ernsthaft?  AS "zwingen Dir eine Codebasis auf, die verschimmelt und beim Lebensende in Gänze fortgeworfen wird.", aber die Spring-Anwendung ist gut, weil "Die werfe ich dort weg, wenn sie mir an einer Stelle nicht gefällt"



kay73 hat gesagt.:


> Der argumentiert einseitig. (Wolff auch. Ich auch ;-)) Aber der zeigt auf seinen Talks Microservices, die er in 700MB Dockercontainer mit Wildfly packt und findet das toll.


Microservices darf man natürlich nur toll finden, wenn sie in 573MB 700MB mit Spring umgesetzt sind 



kay73 hat gesagt.:


> Wer macht denn sowas?


Ziemlich viele. Ist eben deutlich einfacher, als Microservices.



kay73 hat gesagt.:


> Release-Zyklen von 3 Jahren vs. 3 Monaten?


Vom Wildfly gibts alle 3 Monate 'ne neue Version 
Oder beziehst du dich wirklich auf den EE-Standard? Was ist denn das für ein Unsinns-Argument, weil der Standard über mehrere Jahre Stabil ist und nicht alle drei Monate in einer inkompatiblen Version released wird, ist das schlecht?



kay73 hat gesagt.:


> Das kann man kaum vergleichen: Server runterfahren und JARs in einen Modulpfad kopieren, xml-Descriptor anpassen und alles hochfahren? Bei Spring Versionsnummer im VCS ändern, releasen und ausrollen. Wenn verteilt, sogar ohne Downtime. Und vor allem dies direkt im Quellcode. Ohne ein einen Server in einem Configuration Management zu konfektionieren.


Also, AS ist schlecht, weil man Server unterfahren muss, Spring aber gut, weil man Server nur beenden muss?
AS schlecht, weil man das Modul updaten muss (was sich Skripten lässt), aber Spring gut, weil man nur Dependance updaten muss.
Und AS schlecht, weil man den Server starten muss, aber Spring gut, weil man nur Server starten muss?

(BTW, deinen Spring-Weg kann mit mit AS genauso fahren, mach ich auch so...)



kay73 hat gesagt.:


> Das ist eine Milchmädchenrechnung: Spring Anwendungen laufen auch "nach Jahren" noch. Nur ohne aufgezwungenes Produkt, das nicht mehr gepflegt wird.


Ja, laufen noch, aber lassen sich halt nicht mehr updaten - und, Luft anhalten, Spring ist dabei das aufgezwungenes Produkt.
Das "aufgezwungene Produkt" bei AS ist ein *offener Standard*, gegen den man entwickelt. Die Anwendung kann man ohne große Änderungen auf einen neuen AS verschieben und es läuft weiter, und alles ist geupdated, ohne die eigentliche Anwendung angefasst zu haben. (Ja, man muss u.U. die Config des AS anpassen, bei Spring musst du das aber ebenso).



kay73 hat gesagt.:


> Jetzt widersprichst Du dir: Du kannst nicht mit"Update" argumentieren und im Satz davor sagen, dass alles noch nach Jahren läuft. Das, was da "nach Jahren läuft", ist nie geupdatet worden. Sondern verschimmelt. ;-)


Ne, das liegt an deinem Verständnis von Update 
Eine .war, die vor X Jahren gegen den Standard entwickelt und seit dem nicht angefasst wurde, ist auch mit dem aktuellem Standard kompatibel und läuft entsprechend auch auf kompatiblen AS.
Die Fat-Jar, die man vor X Jahren entwickelt und seit dem nicht angefasst hat, ist nicht mehr mit der aktuellen Version kompatiblen und jetzt wirklich verschimmelt, da kann man nicht mal einfach alte Libs updaten.




Ernsthaft, deine ganze Argumentation beruht darauf, das alle mit AS entwickelten Anwendungen grottenschlecht von völlig unfähigen Entwicklern entgegen allen Best-Practices umgesetzt sind, aber alle Spring-Boot-Anwendungen von fähigen Entwicklern nach allen Best-Practices mit perfekter Codebasis entwickelt sind. Die Realität sieht aber anders aus...

Den ganzen Prozess, der bei Spring laut dir so wunderbar ist, kann man nahezu identisch mit AS umsetzen. Und genauso kann man alles, was man laut dir immer mit AS falsch macht, genauso mit Spring falsch machen.
Und, Überraschung, beides passiert. Weder mit mit Spring alles gut, noch mit AS alles schlecht, in der Realität ist das ziemlich ausgeglichen...


----------



## mihe7 (24. Aug 2019)

kay73 hat gesagt.:


> Der "Standard" ist vom Hersteller auf den Eclipse Foundation Gnadenhof verklappt worden und


... damit wurde die Weiterentwicklung der Spezifikation an die Community abgegeben. Wo liegt das Problem? Microsoft hat sich übrigens auch angeschlossen.



kay73 hat gesagt.:


> und die ehemalige Referenzimplementierung (Glassfish) hat den kommerziellen Support abgekündigt bekommen.


Nö. Das ist ganz ähnlich zum Unterschied zwischen OpenJDK und Oracle Java.

Für Glassfish Open Source gab es noch nie kommerziellen Support. "Oracle Glassfish Server" war nicht die Referenzimplementierung sondern das von Oracle vertriebene Produkt (ein Oracle Build von Glassfish + kommerzielle Features). 

Die Entscheidung, dass Oracle nicht mehrere Application Server kommerziell anbietet, dürfte nachvollziehbar sein.



kay73 hat gesagt.:


> Bitte fühlt Euch nicht angegriffen!


Warum sollte sich hier jemand angegriffen fühlen?


----------

