>* java.util.logging could be a good choice for the Direct Runner Yes, this will be great for users (Instead of having no logging when using direct runner).
>* Logging backend could be runner-specific, particularly if it needs to >integrate into some other experience Good point, let's take a look at the current state of runners: Direct runner - will use JUL as suggested. Dataflow runner - looks like there is already no binding (There is a binding in tests only). Spark runner - currently uses slf4j-log4j12. does not require any specific logger, we can change this to no binding. Flink runner - uses slf4j-log4j12 transitively from Flink dependencies. I'm assuming this is not a must and we can default to no binding here. @aljoscha please confirm. Apex runner - uses slf4j-log4j12 transitively from Apex dependencies. I'm assuming this is not a must and we can default to no binding here. @thw please confirm. It might be a good idea to use a consistent binding in tests (Since we'll use JUL for direct runner, let this be JUL). On Wed, Mar 29, 2017 at 7:23 PM Davor Bonaci <da...@apache.org> wrote: +1 on consistency across Beam modules on the logging facade +1 on enforcing consistency +1 on clearly documenting how to do logging Mixed feelings: * Logging backend could be runner-specific, particularly if it needs to integrate into some other experience * java.util.logging could be a good choice for the Direct Runner On Tue, Mar 28, 2017 at 6:50 PM, Ahmet Altay <al...@google.com.invalid> wrote: > On Wed, Mar 22, 2017 at 10:38 AM, Tibor Kiss <tk...@hortonworks.com> > wrote: > > > This is a great idea! > > > > I believe Python-SDK's logging could also be enhanced (a bit > differently): > > Currently we are not instantiating the logger, just using the class what > > logging package provides. > > Shortcoming of this approach is that the user cannot set the log level on > > a per module basis as all log messages > > end up in the root level. > > > > +1 to this. Python SDK needs to expands its logging capabilities. Filed [1] > for this. > > Ahmet > > [1] https://issues.apache.org/jira/browse/BEAM-1825 > > > > > > On 3/22/17, 5:46 AM, "Aviem Zur" <aviem...@gmail.com> wrote: > > > > +1 to what JB said. > > > > Will just have to be documented well as if we provide no binding > there > > will > > be no logging out of the box unless the user adds a binding. > > > > On Wed, Mar 22, 2017 at 6:24 AM Jean-Baptiste Onofré < > j...@nanthrax.net> > > wrote: > > > > > Hi Aviem, > > > > > > Good point. > > > > > > I think, in our dependencies set, we should just depend to > slf4j-api > > and > > > let the > > > user provides the binding he wants (slf4j-log4j12, slf4j-simple, > > whatever). > > > > > > We define a binding only with test scope in our modules. > > > > > > Regards > > > JB > > > > > > On 03/22/2017 04:58 AM, Aviem Zur wrote: > > > > Hi all, > > > > > > > > There have been a few reports lately (On JIRA [1] and on Slack) > > from > > > users > > > > regarding inconsistent loggers used across Beam's modules. > > > > > > > > While we use SLF4J, different modules use a different logger > > behind it > > > > (JUL, log4j, etc) > > > > So when people add a log4j.properties file to their classpath for > > > instance, > > > > they expect this to affect all of their dependencies on Beam > > modules, but > > > > it doesn’t and they miss out on some logs they thought they would > > see. > > > > > > > > I think we should strive for consistency in which logger is used > > behind > > > > SLF4J, and try to enforce this in our modules. > > > > I for one think it should be slf4j-log4j. However, if performance > > of > > > > logging is critical we might want to consider logback. > > > > > > > > Note: SLF4J will still be the facade for logging across the > > project. The > > > > only change would be the logger SLF4J delegates to. > > > > > > > > Once we have something like this it would also be useful to add > > > > documentation on logging in Beam to the website. > > > > > > > > [1] https://issues.apache.org/jira/browse/BEAM-1757 > > > > > > > > > > -- > > > Jean-Baptiste Onofré > > > jbono...@apache.org > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > > > > > > >
