Creating a Serverless framework project with Java Lambdas

The cli gives 2 Lambda project type options for new projects – Node,js and Python:

% serverless  
 Serverless: No project detected. Do you want to create a new one? Yes
 Serverless: What do you want to make? 
   AWS Node.js 
   AWS Python 
 ❯ Other 

If you select Other, it prompts you to create a project using a template:

Run “serverless create --help” to view available templates and create a new project from one of those templates.

The ‘create –help’ option tells you to run with the –template option and provides a long list of supported project types. Since I’m using Maven with Java, I’ll use the aws-java-maven option:

serverless create --template 

Since I already had a Maven pom.xml in place as a starting point for my Lambdas in this test project, the serverless cli warns that it won’t overwrite the existing file. I’m not familiar with what additional dependencies the aws-maven-template will add, so I renamed my pom.xml and reran the ‘serverless create’ cli and generated a new pom.xml.

Looking in the new file, there’s a similar and expected use of the Maven Shade plugin to bundle a ‘fat jar’ and other dependencies for Log4J and the addition of Jackson for json parsing.

There’s also a couple of extra Classes generated too that I wasn’t expecting, but they match up with the example code in the serverless docs (article here), so there’s a ApiGatewayResponse class that I wasn’t familiar with (from building AWS Lambdas with Java by hand and not using the API Gateway Lambda Proxy feature).

As a test, I looked into creating a couple of Java Lambdas not using the generated Classes just to confirm that there’s nothing Serverless framework specific that needs to be used. As it turns out, the default usage of the APIGateway Lambda Proxy feature the Lambda runtime is is expecting to map a json payload into the handler parameters and similarly for the response payload. For testing I just wanted to pass a couple of String request params on a GET request. So for my first test I got the following exception:

An error occurred during JSON parsing: java.lang.RuntimeExceptionjava.lang.RuntimeException: An error occurred during JSON parsingCaused by: com.fasterxml.jackson.databind.JsonMappingException: Can not deserialize instance of java.lang.String out of START_OBJECT token at [Source: lambdainternal.util.NativeMemoryAsInputStream@4cf777e8; line: 1, column: 78] (through reference chain: java.util.LinkedHashMap["headers"])Caused by: com.fasterxml.jackson.databind.JsonMappingException: Can not deserialize instance of java.lang.String out of START_OBJECT token at [Source: lambdainternal.util.NativeMemoryAsInputStream@4cf777e8; line: 1, column: 78] (through reference chain: java.util.LinkedHashMap["headers"])    at com.fasterxml.jackson.databind.JsonMappingException.from(  

At this point I got distracted with a wide range of Java Lambda together with the API Gateway Lambda Proxy specific issues which I covered in a separate post here.

Long story short, the Serverless config for a Java Lambda enables the API Gateway Lambda Proxy feature by default, which means your Lambda impl needs to have a POJO class for it’s return type that matches exactly what API Gateway expects, so the Lambda to API Gateway Proxy integration can map the return value to the expected JSON structure. You can build this yourself to match what is described in the docs (link above) or just use the provided class generated by the aws-java-lambda template. The generated class ApiGatewayResponse is exactly what you need, so rather than reinventing the wheel I changed to use this generated class as the return value from my Java Lambda handler and now it works as expected.

My handler now looks like this:

public class MyHandler implements RequestHandler, ApiGatewayResponse> {

    @Override public ApiGatewayResponse handleRequest(Map<String, Object> input, 
        Context context) {

Note that in order to receive parameters from incoming requests via API Gateway proxy, the first parameter needs to be a Map<String, Object>.

This is the first time I’ve used API Gateway Lambda Proxy with Java Lambdas. Previously the JavaLambdas I’ve built took advantage of API Gateway mapping any parameters to your Lambda automatically using Jackson to a POJO parameter on your Handler method, and even handing a POJO return type serializing that to a JSON response for you. I’ll come back and do some comparisons between these two approaches later.

To deploy your Java Lambda using serverless it’s the same as with Node.js Lambdas or any other supported runtime:

serverless deploy

To test calling your Java Lamdba function locally as if it’s deployed to AWS, use

serverless invoke local --function functionName

where functionName is what to defined your handler as in your serverless.yml.

By default the generated ApGatewayResponse class doesn’t have a toString() so you’ll see the response to your local test print something like:


but you can add a toString() to help with testing locally (this is mentioned in the docs here).

The framework saves a lot of time in automating the deployment and configuration of your Lambdas and is well worth a look.

Sun Ultra 60 serial console login with a VT132

I recently assembled a VT132 and have been connecting it to various things to enjoy some serial terminal goodness.

I’ve tried a number of serial cables and serial terminal programs on my Atari ST to get a serial connection to my Sun Ultra 60 but never managed to get it to work. I didn’t know if this was due to my serial cable or something else. I bought and assembled the VT121 as a VT100 compatible serial terminal to have a better attempt at connecting to some of the devices I have around that support serial connections.

On the VT132 there are jumper pins to switch between a straight though connection or a crossover connection. Through trial and error I found I needed to put the jumpers on 1-3 and 2-4 for the cross over connection and this worked with the Sun Ultra.

I don’t have a pic of the pins in this configuration, this is the section in the docs, and here’s the pin layout next to the voltage regulator for reference (center of the photo):

Pins 1 2 3 4 are on the right. Here’s the pins in the straight through config 1-2 and 3-4, the two jumpers on the right need to be switched to the other 1-3 and 2-4 configuration to work with the Sun Ultra:

There’s two serial connectors on the Sun Ultra 60, note that the DB25 at the top is a parallel connector. Serial A and B are beneath the keyboard connector:

Here’s some useful info on configuring Serial console connections to Sun hardware here. Typically on Sun Sparc systems, if you disconnect the keyboard and have a terminal connected to Serial A when you boot, the boot messages are redirected to the serial terminal instead of the video output. This is useful if you need to run diags on a machine, but it’s also fun to boot the machine up and logon from a serial console. Here’s what the console boot messages look like on my Ultra 60:

At this point I could successfully logon via the console. As I was looking into getting this working I took some notes as I was working on this. I’ll include them here for future reference in case they’re useful.

Other useful notes:

/etc/remote has section for enabling hardwire tip via /dev/term/a|b

See also here talks about /etc/ttytab to enable logins

To enable a logon prompt via Serial A or B after booting, and with keyboard connected:

From here:

sacadm -a -p mbmon -t ttymon -c /usr/lib/saf/ttymon -v `ttyadm -V` -y "TTY Ports a & b"

cat /dev/term/a shows keyboard entry from my VT132 terminal when I press enter, so I know input is reaching the port.

With my serial cable, I needed to set the straight through vs crossover jumpers on the VT132 to the crossover position get any output to appear on the terminal.

Set terminal to 9600 8N1.l