On 11/11/2018 10:48, Rainer Jung wrote: > 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).
This is why I created the Verbatim Formatter. This past discussion looks to be relevant here: https://tomcat.markmail.org/thread/7ve6awm6inud54l3 > 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. There are performance numbers in the thread above. My reading of that thread is that the initial figures weren't encouraging but that further refinement of the code and/or logging configuration may be able to address that. Mark > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
