convex
convex copied to clipboard
Convex-Dev
SLF4J Issue in Kali-linux
After building the Convex JAR by Skipping tests, I got this SLF4J error messages when launching the Peer.
./convex local start2 SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Environment Java 15.0.2 Maven 3.6.3
I was having this issue as well when consuming core libraries from my Clojure stuff. Those are just harmless warnings. I simply suppressed them using a Clojure library. It can be configured from Java.
This is an expected warning if there isn't a logging library configured. Need to work with @billbsing to figure out what the CLI should do as a default. It is possible people may want to configure their own logging?
I don't think users will expect the ability to configure logging (by providing a jar?). Usually with a CLI app you get what you get.
I have submitted a PR #234 , with the CLI to use logback as the logging output library. This allows the CLI to determine the log level that it can show during runtime.
This would mean that the complete Convex suite will have logback as a dependency.
So maybe we should start to split up the Convex, into separate java packages or repos? , for CLI, GUI and Core Convex.
This is an expected warning if there isn't a logging library configured. Need to work with @billbsing to figure out what the CLI should do as a default. It is possible people may want to configure their own logging?
I don't recall to have configured it my "own logging" when testing/running smart contracts in ETH. The whole logging experience was embedded in the CLI (Ganache Tool). I do remember we have the possibility to set up some config parameters in the Json files to specify which network to connect to, ports, private keys, service to access, etc
I would rather prefer Devs have a basic and generic logging mechanism that work, rather than assuming that they will do a full customisation on their preferred logging mechanism (which could added/included in our next updates)
Splitting up the repos sound complex, but if you think it is even simple and that way will solve the problem for the short and mid-term. It is worth to consider that option as well.
We've now separated the CLI into a different module (on develop) so it should be possible to set up better logging with CLI use cases in mind