I think the perf point is likely wrong. Default JUL handlers are "slow" (the hypothesis being you log a lot but this is more comparatively to others frameworks) but if you switch the handler impl you can even bit log4j2 disruptor setup so JUL is not slow by itself but only its configuration can be so I think it is ok to use JUL. Also Tomcat allows to switch the Log impl so you can use any impl, including a stdout/stderr implementation which can be something worth making configurable more than limiting it to the access log IMO (like -Dtomcat.log.usestdstreams=true in LogFactory or just a jar to add implementing Log SPI).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le dim. 11 nov. 2018 à 11:48, Rainer Jung <rainer.j...@kippdata.de> a écrit : > Hi Romain, > > Am 11.11.2018 um 11:16 schrieb Romain Manni-Bucau: > > Hi Rainer, > > > > There is an abstract access valve do providing a log impl (like [1]) can > > enable that - plus other standard stuff like pushing on kafka accesses - > > without hardcoding an stdout stream which can not work in docker in some > > setup (where tomcat is launched by another process and redirects only > > configured logs). > > I know, that there's the AbstractAccessLogValve, that's why I wrote "Of > course it also extends our base AbstractAccessLogValve", so I am using > it in the STDOUT variant just like the LoggingAccessLogPattern you > mentioned does. > > Yes, another way would be to have a variant that writes via JULI and let > people configure that (combining with what log framework they like). > That would be more flexible, but also less performant. The reason, that > the AccessLogValve doesn't simply use a log framework for the request > protocol is (I think) only performance. If that is correct and still > relevant, then using a less performing approach for a seemingly simpler > STDOUT output would be surprising. > > Regards, > > Rainer > > > [1] > > > https://github.com/apache/meecrowave/blob/trunk/meecrowave-core/src/main/java/org/apache/meecrowave/tomcat/LoggingAccessLogPattern.java > > > > Le dim. 11 nov. 2018 11:06, Rainer Jung <rainer.j...@kippdata.de> a > écrit : > > > >> Hi all, > >> > >> I don't like it but in managed container environments application > >> instances tend to get configured to write any log output to STDOUT (than > >> everything is caught and redirected to a log concentrator). > >> > >> I could be wrong, but I think there is no appropriate way of doing it > >> with our standard AccessLogValve. I first thought to add a flag but then > >> noticed that the biggest part of the code of AccessLogValve is about > >> file management. Furthermore adding the STDOUT feature to it means we > >> would either produce lots of warnings for attributes that get ignored > >> once the feature is used, or risking that people might not understand > >> what they actually configure when enabling STDOUT but still setting file > >> and directory attributes. > >> > >> I did a little experiment by stripping the existing AccessLogValve down > >> to just use STDOUT but still allow buffer and encoding configuration. I > >> ended up with 220 lines, less than 100 lines with actual code. > >> > >> I would like to add it, but don't know whether there is enough demand > >> for that use case and whether people agree on using a separate class as > >> the right solution. Of course it also extends our base > >> AbstractAccessLogValve. > >> > >> Opinion? > >> > >> Thanks and regards, > >> > >> Rainer >
