[ 
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-8570:
-------------------------------------
    Description: 
_+Problem with current GridStringLogger implementation+_: 
 Most usages of {{GridStringLogger}} in test assumes the following scenario. 
First, it is set as a logger for some Ignite node. 
 Then, after some activity on that node, log content is searched for some 
predefined strings. 
 {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to 
store log contents, older contents gets dropped on exaustion. 
 Thus, changes that add more logging may damage some independent tests that use 
{{GridStringLogger}}.

 

+_The suggestion for new implementation:_+
 The suggestion is to implement and use another test logger conforming to these 
requirements:
 * It does not accumulate any logs(actually, it will print no logs to anywhere)
 * It allows to set the listener that fires when log message matches certain 
regular expression,

_+Proposed design+_, pseudocode:

```
 public class ListeningTestLogger implements IgniteLogger {
 …
    public void registerListener(Consumer<String> lsnr);

    public void unregisterListener(Consumer<String> lsnr);
    
    public void clearListeners();
…
 }
 ```
In 99.9% cases we at some point we should validate listener precondition. For 
example, default precondition for {{substring listener}} - "_does log have any 
messages containing such substring?_". So, listener should support validation. 

```
interface LogListener extends Consumer<String> {
    void check() throws AssertionError;
}
```

To simplify creation of common case listeners (substring, regular expression 
and predicate) should be introduced special listener builder.

+_Sample logger usage_+:

```
ListeningTestLogger log = new ListeningTestLogger(false, super.log);
// Create listener that should match "hello" (2 times) and "Ignite" (case 
insensitive, at least one time)
LogListener lsnr = 
LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
log.registerListener(lsnr);
...
lsnr.check();
```

  was:
_+Problem with current GridStringLogger implementation+_: 
 Most usages of {{GridStringLogger}} in test assumes the following scenario. 
First, it is set as a logger for some Ignite node. 
 Then, after some activity on that node, log content is searched for some 
predefined strings. 
 {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to 
store log contents, older contents gets dropped on exaustion. 
 Thus, changes that add more logging may damage some independent tests that use 
{{GridStringLogger}}.

 

+_The suggestion for new implementation:_+
 The suggestion is to implement and use another test logger conforming to these 
requirements:
 * It does not accumulate any logs(actually, it will print no logs to anywhere)
 * It allows to set the listener that fires when log message matches certain 
regular expression, {{Matcher}} can be passed to the listener

 

_+Proposed design+_, pseudocode:

```
 Class GridRegexpLogger implements IgniteLogger{
 …
 debug(String str){
 if (/* str matches pattern. */)
   \{ /* notify listeners. */ }
}
 …
 listen("regexp", IgniteInClosure<String> loggerListener)// listener receives 
message
{ /* registers listener. */ }

listenDebug("regexp", loggerListener)
{ /* registers listener for debug output only. */ }

…
 }
 ```

+_Sample regexp logger usage_+:

```
 GridRegexpLogger logger;

logger.listen(“regexp”, new GridRegexpListener());
logger.listenDebug("regexp", new GridRegexpListener());
 ```


> Create lighter version of GridStringLogger
> ------------------------------------------
>
>                 Key: IGNITE-8570
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8570
>             Project: Ignite
>          Issue Type: Improvement
>    Affects Versions: 2.4
>            Reporter: Andrey Kuznetsov
>            Assignee: Pavel Pereslegin
>            Priority: Major
>             Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_: 
>  Most usages of {{GridStringLogger}} in test assumes the following scenario. 
> First, it is set as a logger for some Ignite node. 
>  Then, after some activity on that node, log content is searched for some 
> predefined strings. 
>  {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to 
> store log contents, older contents gets dropped on exaustion. 
>  Thus, changes that add more logging may damage some independent tests that 
> use {{GridStringLogger}}.
>  
> +_The suggestion for new implementation:_+
>  The suggestion is to implement and use another test logger conforming to 
> these requirements:
>  * It does not accumulate any logs(actually, it will print no logs to 
> anywhere)
>  * It allows to set the listener that fires when log message matches certain 
> regular expression,
> _+Proposed design+_, pseudocode:
> ```
>  public class ListeningTestLogger implements IgniteLogger {
>  …
>     public void registerListener(Consumer<String> lsnr);
>     public void unregisterListener(Consumer<String> lsnr);
>     
>     public void clearListeners();
> …
>  }
>  ```
> In 99.9% cases we at some point we should validate listener precondition. For 
> example, default precondition for {{substring listener}} - "_does log have 
> any messages containing such substring?_". So, listener should support 
> validation. 
> ```
> interface LogListener extends Consumer<String> {
>     void check() throws AssertionError;
> }
> ```
> To simplify creation of common case listeners (substring, regular expression 
> and predicate) should be introduced special listener builder.
> +_Sample logger usage_+:
> ```
> ListeningTestLogger log = new ListeningTestLogger(false, super.log);
> // Create listener that should match "hello" (2 times) and "Ignite" (case 
> insensitive, at least one time)
> LogListener lsnr = 
> LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
> log.registerListener(lsnr);
> ...
> lsnr.check();
> ```



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to