jpg0 / ohj

Openhab Javascript Library
Eclipse Public License 2.0
6 stars 2 forks source link

Logger fails due to unknown `log_appenders` module #11

Open simonihmig opened 3 years ago

jpg0 commented 3 years ago

Need to look into whether this actually works with the included GraalJS module loading.

simonihmig commented 3 years ago

So, for you it's working as you seem to have that module in your lib folder: https://github.com/jpg0/oh-config/blob/master/automation/lib/javascript/personal/node_modules/log_appenders.js

I guess that's not installed by npm, and certainly the ohj npm module has no dependency on it, so for me (and any other doing a plain installation of ohj) this is missing, and thus failing. I think you cannot require it, unless you either ship it by yourself or depend on it. Or do I miss something?

jpg0 commented 3 years ago

Sure - I have this file because I want to explicitly define additional log appenders. What is supposed to happen is that if you do not want additional appenders and you won't have this module, then the log module will fail to load it and default to no additional appenders.

(If you have a better way of doing this then I'm happy to hear it!)

simonihmig commented 3 years ago

Usually I would not create the "appender" (or whatever) by myself, instead pass it when creating the logger instance, like with a Dependency Injection system. You can do it with the appenderProvider argument, but I guess your problem was that you wanted it to be used not only for the logger instance you create by yourself, but also for all the other loggers that are created implicitly within ohj?

So first it seems the JS engine here is behaving differently than node, as your code would normally work I think (able to catch the thrown module not found exception)! 🤔

Two approaches come to my mind:

jpg0 commented 3 years ago

Correct, I really want it to be applied to all loggers, within ohj and in consuming code.

I have considered your first option, however in OH, each script is run in it's own instance of the runtime, meaning no shared state (unless explicitly passed via the host), so it would mean calling the static method at the top of every script.

I was not aware of require.resolve - I'll check it out!