Thorbjoern Ravn Andersen wrote:
If I understand you correctly you basically say there is a need for a standardized set of event data.
Yes.
After thinking this over it might be better to have code generating the events instead of them being stored statically on disk. This is to avoid setting any API in stone except the slf4j interface which by now should be settled.
The generator might have some logback dependencies, we are talking about logback logging events after all.
(What if the internal representation of a stack trace is changed or similar? Just happened, might happen again :) )
If we assume that the corpus is generated, then we don't need to worry about the internal representation of logging event changing. The generator will take care of adapting to the new format. The generator might have some logback dependencies, we are talking about logback logging events after all. It is likely that the corpus will need to be present in memory, so it should not be huge as to exceed the heap size of the JVM. A sample size of approximately 100'000 is imho sufficient. We would then measure the time it takes to encode and then decode the corpus and storage size of the encoded results. I assume that the generator will be based on pseudo-random number generators. We would need to settle on several parameters such as message length, the number of messages with parameters, the frequency of exceptions, etc. There is no test suite as such. There is just a standard set of logging events called the corpus that various encoding strategies are benchmarked against. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch