Si t’utilise tomcat, je suppute que tu a un war, qui inclue tous les jar de ton appli.
Une autre pratique courante est d’utiliser un serveur d’appli embedded, et de shader le jar, à savoir exploser toutes les dépendances et les mettre dans un seul gros jar.
L’avantage étant que tu te fades pas tomcat (ou autre), et surtout, tu lances l’appli avec un simple java -jar monjar.jar, ce qui rend les deploiements vachement plus simple (parce que dire à tomcat d’arrêter cette web app et la relancer, c’est vachement plus compliqué qu’un kill + java -jar monjar.jar).
Bref, le problème c’est que je vois pas comment ta commande peut marcher dans ce mode.
Ah, et sinon, même si ça marchait, y’a des chances pour que des bindings log4j soit embarqués par une dépendance transitive si t’utilise slf4j. Ce qui compte c’est de ne pas avoir log4j-core si je me rappelle bien.
[^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille
Posté par groumly . En réponse à la dépêche Détectez et bloquez les tentatives d'exploitation de Log4j avec CrowdSec. Évalué à 2.
Si t’utilise tomcat, je suppute que tu a un war, qui inclue tous les jar de ton appli.
Une autre pratique courante est d’utiliser un serveur d’appli embedded, et de shader le jar, à savoir exploser toutes les dépendances et les mettre dans un seul gros jar.
L’avantage étant que tu te fades pas tomcat (ou autre), et surtout, tu lances l’appli avec un simple java -jar monjar.jar, ce qui rend les deploiements vachement plus simple (parce que dire à tomcat d’arrêter cette web app et la relancer, c’est vachement plus compliqué qu’un kill + java -jar monjar.jar).
Bref, le problème c’est que je vois pas comment ta commande peut marcher dans ce mode.
Ah, et sinon, même si ça marchait, y’a des chances pour que des bindings log4j soit embarqués par une dépendance transitive si t’utilise slf4j. Ce qui compte c’est de ne pas avoir log4j-core si je me rappelle bien.