Open letmaik opened 4 years ago
@letmaik @hukoyu I think that it makes sense to keep the script, as it's otherwise cumbersome to run any Java application from the command-line, given the complex JVM options that must be passed. I agree that it could be moved out of tools/
but the question is then where to put it. Java applications under samples/
would use it, but also tests under tests/
.
@prp @letmaik I totally agree with Peter that we must keep sgx-lkl-java tool. It definitely simplifies running java apps. It doesn't sound too bad keeping it under /tools actually it is perfect folder IMHO for the script.
sgx-lkl-java is unsuitable for real deployments, simply because it does not rely on an app config for specifying the necessary environment variables and JRE arguments. It makes sense for tests (simply to avoid duplication), but not for samples or real use cases.
For samples and tutorials/docs etc. we should converge to a single mechanism which scales from local testing to deployment, and that is using an app config. If some applications (like those using the JRE) require non-standard ways for working inside SGX-LKL then we could help users by providing a tool that generates an appropriate host/app config, and to me it looks like sgx-lkl-cfg
is a good candidate for that, e.g. by adding an extra flag like --app-type=java
that adds the required pieces.
The existing sgx-lkl-java
tool can still be used for tests but then we should move it into the tests/ folder as a support tool.
Eventually the sgx-lkl-java
script should be replaced by an app_config mechanism for samples/
while the current script could still be used for tests/
.
Blocked by https://github.com/lsds/sgx-lkl/issues/256
This is very application-specific and should rather be in the form of a sample/test using an app config. Note that this relies on tests/containers/unencrypted/env being fixed first.