Question about the `root.detachAndStopAllAppenders()` call

[Ldoppea]

Hi,

First, thank you for this project, I started using it a few days ago and it makes way easier to get debug data from the app's testers

I'm investigating an incompatibility between react-native-file-logger and react-native-background-geolocation which has its own log mechanism, also based on logback-android

When using both libraries, then the geolocation library stops working

I just found that this is because react-native-file-logger calls root.detachAndStopAllAppenders() during its initialization. Due to this, the react-native-background-geolocation's appenders are cleared and so it cannot do its job anymore

I tried to remove this line locally and it fixes the problem

The question is now: why is this line needed?

The project's history says that it has been added in this specific commit: 5c04853

Because it was not initially there and because it has been added later, my conclusion is that it is here for a specific purpose (i.e. to fix a bug) and so I don't want to remove it without understanding why it was here in the first place

So my two question are:

• Do you remember why it was needed?
• Based on first answer, do you think I should remove this in a local patch? or to make a PR on this repo?

Thanks

[fdrault]

Hello,

Thank you for the detailed issue

Do you remember why it was needed?

I don't have the history, but I think the purpose is re-reading configuration information while keeping only one appender at once. It is needed for dynamic configuration change.

Based on first answer, do you think I should remove this in a local patch? or to make a PR on this repo?

If you call configure() only once, it should works in your configuration, so you can use it in a local patch with that in mind, but you are breaking things in this library, so "remove" the line is not a proper fix

If you want to work on a real solution, any PR is welcome, we are open to contributions 👍

[Ldoppea]

If you want to work on a real solution, any PR is welcome, we are open to contributions 👍

For sure, I would be happy to contribute

It is needed for dynamic configuration change.

Do you mean if the developper want to call configure() multiple times based on some events?

For now I see two potential solutions.

First one would be to add a parameter resetConfig (or something similar) to the configure() method that would allow the dev to tell if they want to do the detachAndStopAllAppenders thing or not. So we can keep the current behavior but allowing to change it for other libs compatibility

Second one would be to find a way to detach only the react-native-file-logger appenders (if they exist). I prefer this one but I don't know yet if this is possible. There is a detachAppender(String name) method that may help. But there is no mention of the stop action that seems to exist in the detachAndStopAllAppenders() one, so I'm not sure yet if this would help.

[fdrault]

Second one would be to find a way to detach only the react-native-file-logger appenders (if they exist). I prefer this one but I don't know yet if this is possible. There is a detachAppender(String name) method that may help. But there is no mention of the stop action that seems to exist in the detachAndStopAllAppenders() one, so I'm not sure yet if this would help.

I tried this idea in the Pull Request #66 .

I have publish the fixed version 0.5.4-rc.1 with tags "next".

@Ldoppea Can you install this version and tell me if it works better with react-native-background-geolocation ?

npm install react-native-file-logger@next

[Ldoppea]

Hi,

Thanks for the time you spent on this 👍

My project is using an old ReactNative version so I'm stuck with v0.4.1 and I cannot test 0.5.4-rc.1

But I did the test by applying the same modification and it works very well 😃

[fdrault]

Hi,

Thanks for the time you spent on this 👍

My project is using an old ReactNative version so I'm stuck with v0.4.1 and I cannot test 0.5.4-rc.1

But I did the test by applying the same modification and it works very well 😃

I see, thanks for reporting this.
Being up-to-date is kinda hard on react-native, but I don't have time to ensure backward compatibilities, still I am glad the patch worked for you 😄

[Ldoppea]

hi @fdrault sorry i would like to reopen this issue,

I just found that the iOS part has a similar bug as it also call removeAllLoggers here

The difference with the android part is that there is no visible exception. In our app, the first logger has enough time to be created, then to logs some lines, and finally it is removed by removeAllLoggers. We didn't realize it because we just checked that the log file was existing with some logs, and so we missed the fact that logs stopped after a few seconds (or milliseconds)

I wanted to make a PR with a fix, but unfortunately, CocoaLumberjack doesn't seems to allow removing a logger by name like logback-android does. The removeLogger methods seems to only take a reference to an existing logger but I did not find any method that take a string as an ID.

The allLogger method may be useful too, but here again I don't see any way to distinguish between the RNFileLogger's loggers and others.

Do you have any idea on how to handle this?