Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use application specific configuration keys #37

Open
DavidAntaramian opened this issue Mar 17, 2017 · 6 comments
Open

Use application specific configuration keys #37

DavidAntaramian opened this issue Mar 17, 2017 · 6 comments

Comments

@DavidAntaramian
Copy link

I was responding to a question someone had about this package, and I noticed that you're using the :logger application configuration to hold configuration specific to this package.

You should instead be using your application's own configuration space, in this case :logger_file_backend, e.g.:

config :logger_file_backend, :error_log,
  path: "/var/log/my_app/error.log"
@xurde
Copy link

xurde commented Jul 23, 2017

@DavidAntaramian I think this is due to the fact that LoggerFileBackend is a backend for the Logger module instead of a standalone package which works autonomously.

@DavidAntaramian
Copy link
Author

@xurde That's not the way configuration keys work, though. :logger_file_backend is a distinct OTP application and should source all of its configuration from the :logger_file_backend key in the configuration . :logger is its own OTP application that maintains its own set of configuration keys.

@ngeraedts
Copy link

:logger_file_backend is not a distinct OTP application. It's a backend for the :logger OTP application which spawns multiple processes for each configured backend. It's entirely possible you will end up with a configuration like the following:

config :logger,
  backends: [{LoggerFileBackend, :file_log}, :console]

config :logger, :file_log,
  path: "/var/log/my_otp_app.log",
  level: :info

config :logger, :console, 
  level: warn

@isaacsanders
Copy link

This issue feels closed. @ngeraedts's statement seems to settle things. If this were an application, it might be different, but as it stands, the public API is a module used by the logger application. Unless the logger changes its approach to backends, it doesn't look like there is a case.

@DavidAntaramian
Copy link
Author

@isaacsanders @ngeraedts's statement is fundamentally flawed. :logger_file_backend is a distinct OTP application. There would be no possible way for it not to be a distinct OTP application. This is why there is an :app key and application/0 function in the mix.exs file. That is why a .app file is generated during the build process when the project is compiled. That is how the Erlang runtime system loads the project's compiled modules into the VM.

@isaacsanders
Copy link

@DavidAntaramian Sure. It still feels weird to configure it separately, but that is a different argument.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants