Keine Ahnung, warum hier jetzt ergoogelte Quellen, gefühlte Hostingumgebungen und was-weiß-ich-noch-sonst-so-kommen-wird ein buntes Potpourri bilden.
Natürlich benutzt man Logger, weil sie einem eine aufwendige eigene und im Zweifelsfall fehleranfällige Implementierung ersparen. Und weil diese auf Performance getrimmt sind. Und weil sie in der Auswahl der Logging-Targets die komplette Klaviatiur bespielen. Und weil sie - meist - extrem flexibel konfigurierbar sind. Und weil der Anbieter die - in der Regel/hoffentlich - konsequent weiterpflegt. Und... und... und...
Ich habe früher oft Log4net genutzt. Das stammt letztlich aus der gleichen Familie, nachdem aus dem Appache-Logger eine ganze Armada für verschiedene Sprachen und Frameworks entstanden sind, die teilweise von der Appache Foundation selbst oder anderen gepflegt werden. Inzwischen benutzen wir lieber NLog, was aber eher eine Geschmacklichkeit wegen seiner Flexibilität ist.
Warum ich die Frage nach dem Einsatz einer Java-Bibo in einem reinen Php-Umfeld für fragenswert hielt, habe ich schon geschrieben.
Es ist ja nun aber geklärt, dass offenbar manche Anbieter von Php-Applikationen auf Elastic, Solr oder Lucene setzen, die ihrerseits evtl./wahrscheinlich/whatever auch Log4J nutzen.
Alle drei verwandten Suchtechnologien werden von der jeweiligen Php-Applikation via http(s) über deren Api angesprochen, haben also bspw. mit der hinter der Php-Applikation liegenden whatever-Sql-Datenbank - in der sich dann auch Eure hoffentlich vernünftig gehashten Passwörter finden - nicht wirklich Kontakt. Natürlich kann man einen Server damit kompromittieren, wenn man das auf einer Kiste parallel laufen lässt.
In professionellen Umgebungen würde man Elastic oder seine Brüder eher in einen orchstrierten Zoo von Containern oder vergleichbarer Technologie stecken. Und auch sonst würde man... ach, das führt zu weit.
@michael wird wissen, ob er die kostenpflichtige XenForo-"Sucherweiterung" hier laufen hat..
