HardySimpson / zlog

A reliable, high-performance, thread safe, flexsible, clear-model, pure C logging library.
Apache License 2.0
2.2k stars 711 forks source link

No config file #51

Open alvarolm opened 10 years ago

alvarolm commented 10 years ago

Is there a way to load the config settings as a static definitions inside the program without depending of the actual config file?

HardySimpson commented 10 years ago

I am thinking the same problem, but can't find a proper api to express it.

meffie commented 10 years ago

Hello,

Thank you HardySimpson for zlog. I agree wih avlarolm, zlog needs a way to be initialized without an external file. In the project I'm currently working on the design is zero-configuration; there are no external configuration files at run time. For applications which do have configuration files, the logging configuration would go into a section of a existing file which is already processed by the application and calls APIs to configure various software components.

As an initial workaround to try to evaluate zlog, I thought about having the application create a temporary file before calling zlog_init(), but this was ugly and error prone.

So, in order to start using zlog, I created a patch to read the configuration from a text string embedded in the application which is passed to zlog at startup. This of course is just a work around for now, but passing the string is useful and easy to do. I added a new initialization function called zlog_init_from_string() for now.

https://github.com/meffie/zlog/commit/65ad202fd8efda61e80dc0113a98c452859a7fd9

It seems much of the zlog initialization code is rather tightly wrapped around the configuration file processing, so making the initialization more flexible would take some thought about how to separate the data from the data source. Perhaps an API that allows the application to build an configuration object then pass it to a zlog initialization API would be useful.

Thank you, Mike

meffie commented 10 years ago

Btw, I've been looking at how zlog parses the configuration text and was surprised at the amount of ad-hoc c code to scan and parse the configuration. Is there a reason a standard scanning and parsing design using lex and yacc (flex/bison) is not used? That would be much more maintainable, flexible, and likely generate faster less error prone code. I would provide an example if that would be helpful.

aisbaa commented 10 years ago

Totally agree meffie comments.

HardySimpson commented 10 years ago

Actually, I think a lot of charm of zlog comes from it's syslog-like configure file. Many people tell me that configure file is hard to maintain. I agree with that. Still I need to say something to support configure file.

In most C program, it is hard to change behavior after you compile it. After modification of source code, you need to re-compile it, copy the executable to the product environment, and restart it. But the ability of change log output and level is always need at runtime. I mean, there is always a need to change how program out-put it's log when it is running in a high speed. That's why most log library need a configure file.

In many dynamic interpret language, it is easy to change it's behavior at runtime. In python, the .py file is it's configure file. Json provides a standard way of how javascript interpret it's data. Lisp, I never use it, but heard that it is can be modified easily at runtime...

The base problem is between data and code. Most compile-language solve the problem by configure file(lightweight), or database(heavyweight).

In zlog's case, I think provide a two layer api maybe help.


It seems much of the zlog initialization code is rather tightly wrapped around the configuration file processing, so making the initialization more flexible would take some thought about how to separate the data from the data source. Perhaps an API that allows the application to build an configuration object then pass it to a zlog initialization API would be useful.


That's right, a 2-layer API will be better, I will try to learn lex and yacc.

HardySimpson commented 10 years ago

Hello guys, I'm back.

I tried design no config api, but has no progess. Show my designs here. Hope get some advise

 zlog_sinit("
    [global]
        default format = \"%m%n\"
    [rules]
        *.*  > aa.log
  ");

this is ugly, put the configure file directly into c source. the second way is

zlog_set("global", "default format = \"%m%n\"");
zlog_set("rules", "*.* > aa.log");

still ugly, but better than the first.

btw, I am redesigning configure syntax now, the sentence of rule is too long *.* -"%12.2E(HOME)/log/%c.log", 1MB * 12 ~ "%E(HOME)/log/%c.%D(%F) #2r #3s.log"; simple but there is no better way, I get something like this, but it it reductant

[*.*]
  file path = -"%12.2E(HOME)/log/%c.log"
  file path = +"%12.2E(HOME)/log/%c.log"
  file permission = 0777
  archive size = 1MB
  archive number = 12
  archive path = "%E(HOME)/log/%c.%D(%F) #2r #3s.log"
  format = "%d %m%n"
aisbaa commented 10 years ago

I would suggest to have separate config structure that holds loggers formatters and appenders. That could be constructed using function calls, e.g.:

zlog_config *cfg = zlog_config_new();
zlog_config_add_logger(cfg, zlog_logger_new(/* ... */));
gaolizhou commented 8 years ago

Hi Guys, is there any update for this issue ?

shibir007 commented 1 year ago

Any further update on this?