For examples (which I think is auto-propagated to examples archetype), and
I think also manually done for starter archetype:
* Every runner, including DirectRunner, is in a profile: -Pdirect-runner:
https://github.com/apache/beam/blob/master/examples/java/pom.xml#L43
* The slf4j-jdk14 is already
>IMO I don't think the DirectRunner should depend directly on any specific
>logging
backend (at least, not in the compile or runtime scopes). I think it should
depend on JUL in the test scope, so that there are logs when executing
DirectRunner tests.
>My reasoning: I can see in any binary version
Fair enough. +1 especially for the documentation.
Regards
JB
On 04/03/2017 08:48 PM, Aviem Zur wrote:
Upon further inspection there seems to be an issue we may have overlooked:
In cluster mode, some of the runners will have dependencies added directly
to the classpath by the cluster, and since
+1
> On Apr 3, 2017, at 11:48 AM, Aviem Zur wrote:
>
> Upon further inspection there seems to be an issue we may have overlooked:
> In cluster mode, some of the runners will have dependencies added directly
> to the classpath by the cluster, and since SLF4J can only work
Upon further inspection there seems to be an issue we may have overlooked:
In cluster mode, some of the runners will have dependencies added directly
to the classpath by the cluster, and since SLF4J can only work with one
binding, the first one in the classpath will be used.
So while what we
Yes, I think we can exclude log4j from the Flink dependencies. It’s somewhat
annoying that they are there in the first place.
The Flink doc has this to say about the topic:
https://ci.apache.org/projects/flink/flink-docs-release-1.3/monitoring/logging.html
> On 3. Apr 2017, at 17:56, Aviem Zur
>* 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
On Wed, Mar 22, 2017 at 10:38 AM, Tibor Kiss 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
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
+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é
wrote:
> Hi Aviem,
>
> Good point.
>
> I think, in our
10 matches
Mail list logo