Neutral about this one: haven't seen a case where this was needed, but
don't see anything wrong with it either. One thing I'd recommend if you go
through with it, extract from system properties under "beam." rather than
all of them, to avoid clashes.

On Tue, Feb 13, 2018, 7:53 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote:

> Hi Romain,
>
> it sounds interesting to me, and doesn't break anything, so +1 from my
> side.
>
> Regards
> JB
>
> On 02/13/2018 03:42 PM, Romain Manni-Bucau wrote:
> > Hi guys,
> >
> > there are hacks in beam testing code to read the args from a system
> property but
> > I wonder if we shouldnt add a
> PipelineOptionsFactory.fromSystemProperties().
> >
> > It would iterate over the system properties and take all --xxx=foo as
> potential
> > argument it tries to bind.
> >
> > Rational behind that is to enable users to wrap the pipeline API but
> still
> > expose the pipeline options to end users for advanced cases.
> >
> > Any discussion on this kind of usages already? What do you think of this
> proposal?
> >
> > Side note: we can think about a fromEnv() too.
> >
> > 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
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to