Teach Platform to load via ServiceLoader

[cslee00]

Allows back-ends to be loaded by dropping in JARs supporting ServiceLoader semantics. Preserves existing behaviour of only allowing a single Platform to be provided

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[cslee00]

Signed CLA

[googlebot]

CLAs look good, thanks!

[ronshapiro]

I'm not sure that ServiceLoader is what we'd want, because it can have bad performance in certain environments. Perhaps a command line flag to the JVM might serve the same goal without any performance considerations?

/cc @hagbard

[ronshapiro]

Ah I just saw that @hagbard has an internal PR too have this configurable via system property.

[cslee00]

Thanks for the prompt response. Use case is separating the use of the API from the implementation; goal would be to create ‘libA’ that uses flogger API and use the same binary in different contexts with potentially different logging back ends. Current logging APIs (eg slf4j) allow for dropping in different JARs to support this. System property would work, though it isn’t as transparent as ServiceLoader (or other ‘discoverable’ solns) and maybe limiting in some use cases (inability to set system props in managed environment, for example). Chris.

…

On Apr 22, 2018, at 4:26 PM, Ron Shapiro ***@***.***> wrote: Ah I just saw that @hagbard has an internal PR too have this configurable via system property. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Marcono1234]

Could it please be reconsidered to add support for ServiceLoader as well?
The logic could be:

• If System property is set, use that class
• Otherwise try ServiceLoader
• Otherwise fall back to default

The problems @cslee00 listed are still the case, especially:

maybe limiting in some use cases (inability to set system props in managed environment, for example).

Similarly when a project using Flogger is used as dependency by other projects (with a different logging implementation), for each of them the System property needs to be set, which is rather error-prone (and not always possible). When using ServiceLoader, the project using Flogger can simply add the logging bridge (e.g. Flogger to Log4j 2) and dependent projects won't have to do any special logging configuration (assuming they use the same logging framework).