Allow to configure a custom logging backend

[marcmo]

It's currently not possible to configure a custom logging backend. What is needed is a way to use a custom logger along with some guidance of where to initialize it (since we do not have a main where this is done for applications.

[nicholastmosher]

Thanks for the submission @marcmo! I'm going to write down some notes and observations here :)

Right now it seems that module "initialization" is somewhat static. We can see that the logging implementation is registered here in init_module, which has the #[ctor] attribute. I believe that this causes the init_module code to be loaded at least before any other module code, my guess is that it happens when the dynamic loader loads the shared object file.

Probably something we can think about doing is adding some sort of hook where module authors can define their own initialization function and init_module can call out to it. From a user-interface perspective, it would probably be possible to create an attribute such as #[node_bindgen(init)] that can be used to indicate that a particular function should be used for initialization.

#[node_bindgen(init)]
fn init_my_module() {
    // Logging init or other global setup
}

Implementation-wise, I'm imagining that we could probably use some sort of static that holds a reference to a Fn() -> () (or whatever we decide the init function signature should be) which is initialized to some empty or default init function (perhaps controlled by a feature flag), and can be overridden if a #[node_bindgen(init)] attribute is defined.

[marcmo]

Hi @nicholastmosher, thanks for laying out your thoughts on this.
After reading about the ctor library and how it works, it seems dangerous to expose a hook so that your users can add any function.
OTOH if the initialization code fails, it will fail at startup and thus should be easy to debug.
As for how to implement a static that holds a reference to a function...I tried but failed... don't know how to implement that!
would be a nice way to enable replacing the default-logger initialization that way

[nicholastmosher]

I think when I suggested that solution, I was looking at some code from tracing as inspiration: https://github.com/tokio-rs/tracing/blob/master/tracing-core/src/dispatch.rs#L197-L202

They have a static GLOBAL_DISPATCH, where "dispatch" seems to refer to a reference to a particular "Collector", which is their interface for receiving log events. I will need to come back and read that more thoroughly, but I wanted to post it in case it can help you think through what an implementation here might look like

[Badel2]

Hi, I also would like to setup a custom logger. The problem is that the log library has no way to "unset" a logger, so we are stuck with the logger from here. I like the solution to add a #[node_bindgen(init)] attribute, but in my case I need to pass some extra arguments to that function so I would use it like this:

#[node_bindgen(init)]
pub fn no_init() {
    // Disable default logger
}

pub fn manual_init(args: Value) {
    // Setup logger manually, using options from args
}

And then just call manual_init manually from my code. So if this init attribute is hard to implement, some config option to disable the default logger would be enough for me.

[sehz]

Thanks for suggestion. Will try to address this issue soon.

[sehz]

@Badel2 What option do you need for init? It's hard to pass argument. It would be simpler if pick up form env variable.

If we go with init attribute. then it just matter of copy/paste function in the init_module

[Badel2]

Actually I need to pass a function, like this:

let rust_addon = require("../../rust-dist");
rust_addon.manual_init(function(msg) {
    console.log(msg);
});

I tried to get a reference to console.log using JsEnv, but that didn't work.

Another possibility is to allow using RUST_LOG=off to disable the default logger, you would need to modify this function:

node-bindgen/nj-core/src/lib.rs

Lines 124 to 126 in 6450525

	pub fn init_logger() {
	fluvio_future::subscriber::init_logger();
	}

Into something like

if std::env("RUST_LOG") == "off" {
    // Do not initialize logger here, to allow user to set a custom logger
} else {
    fluvio_future::subscriber::init_logger(); 
}

[sehz]

Thanks to @marcmo, this issue is resolved. Should do release? I think only minor bump version is necessary