RegexUtil.group(String, CharSequence) 方法 可以使用LOGGER.trace 替代 LOGGER.debug about feilong-core

[venusdrogon]

    public static Map<Integer, String> group(String regexPattern,CharSequence input){
        Matcher matcher = getMatcher(regexPattern, input);
        if (!matcher.matches()){
            LOGGER.debug("[not matches] ,\n\tregexPattern:[{}] \n\tinput:[{}]", regexPattern, input);
            return Collections.emptyMap();
        }
        int groupCount = matcher.groupCount();
        Map<Integer, String> map = MapUtil.newLinkedHashMap(groupCount + 1);
        for (int i = 0; i <= groupCount; ++i){
            //匹配的索引
            String groupValue = matcher.group(i); //map.put(0, matcher.group());// 捕获组是从 1 开始从左到右的索引.组0表示整个模式,因此表达式 m.group(0) 等效于 m.group().
            LOGGER.trace("matcher group[{}],start-end:[{}-{}],groupValue:[{}]", i, matcher.start(i), matcher.end(i), groupValue);
            map.put(i, groupValue);//groupValue
        }

        if (LOGGER.isTraceEnabled()){
            LOGGER.trace("regexPattern:[{}],input:[{}],groupMap:{}", regexPattern, input, JsonUtil.format(map));
        }
        return map;
    }

change

[venusdrogon]

但是 依照 http://programmers.stackexchange.com/questions/279690/why-does-the-trace-level-exist-and-when-should-i-use-it-rather-than-debug#answer-291143

所言

What would be a canonical example of logging at the TRACE level?

看样子 TRACE 只是 ENTRY/EXIT logs from a method

ENTRY/EXIT logs from a method. These logs help you trace the flow of the program and tend to be very useful when:

The program abruptly crashes - you know exactly which function it crashed in by looking at the last line of the log
Some rogue function silently fails by absorbing an exception
They warrant a separate TRACE level rather than just using DEBUG because enabling ENTRY/EXIT logs for every method in your code base is going to generate a tremendous amount of extra logs that are unreasonable to be always on, even in a DEBUG context.

[venusdrogon]

What are example of information that should be logged with TRACE and not with DEBUG?

Telastyn's excellent answer 他的回答 比较受到大家的同意

If I have an algorithm that goes through a bunch of steps, trace level will print info about each of those steps at the finest level. Things like the literal inputs and outputs of every step.

In general, trace will include all debug (just like debug includes all warnings and errors).

[venusdrogon]

The org.apache.log4j.Level.TRACE level was added to log4j in the version 1.2.12

see org.apache.log4j.Level, ALL=TRACE=DEBUG syslogEquivalent is 7

http://stackoverflow.com/questions/19678324/trace-log-level#answer-19683073

[venusdrogon]

http://slf4j.org/faq.html#trace 这里的说明比较权威

The addition of the TRACE level has been frequently and hotly debated request. By studying various projects, we observed that the TRACE level was used to disable logging output from certain classes without needing to configure logging for those classes. Indeed, the TRACE level is by default disabled in log4j and logback as well most other logging systems. The same result can be achieved by adding the appropriate directives in configuration files.

Thus, in many of cases the TRACE level carried the same semantic meaning as DEBUG. In such cases, the TRACE level merely saves a few configuration directives. In other, more interesting occasions, where TRACE carries a different meaning than DEBUG, Marker objects can be put to use to convey the desired meaning. However, if you can't be bothered with markers and wish to use a logging level lower than DEBUG, the TRACE level can get the job done.

Note that while the cost of evaluating a disabled log request is in the order of a few nanoseconds, the use of the TRACE level (or any other level for that matter) is discouraged in tight loops where the log request might be evaluated millions of times. If the log request is enabled, then it will overwhelm the target destination with massive output. If the request is disabled, it will waste resources.
In short, although we still discourage the use of the TRACE level because alternatives exist or because in many cases log requests of level TRACE are wasteful, given that people kept asking for it, we decided to bow to popular demand.

[venusdrogon]

Pros and cons for adding a Trace level

这里的介绍不错

Possible interpretations:

1. The above quotes establish that TRACE is a synonym for DEBUG, or even a better word in the context of logging.
2. TRACE is very verbose: it is a "line drawn by a recording instrument", "a mark left by anything passing" , "a footprint". It details every single move of the system. -endre

"Tracing" an application is usually referring to "step-locking" through code, that is, seeing every single change to every single register in the processor, for every operation. For unixers, "strace" and "ltrace" are the tools by which -all- system calls / library calls are "traced". The "trace" word hence, in my opinion, have an established meaning as something -extremely- verbose: it -traces- the applications every single step.

Debug information, on the other hand, is more for being able to debug the application as a whole (and this is, of course, a very overlapping area!). You'd like to see when the application asks the dbpool for an connection (maybe? - the 40 steps required within the dbpool to fetch this connection are at least definitely trace-level outputs), you'd like to see that the user made some "semantic action", e.g. "loaded customer data". This is more "contextual" information, e.g. "the user such and so made the this and that action", and, implicitly, if you'd turn on trace, you'd see -which- small, single-steps that have been done to accomplish this action.

[venusdrogon]

4ee28ca

已经提交了代码

[venusdrogon]

4ee28ca