Optilog-Client
This is an open source logging framework written in Java language. It has more advantages than other open source logging frameworks (such as log4j and slf4j).
The wiki of Optilog will be updated at any time. Problems or bugs will be raised on issues or discussions.
Be sure to read the wiki of this project before using it.
If you like, you are welcome to contribute to Optilog through fork. The code of this project is quite basic, and anyone can contribute.
Optilog advantages
0.Frequent updates(log4j and slf4j have no update since 2017..)
high performance: After initialization, another log (output to the screen + output to a file + output to the server through socket) can be output as fast as 8 milliseconds (it will be optimized later). Log4j should be at least 41 milliseconds.
Placeholder convenience: optilog supports unlimited placeholders and can be reused (#1 #1 outputs the first placeholder twice). Log4j only supports 9 placeholders.
Configuration file can be placed in any location. The name of the configuration file is unlimited. Two types of configuration files are supported. In log4j, the configuration file can only be in classpath and the name can only be log4j2 xml.
Support the client to send logs to Server.
All possible exceptions in Optilog are basically captured without affecting the main logic.
You only need one jar package, and you can use it directly by typing in the classpath (I don't know the feeling of adding dozens of jar packages at once when using gradle).
Suitable for beginners without complex configuration files.
Few dependence.
Class, method and other information output in the log are absolutely accurate, because Optilog uses StackTraceElement internally to determine these information, and there is no need to write the class instance when initializing the log.
Optilog can directly generate a default configuration file. Beginners do not need to look for the configuration file example (Tutorial).
Support configuration files in multiple formats, including JSON, yaml, XML and properties. Support for .toml configuration files will be added later.
Optilog supports configuration modification during runtime. Of course, only some configuration items of true and false can be modified. Output file paths cannot be modified.
Support outputting logs to JDBC.
Optilog log picture:
Generate by carbon.now.sh
Dependency:
com.google.code.gson:gson:2.9.0
\
com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.13.3
\
org.yaml:snakeyaml:1.30 mysql:mysql-connector-java:8.0.29
\
mysql:mysql-connector-java:8.0.29
\
(You needn't add dependency if you don't use these function.)
Contributor:
JavauserO
Future plans
realize remote call
Top comments (14)
Oh no! ... Please not yet another logging framework for Java! One of the most widespread issue with Java is that multiple Logging frameworks coexist and the community is fragmented, leading to all kind of complications. I guess this additional library would add one more brick to this disaster. Sorry.
I'm sure your talent could be spent on more useful things.
You're right. I didn't think about this before.But I want to ask what exactly does complications mean?
One must be aware that the logging is not only done by your own code, but also by all the third party libraries used. Everyone logs stuff, using different logging frameworks, and yet you need your logging configuration to apply to all of them. If I change my logging level from WARN to DEBUG, I want all libs to pick it up, and not have one dependency ignore it because it uses a separate logging which requires its own distinct config.
I understand what you mean.If a dependency use logging framework A,but my project use logging framework B.If I want to apply my configuration to all dependency and my project,I have to create many configure files for all logging framework.
Thanks.
As long as only the SLF4J API is used in the Java code, there will be no such problems
I think it's not a big problem as long as the specification of SLF4J is implemented
I have an immature idea.
I think the most big question is configuration, i can let Optilog control other logging framework's configuration.When you write Optilog's config file,Optilog auto generate configure file that other logging framework need(in runtime),that config is same as Optilog's configure file.If you change configure file,Optilog will change the configure file for other logging framework.
Maybe this idea is unrealistic...
Instead of making your logging library, I would ask two questions:
First,because I want to make a better logging framework,that doesn't mean I think they are too bad.They have some problems.
problem example:
public class Test {public static Logger log = LoggerFactory.getLogger(Test.class);
public static void main(String[] args) {
log.info("test in Test");
test2.t(log);
}
}
class test2 {
public static void t(Logger logger) {
logger.info("test in test2");
}
}
console:
[main] INFO com.test.Test - test in Test[main] INFO com.test.Test - test in test2
Why second log in class test2 print class:com.test.Test?
I once want to contribute these logging framework.But if you see their pull request,you will know they will not access you.
github.com/qos-ch/slf4j/pulls
github.com/apache/logging-log4j2/p...
It's not that we don't need to innovate when we have it on the market. Sometimes the existing framework can't meet our needs.
Brother, support you, you can also add Chinese descriptions in the project about, so that Chinese brothers can also search for it
Thanks.There is Chinese description on my github.
github.com/OptiJava/Optilog-Client
No, I mean project about, it's where the GitHub search engine takes into account, like github.com/alibaba/GraphScope
I see.It's a good idea.