Hi Matt. If using the go proxy (aka “action loop”), doesn’t it export the environment variables before running the JVM?
-r > On Jun 1, 2021, at 1:17 AM, Matt Welke <mattwe...@gmail.com> wrote: > > Hi everyone, > > When I read the history of the GitHub PR open right for adding Java 11 > support, I learned that modern Java doesn't support what the OpenWhisk > contract does right now, where environment variables are mutated at > runtime. I thought of another approach. I left details in the GitHub PR in > a comment ( > https://github.com/apache/openwhisk-runtime-java/pull/82#issuecomment-851799588), > but I'll repeat the main idea here. > > Instead of adding environment variables, which is problematic since the > environment has already been created (the runtime is the environment, and > the user action is a "hook" so to speak that the runtime dynamically links > to), a second parameter is added to the user action. The first parameter is > the traditional "params" where it's the values set at deploy time, which > are optionally overridden at request time, and the second parameter is > these values that used to be added to the environment with the __OW_ prefix. > > I have an example Java 11 runtime working ( > https://github.com/mattwelke/apache-openwhisk-runtime-java). I tested it on > IBM Cloud Functions as a Docker action. That repo has a strange structure. > It doesn't use Maven or Gradle. But don't worry, I wouldn't expect code > like that to be checked into the official project. I'm not very familiar > with Maven or Gradle yet because I'm new to coding things in Java outside > of playing around in IntelliJ's GUI in school. I thought a fun way to learn > Java would be to make Java 11 and Java 16 runtimes for OpenWhisk. A custom > build system where I could focus only on what I needed was the quickest way > for me to make a custom runtime. > > Curious to hear peoples' thoughts on this new user action contract idea.
