#4750 Java invoke local support for handlers that implement RequestStreamHandler

[XaeroDegreaz]

What did you implement:

Closes #4750

How did you implement it:

I performed some checks inside the invoke method to support RequestStreamHandler compatible handlers. The checks include testing whether or not the first parameter was an InputStream type, and also a similar check during the reflected method invocation.

How can we verify it:

Unit tests are included that verify that RequestStreamHandler methods can receive input, and write to an OutputStream. You can verify it by running the tests from your IDE, or simply run mvn clean test in the root of the plugin's directory.

You can also run mvn clean package from the plugin's directory; it will run the tests, and output the plugin JAR to target/invoke-bridge-1.0.jar. You can take this JAR file and put it in your global node_modules directory that houses serverless. For instance on my machine that location is /usr/local/lib/node_modules/serverless/lib/plugins/aws/invokeLocal/java/target. Be sure to back up the original serverless JAR, just in case ;)

After replacing your JAR, you can run sls invoke local with your function (one that handles RequestStreamHandler), and provide a path to some target data file to verify functionality.

Todos:

• Write tests
• Write documentation
• Fix linting errors
• Make sure code coverage hasn't dropped
• Provide verification config / commands / resources
• Enable "Allow edits from maintainers" for this PR
• Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

[XaeroDegreaz]

Old test dev APP id -- no longer valid.

[XaeroDegreaz]

Old test dev CF id -- no longer valid.

[pmuens]

Great! Thanks for working on this @XaeroDegreaz 👍

This looks good from a code perspective. Unfortunately I wasn't able to test this on my machine (both bare metal and in Docker) since building the bridge takes forever and it hangs there. I tested invoke local against master and I see the same issue, so it might be something with my setup.

@dschep @eahefnawy could you test this? After that we should be able to merge this soon

[pmuens]

Thanks for updating this PR @XaeroDegreaz 👍

Looks like we're almost there. Just a minor permissions error with the invoke local bridge:

[nix-shell:~/code/serverless/tmp/java-maven]$ ../../bin/serverless invoke local -f hello
Serverless: In order to get human-readable output, please implement "toString()" method of your "ApiGatewayResponse" object.
Error: Unable to access jarfile ~/code/serverless/lib/plugins/aws/invokeLocal/java/target/invoke-bridge-1.0.1.jar

Let us know if you need any help here!

[XaeroDegreaz]

@pmuens

Hm, did you put the invoke-bridge-1.0.1 JAR in your plugins directory?

I'm not entirely sure how one would test it other than that. I just packaged the jar manually, dumped it in the plugin directory, updated the index.js file in the parent directory, and ran the invoke command.

Once I saw that worked, I updated the index.js file in the repository and pushed.

How are you testing?

If you'd prefer, I can just revert the commit incrementing the version. It just seemed like the appropriate thing to do at the moment, but if it's somehow introduced some new complication in the file permissions (not sure where all of that is set up), then I'm fine with a revert.

[pmuens]

Thanks for the reply @XaeroDegreaz 👍

I started with a regular invoke local test to check whether the core functionality (prior to this PR) still works.

So what I did was:

1. serverless create -t aws-java-maven -p java-maven
2. cd java-maven
3. mvn package
4. serverless invoke local -f hello

This works on master, but I got the permission error when using this PR.

[XaeroDegreaz]

@pmuens

Ahh, I see!

Ok, so after mvn package, you need to take the artifact, ./target/invoke-bridge-1.0.1.jar, and put it in ~/code/serverless/lib/plugins/aws/invokeLocal/java/target/.

I'm assuming that you guys have some build process that does this for the real distribution that people get, i.e. performs the Maven build then puts the artifact where it needs to go for dist, however in this instance, you're simply checking out the repository as-is, building the JAR, and not doing anything with it :D

Hope it helps!

[pmuens]

Thanks for the follow-up @XaeroDegreaz 👍

I just tested it again and it works. The reason why it failed on my end was that I had the old bridge built (from master) which was not overwritten when running your changes. I just wiped the target directory in the invokeLocal plugin and everything worked as expected.

[pmuens]

LGTM