[SUREFIRE-1926] Console logs should be synchronized

[Tibor17]

The point is to get logger operations in semi-sequential order across multiple threads.
The messages will not be mixed up, especially out and err.
PluginConsoleLogger is synchronized. This instance is only one and it is passed to DefaultReporterFactory and TestSetRunListener as a monitor object.

[Tibor17]

@slawekjaranowski
Pls finish this review and I would like to close the Jira ticket.

[slawekjaranowski]

why not

startupReportConfiguration.getReportsDirectory();

than we can remove this method from ReportsMerger interface.

[Tibor17]

Because there must be abstraction. There are two DefaultReporterFactory instances. One is per fork, and another is the "merger".
We simply cannot allow ForkStarter or the developer who is not aware of Surefire insides to call other methods than the "merger" can expose.
Now, the answer for the following questions why this interface ReportsMerger exists in here is the fact that I implement the method writeTestOutput(). Of course I cannot allow the "merger" to call this method by any reason even if by mistake. So the ReportsMerger becomes a subinterface with limitted access excluding writeTestOutput() to prevent from calling it, to prevent from calling new implementation of this method, so that it will be called only in ForkClient and not in ForkStarter.

[slawekjaranowski]

reportMerger and startupReportConfiguration are final variable
startupReportConfiguration is pass to reportMerger constructor ...
CloseableCloser is inner class which use variable from ForkStarter instance

is it possible that we have different instance of startupReportConfiguration?

[slawekjaranowski]

maybe I don't see something ...

[slawekjaranowski]

next responsibility for this class - maybe will be possible create separate class

[slawekjaranowski]

Name of method is not corresponding to what is doing ... inside close method - there are calling

• mergeTestHistoryResult
• runCompleted
• and close on all listerneres colected in mergeFromOtherFactories

[Tibor17]

The close method is closing the status, no matter that the class name is factory, it really does closing the reports after JVM exit. But I do not want to spend time on talking about theory with design patterns. I was aiming for not giving the developer a chance to call the method I am reimplementing since this class is polymorphic - it has two usages in ForkStarter.

[slawekjaranowski]

I'm still not comfortable for adding next responsibility ReportsMerger for DefaultReporterFactory

[Tibor17]

@slawekjaranowski
The feeling about the methods in the interface ReportsMerger would mean a refactoring and it is not my goal to make here.

If you see the usages of DefaultReporterFactory in ForkStarter you would notice that DefaultReporterFactory has three purposes, one is an aggregator of listeners which is ReportsMerger, second is Fork Reporter and the third purpose is a factory which is constructed in ForkStarter and passed into ForkClient.

Of course it is possible to make a refactoring and rename few methods, which is your main whish coming from your feeling, but it is not the goal of this ticket. The fact is that the field listeners have to be shared and the private method mergeTestHistoryResult() must become protected and therefore the abstraction would contain an abstract class, three interfaces and implementation classes.