Seperate logs in different directories when using multi-module maven project

[acommuni]

Would it be possible to have one log file "global-groovy.log" (and 2 other log files) per module ? In fact with multi-module maven project there is only one directory soapui/logs created for all modules. It would be nice to have one per module. The first module using soapui mock creates the log directory and then all other modules are logging in it. It's difficult to analyse logs

[redfish4ktc]

@acommuni the issue has the same root cause than #68 The underlying soapui runners have not been designed originally to be runned several time in the same JVM (1st use case was command line usage, so several calls means several jvm instances). What we see here, is that the log4j configuration is initialized during the 1st goal execution (in your case, the mock goal), then each time a new execution starts, soapui skips the log4j initialization (see DefaultSoapUICore).

1st solution could be to add an option in the test goal to force log4j reconfiguration during the goal startup, so all logs will be redirected in the expected directory. But you will have both the mock and the test logs in the same files.

Another solution could be to fork a jvm process each time. I plan to do this for a new test-multi goal (see #89) but this could be also done for the test goal. In this case, you will have all mock logs in a given directory, and test logs in specific directories.

So what do you think about this?

I have also have a question: why do you use one module for each project you want to test? don't you like having all project files in a single module or do you have external constraints?

[acommuni]

I wish you a hapy new year.

Thank you for giving the explanation.

I'm using different module in order to seperate code for each external interface (I mean for each kind of interface contract, for instance one for service provider A, one for service provider B, ...). One external interface = one module, it's only an architectural rule in order to have a clear organization of code. It ensure that modules are indepedent. I'm only using the mock goal. And the mock is only used into the module launching it (~20 modules using mock, ~40 soapui projects)

It could be a good idea to add an option in order to force log4j reconfiguration, it will solve issue on my side but I'm not sure it will fit for everyone using the extension. Forking the jvm could be a better long term solution.

As far as I understood your explanation, each time a new mock goal is used, the new configuration is added into the same JVM. I don't know how plugin is working but I guess that all mocks are only stopped at the end of the whole maven script execution. I didn't see any goal stopping the mock. Does it means, in case a new jvm is used for each goal that those new jvm will only be stopped at the end of the whole maven execution (I mean after all module execution) ?

Forking the jvm is a good idea but do you know when this new JVM could be stopped ? I don't know how many memory a jvm fork need, I assume that a fork is consuming huge part of memory comparing to just executing a new goal.

[redfish4ktc]

Hi, and happy new year to you too :bowtie: Thanks for having clarifying the use case, I previously thought you also used the test goal.

About your remark and question

I don't know how plugin is working but I guess that all mocks are only stopped at the end of the whole maven script execution. I didn't see any goal stopping the mock.

AFAIK, yes the mock service is stopped on jvm termination (i guess, a shutdown hook is registered to make this work). The maven plugin delegates all the processing to a soapui mockservices runner (it is also used when running from the command line); it is not the same code that is used in the GUI to start/stop the mock. The service is implementing using a jetty server, so it should be possible to stop this server as it is done by the jetty maven plugin. Regarding this remark, I would like to know if you use a different port for each mock. This could confirm that the mock are stopped on jvm termination?

Does it means, in case a new jvm is used for each goal that those new jvm will only be stopped at the end of the whole maven execution (I mean after all module execution) ?

Regarding my previous answer, I guess yes, but this should be confirmed by performing more testing.

Even if we still have some pending questions around how the mock services work and your use cases, I've already created some new issues to move forward (see #101, #102, #103)