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

Logger reconfigure Handle is inaccessible #390

Open
izolyomi opened this issue Sep 3, 2024 · 1 comment
Open

Logger reconfigure Handle is inaccessible #390

izolyomi opened this issue Sep 3, 2024 · 1 comment

Comments

@izolyomi
Copy link

izolyomi commented Sep 3, 2024

First of all, thank you for this awesome library.

I'm building a small UI app and would like to use log4rs in a multilog context besides another logger, similarly to https://github.com/davechallis/multi_log . My rationale is that while log4rs can nicely handle console and file logging, displaying messages on a UI is fully out of the scope of this crate and it's probably better to use an independent component there.

Creating a Logger instance from a log4rs Root and then Config instance seems to be nicely supported already. On the other hand, a Handle can be created and used to reload the configuration only when directly setting log4rs as the single global logger instance e.g. using init_config. I'd expect that a Logger has a get_handle(&self) -> Handle or similar function to support config reloads without init_...() functions.

Was it a deliberate choice to prevent this workflow or am I discovering a possible scenario that simply wasn't thought of yet?

@izolyomi izolyomi changed the title Logger reload Handle is inaccessible Logger reconfigure Handle is inaccessible Sep 5, 2024
@bconn98
Copy link
Collaborator

bconn98 commented Sep 8, 2024

My guess, is that this scenario was not considered when the library was originally created. That said, I see a couple options.

  1. Introduce an appender that writes to a socket or similar, such that your UI can capture and display the logs. This option may be better as you can keep consistent logs across all locations and only need 1 configuration/dependency.
  2. Introduce the Handle as you've described above. I don't immediately see an issue with providing the handle like you're requesting. Feel free to put a PR out and we'll try and get it in. We have had a bit of trouble getting PRs in of late but hopefully can get them rolling again.

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

2 participants