Hi Dmitry, thanks for the feedback.
I will comment in-line below.
On 2014-05-16 15:40, Dmitry Samersoff wrote:
Fredrik,
1. I'm not sure we have to provide user-configurable decoration.
It add complication to logger because not all decorations
available for all components and it creates a burden
for customer support because all tools would have
to support different log formats.
Agreed. Any extra information information could easily be added to the
actual log message if needed. This is of course only feasible if the
output is in text format. Examples of user-provided decorations that
people asked for is gc number, and compiler number.
2. Backend might be a better word than adapter.
STDOUT, STDERR and text file is essentially the same backend.
You're right, these three adapters are all file stream adapters. Its
only the stream written to that differs. from a configuration point of
view they are three different targets though. Adapter is used in some
other logging frameworks, I choose that name to have people recognise it.
3. I'm not sure we have to care about log rotation by size, time etc -
everything is done here during last 20 years, and there are lots of
tools that do it.
I think it is very nice to have this simple functionality in the logging
framework, it removes one external tool dependency when setting up
logging. But as you say, it is not strictly necessary.
But, for file backend, we have to provide jcmd command to close
current log and start new one at runtime.
Good idea. I will add this to the JEP somewhere.
4. Proposed VM API is too verbose and require lots of typing.
Also to add new component you have to touch log code, split
or rename components is also problematic.
So it might be better to use
Log::set_component(Log::gc);
Log::warn( format, ... );
Log::error();
Log::trace();
Log::debug()
Log::start();
Log::add( format, ... )
Log::commit(Log::level());
The VM API was just an example in the JEP. There are basically no
loggers defined in the raw implementation. It is up to the developers to
add loggers/categories when there is a need for it. if you want to you
can name them a, b and c :)
I cant really see that verbosity is an issue here. I really hope most of
you are typing fast enough to handle a few more characters. I think the
readability is more important than the number of character in the name.
there are enough abbreviated names in the JVM code as it is now. The
number of lines that are logging are few in comparison with actual code
lines anyway I think.
Split and rename is only an issue if you aren’t using a modern
editor/ide to re-factor stuff (hope I didn’t step on any toes here ;) ).
In my poc implementation you only have to add one line of 'code' to have
a new logger. I used Eclipse when I tried it and it picks up all info to
provide good contextual help on the spot. I would expect Visual Studio
and other tools to work equally well. Very easy to use and simple to manage.
5. I'm not sure that transaction is the best term here.
-Dmitry
Maybe not, Ill try to find a better word for the buffered logging.
Cheers
/Fredrik
