Seems to be there:

# unzip aws-test-shadow.zip 
Archive:  aws-test-shadow.zip
   creating: aws-test-shadow/
   creating: aws-test-shadow/lib/
  inflating: aws-test-shadow/lib/aws-test-all.jar  
   creating: aws-test-shadow/bin/
  inflating: aws-test-shadow/bin/aws-test  
  inflating: aws-test-shadow/bin/aws-test.bat  

# unzip -l aws-test-shadow/lib/aws-test-all.jar | grep AppLoader
      813  06-21-2018 07:51   org/http4k/serverless/AppLoader.class
     3406  06-21-2018 07:51   org/http4k/serverless/BootstrapAppLoader.class

Does the zip include a base

aws-test-shadow/

directory?

(I've always deployed lambdas as a single jar, so am basically stabbing in the dark here)

I think that's just

unzip

creating a dir with the same name as the zip? I'll try to directly deploy the jar

What I've done in the past is creating a single jar with all classes (incl. dependencies).

Yep, using the jar directly works - thanks!

After figuring out that one has to hit a hidden "Deploy API Gateway" button to apply changes, I have the app running now! 🎉 learnings today: http4k is still awesome, the aws ui sucks

Hi guys, does routing take into account query string params? In other words /somepath and /somepath?someparam=5 are matched as different routes ?

@zero.meta no - only paths are used for route matching

Ok thanks

just updated to 3.39.2 from 3.34 and unit test that checked that a missing required query parameter resulted in a 400 are now failing and I am getting 500s? Any thoughts?

@scap Are you able to share some code that exemplifies the issue?

I will have to write something up

Checked the changelog - nothing sticks out particularly

maybe it is on our end but not sure how... let me see if I can get a more generic example and provide a gist

@scap you're using contracts yeah? is it a security API key?

I am using contracts but its not part of the API key... it is a query parameter to a rest endpoint

Hmmm - that seems like the request is blowing up in a non lensfailure

The trace will probably be in the response.

so it appears I have a exceiption handler filter that is catching the lensFailure exception. I wanted my exception handler to be the last line of defense. It seems if I disable it, http4k works like expected which would lead me to believe that http4k catches that exception and returns a 400 whereas my catch all returns 500s because it is suppose to log details and sanitize the output to the user.

is there a way to put my exception handler at a higher level?

Looks like I can use the catchlensfailure filter before mine to fix this issue.

Just thought it might be worth knowing, it looks like http4k 3.39.3 pulls in jetty 9.4.12.RC as a transitive dependency rather than a stable jetty release. We are using gradle.

@xuemin.guan good spotting. I'm changing it to use the latest release version

Please notice: due to a very silly spelling mistake made by me, http4k version has now jumped from 3.39.3 to 3.93.4. As we can't "un-release" things from maven central, we'll continue to increment from that version (i.e. next version will be 3.94.0)

Hi http4k-ers. What’s the way you do content negotiation in HTTP4K?

Using the body lense mechanic, we implement basic content negotiation, but it only supports a single content type. You cannot discriminate between endpoints on content type.

I want something a bit more complicated. I’ll write something with apache.http.message for now…

using the BasicHeaderValueParser class