server.env file not being resolved about liberty-arquillian HOT 11 CLOSED

@chyt I think we started the java process directly as that seemed like the "easier" option due to the following reasons:

• If we use the script we potentially need to track the child processes of the script and the script runtimes will be different between different systems
• We need to redirect the output and that might be harder to do consistently
• We also need to shut everything down at some point and that also might mean we need to not only terminate the script, but all childs as well
• We are passing several arguments and properties to the java executable and those also still need to be passed through the wrapper shell script; not sure how easy that will be

Considering that you own the script as well you might be able to influence what it does, so it might be possible for you to make this work through the script as well.

from liberty-arquillian.

Thanks for the background info @gpoul!

Regarding PIDs and child processes: when a Liberty server starts, the server script writes out the pid at $WLP_USR_DIR/servers/.pid/<serverName>.pid. So as long as the server name and WLP_USR_DIR are known, the PID of the server can be determined by reading that file.

Also, the JVM options we are passing through should be handled by the bin/server script, or the standard jvm.options mechanism. If any options need to be set in an arquillian layer, in the next release of Liberty we will support passing generic JVM -X or -D options to the bin/server script.

As for child processes and output redirection, I don't have any immediate answers there, but I think we can figure out some sort of solution.

from liberty-arquillian.

I've just published a snapshot here: https://oss.sonatype.org/content/repositories/snapshots/io/openliberty/arquillian/arquillian-liberty-managed/1.0.4-SNAPSHOT/

I will need to run some more tests against Open Liberty and our Liberty Maven/Gradle plugins before I can make a release. I'll try to do this within the next week or two.

from liberty-arquillian.

The reason the server.env file is not being read when the server is started is due to the way the server start is invoked. I talked to @aguibert and was told that things like server.env and jvm.options are only read automatically when the server start is invoked from the bin/server script. Currently the container implementation uses a ProcessBuilder to invoke ws-launch.jar. I'm not sure of the historical reasons as to why this was done - maybe @gpoul could shine some light on this?

I'd like to suggest changing the implementation of the server start/stop to invoke the bin/server commands instead. This is the implementation that we are using in the liberty-maven-plugin, which is done through the ServerTask in our Ant library. I think a similar implementation would make sense in our Arquillian container. I feel that it is cleaner than having the container read server.env and other server config files.

In the meantime, I expect you would be able to circumvent this issue by setting allowConnectingToRunningServer=true in your arquillian.xml and calling the liberty-maven-plugin's start-server and stop-server goals before and after your Arquillian tests run, respectively. That will pass the starting and stopping of the server to the liberty-maven-plugin, which will invoke the bin/server commands so that server.env is respected.

from liberty-arquillian.

@chyt Thank you for the feedback!
Whilst working on a PR for this issue, it did come to my mind why we were not just passing bin/server to the ProcessBuilder instead, which would properly pre-load all server.env files. However, I have at this point (in my PR) mimicked bin/server in fetching and merging server.env properties from the runtime-level as well as server-level, and merging them correctly in case of duplicates. You can give it a review if you like.
With regards to using liberty-maven-plugin to pre-start the server with allowConnectingToRunningServer enabled: Sounds like a good work-around. However fixing the main issue would be more appreciated.

from liberty-arquillian.

We already handle output redirection in the Ant plugin, that should not be difficult. As for handling child processes, would that be done the bin/server stop script? It doesn't looks like we handle this issue in the Ant task other than just calling bin/server stop.

from liberty-arquillian.

I have divided the proposed solutions into 2 PR's.

1. Containing a pre start-up server.env parser #41
2. Attempting to instead run bin/server shell-script, which should handle the loading of properties. #42

Hope this can be of some help!

from liberty-arquillian.

Thanks @HasseNasse! I would be in favor of option (2), since that will help to eliminate all current and future differences between how a real Liberty server gets run and how it gets run the Arq. I've left some review comments on #42 accordingly

from liberty-arquillian.

Sounds good 👍

from liberty-arquillian.

Will there be a new release for this?

from liberty-arquillian.

Closed by #42.

from liberty-arquillian.