That's a good point, but what I saw while I was working on the code was that the env vars come in with each activation. I saw a single JSON object that the runtime receives that it splits into a JSON object (to be passed to the user action) and a set of env vars (that is adds to the already running runtime for the user action to parse). That might be why it wasn't done using the proxy this way so far.
Speaking of which, I'm curious... Why was it done this way in the first place? If the data comes in as a single JSON object to the runtime, why did the runtime move a subset of that data to env vars instead of just keeping it all within the params map sent to the user action code? It seems more complex. Was there a reason back then to do it this way? On Tue, Jun 1, 2021, 7:13 AM Rodric Rabbah <rod...@gmail.com> wrote: > 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. >
