feat(#973): Allow deactivation of standard LoggingReporter

[tschlat]

I came up with a solution that enables the complete disablement of the LoggingReporter's functionality. Considering that both the HtmlReporter and JUnitReporter already offer similar disablement options, I believe this solution adequately addresses the requirements.

[bbortt]

is there a possibility to completly supress the underlying logger? because you'd have to add an immediate return to every method - also info and error etc. that seems a bit much to me....

[bbortt]

or we do say that in the case of a direct invocation it might be wanted and we do knowingly not suppress it. but that clashes with the current implementation of the debug method.

[bbortt]

maybe this https://www.slf4j.org/api/org/slf4j/helpers/NOPLogger.html can help?

[tschlat]

is there a possibility to completly supress the underlying logger? because you'd have to add an immediate return to every method - also info and error etc. that seems a bit much to me....

Please see the javadoc of the class.

[tschlat]

maybe this https://www.slf4j.org/api/org/slf4j/helpers/NOPLogger.html can help?

Gratefully accepted.

[christophd]

hey folks, thanks for the contribution!

I think it would also be nice to enable/disable the reporter via env var settings like HTMLReporter is doing (see HtmlReporter)

Also in general for all reporters it would be good to find a way to completely remove the reporter from the list of reporters once disabled. So we do not even initialize the reporter and send log events to it once disabled.

Reporters are initialized in DefaultTestReporters. So we should make this configurable and enable/disable reporters here in order to not even initialize the disabled ones.

For Spring configuration we can use

@ConditionalOnProperty(
  value="citrus.default.logging.enabled", 
  havingValue = "true", 
  matchIfMissing = true)

on the reporter bean to not even initialize the bean based on the env var settings.

I think I will open a separate enhancement issue for this feature.

[tschlat]

I implemented it like this, running into the problem, that the LogginReporter also serves as Logger for Inbound/Outbound messages.

You may want to have a look at this:
main...issue/973/standard-reporter-override-TS

The point is, that the default reporters which are registered only if required, are not available as beans and are thus not autowired properly. Especially with respect to the additional interfaces, the LoggingReporter is implementing.
I then dropped this approach.

I also already checked @ConditionalOnProperty. It would require the following dependency to be added to Citrus:

<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-autoconfigure</artifactId>
</dependency> 

If we want to avoid it, I could add respective conditions and use @conditional.

I'd be pleased to provide an MR for the conditional approach if you could shortly comment on the depencency question.