Repository navigation
Use a logging framework such as as SLF4J instead of System.out.println #670
Description
Expected Behavior
the library logs stuff using SLF4J and the application controls the actual output. this will allow logging stuff like logger and thread names, etc. the library uses different log levels (trace, debug, error) for different things and it's easy to filter them out, if needed. as the output is controlled by the application, no stuff like if (WebSocketImpl.DEBUG) is needed.
also, it would be nice to have a proguard rule file that would remove the logging messages from the code.
Current Behavior
the library prints its debug messages to stdout in a pretty raw form. all messages, accordingly, are of the same “level” and are inconsistent with the other messages that the application prints
Possible Solution
use SLF4J
Reacted by Dennis Neufeld
Reacted by Björn and Walker Knapp
Activity
marci4 commentedon Feb 25, 2018
Hello @oakkitten,
thank you very much for this improvement!
Do you think it is possible make this somehow happen without f**king everyone up right now, especially users who do not use a build system like maven or gradle?
Or do I have to provide a separate download then?
I have no knowledge on how to write such a rule so could you maybe help me do this?
Thank you!
Greetings
marci4
WalkerKnapp commentedon Mar 5, 2018
Hi @marci4,
I'm not the original one to post the issue, but I think the best way to go about addressing the first issue would be to distribute a Fat Jar (Not the most technical of terms, sorry) for those who don't use a build system and to have a fallback logger with System.out (Depending on WebSocketImpl.DEBUG, like currently) if they don't provide a slf4j compliant library. Are there any issues with a system like this?
I really hope this issue is implemented eventually as it is a really nice feature to have slf4j logging. Thanks!
marci4 commentedon Mar 5, 2018
Hello @WalkerKnapp,
thank you for your feedback!
I quess I have to do it this way and maintain 2 versions.
One maven version and one standalone version.
Will only do this to the next major release 1.4.
BTW input is always welcome!!! That what github is build on! :)
Greetings
marci4
marci4 commentedon Mar 6, 2018
Hello everyone,
You can see the current development status for this in this branch (https://github.com/marci4/Java-WebSocket-Dev/tree/slf4j).
Would like to get some feedback on this please!
Greetings
marci4
WalkerKnapp commentedon Mar 7, 2018
Looks great in my opinion. Although, there were still some printlns dotted around, so I commented on those in the commit. Other than that, looks perfect and I hope to see it in the next major release.
ItsHarper commentedon Aug 10, 2018
Any update on this?
marci4 commentedon Aug 13, 2018
@noahAndrews 1.4 is planned as the next release. No ETA since there is a lot to do...
neoedmund commentedon Mar 13, 2019
An unconstructive dissent here.
Why not just use java.util.logging.Logger? add 48 classes and 123KB just for a logger? what makes bloatware.
PhilipRoman commentedon Mar 13, 2019
At this point SLF4J is basically an industry standard (and for a good reason). With java.util.logging you lose a lot of flexibility.
SLF4J API jar is 40kb and it's java.util.logging implementation is only 8kb.
neoedmund commentedon Mar 14, 2019
SLF4J maybe popular, but there is no such thing that SLF4J is an industry standard.
And there is also a reason for a library like Java-WebSocket not use any specified logging library, at least because logging is not playing as a must part, it should be totally disabled when it's out of development into a stable release(Java don't have proprocessor like C, or can be easily done).
About the size, in
Java-WebSocket-1.4.0-with-dependencies.jarorg.java_websocket79 items, 268KBorg.slf4j48 items, 123KBdozens of lines of logging functions taking up 1/3 of the code size!
Bloatware pollution, at the point of software engineering.