@Rainer: if it helps you can test with this file handler: https://github.com/apache/tomee/blob/master/tomee/tomee-juli/src/main/java/org/apache/tomee/jul/handler/rotating/LocalFileHandler.java
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 lun. 12 nov. 2018 à 10:51, Rainer Jung <rainer.j...@kippdata.de> a écrit : > Hi Mark, > > Am 12.11.2018 um 10:40 schrieb Mark Thomas: > > 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. > > Thanks for the discussion pointer actually going back to 2012! > > I will do some experiments along the lines of JULI to get current > numbers on overhead (mostly CPU and latency but probably also memory) > using our current default solution versus using JULI with > java.util.logging versus using JULI with something like Log4J2. And also > probably checking the log framework cases with simple file based logging > and with STDOUT logging. > > I'll come back here, when I have some numbers. > > 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 > >
