jpa02 : Spring Boot and Heroku Hello World

num ready? description assigned MW lect due MW lect assigned TR lect due TR lect
jpa02 true Spring Boot and Heroku Hello World Tue 03/30 05:00PM Tue 04/13 11:59PM

Look here for formatted version:

This is an individual lab on the topic of Java web apps on Heroku.

You may cooperate with one or more pair partners from your team to help in debugging and understanding the lab, but each person should complete the lab separately for themselves.

Step 0: If you are working on your own machine

If you are working on CSIL, you can skip this step.

But if you are working on your own machine, you’ll need to install a few things before proceeding.

See guides for installing these on your machine at the links shown:

Step 1: Understanding what we are trying to do

What are we trying to accomplish again in this lab?

Why use Heroku?

Limitations of the free plan of Heroku

TL;DR: You should NOT need to enter a credit card into Heroku. If you are asked for one, something has gone wrong.

Web Apps vs. Static Web Pages

You may already have some experience with creating static web pages, and/or with creating web applications (e.g. using PHP, Python (Django or Flask) or Ruby on Rails.) If so, then the “Learn More” section will be basic review.

If you are new to writing software for the web, you are strongly encouaged to read the background information at the “learn more” link below.

What are we trying to accomplish again in this lab?

If you just did a deep dive into the article Web Pages vs. Web Apps it may be helpful to again review what we are trying to accomplish in this lab:

Disk Quota

IMPORTANT: if you are working on CSIL, and at some point things just “stop working”:

Then you probably have a disk quota problem.

Step 2: Create a Heroku Account

If you do not already have a Heroku account, navigate to and click the “Sign up for Free” link.

You’ll be asked for:

Step 3: Create your repo

You should already have a repo under the course organization ucsb-cs156-s21 called jpa02-githubid created for you by the staff, where github is your github id.

If not, create one for yourself following that naming convention; it should initially be private, and empty (no README, license or .gitignore.)

Clone that repo somewhere and cd into it.

Then add this remote:

git remote add starter

Then do:

git checkout -b main
git pull starter main
git push origin main

Step 4: Start your webapp on localhost

The application should be ready to go out of the box; it starts up a web server that brings up a page with the message Greetings from Spring Boot!

We are going to run a command to start up this web server and then try to connect with a browser.

Connecting with a browser

Now, if you are running on your own machine, connecting with a browser is quite simple; the web server is running on the local machine (localhost) on port 8080, so putting the address http://localhost:8080 in your browser will just work. If you are successful, you should see the message Greetings from Spring Boot appear in your browser.

It’s the case where you are running on CSIL where things can get more complicated.

First, there’s the possibility that port 8080 may already be taken; in that case you’ll see the error:

Web server failed to start. Port 8080 was already in use.

To see how to fix the Port 8080 was already in use error, click the triangle:

In this case, the fix is to choose another port number. Any number between 8080 and 65535 is fair game; to try another port number, use the command shown below (change 12345 to whatever port number you like):

PORT=12345 mvn spring-boot:run

You’ll need to substitute this number (e.g. 12345) in place of 8080 when trying to load the website.

To see strategies for bringing up a web page for a web server running on CSIL, click the triangle.

Strategy 1: Point browser directly at CSIL machine

If you are running on CSIL, you can try to point your web browser at the machine where the server is running instead of localhost.

For example, if you are running on CSIL and type in hostname, and see this:

[pconrad@csilvm-01 ~]$ hostname
[pconrad@csilvm-01 ~]$ 

Then substitute that name in place of localhost, e.g. point your browser as instead of http://localhost:8080

This may not always work, because firewalls may prevent access. Using the UCSB VPN may help.

Strategy 2: Port Forwarding

If you are using ssh to connect to CSIL, the solution shown here allows you to forward traffic on localhost:8080 on your own machine to localhost:8080 on the machine you are connecting to:

Strategy 3: Remote Desktop

Using the Remote Desktop (RDP) Solution described in the articles below, you can load a complete “desktop” of a CSIL Linux environment and show it in a window on your Mac or Windows machine.

In the RDP window, you can open both a terminal window and a browser that are both running on CSIL. Since that browser is running on the same system as the web server, you can just use http://localhost:8080 to connect to the server.

About localhost and “Port Numbers”

The code in this repo is configured to start up a webserver on port 8080, running on localhost, which is a name for the machine on which the code is running.

So the web address to acccess your server is: http://localhost:8080.

Step 5: Undertstanding localhost vs. Heroku

When running on localhost:

Running on localhost is fine for testing and development. But eventually we want to know how to deploy a web application so that anyone on the internet can access it.

To get the web app running on the public internet, we’ll need to use a cloud-computing platform such as Heroku. Heroku allows us to deploy web applications in Java rather easily.

A side note: though we won’t explore it in this course, Heroku also makes it easy to deploy webapps in a variety of langauges, including Python, Node (JavaScript), and Ruby just to name a few. Many of the skills you’ll learn in this course about Heroku will transfer to those other languages if you want to work with them in other courses such as CMPSC 48, CMPSC 189A/B, or personal projects.)

A note about security: Let’s say up front that this is a risky thing to do. You need to be very careful about security when deploying web applications to the public internet. Fortunately, this particular application is rather simple and low-risk. We’ll discuss web security throughout the course.

Step 6: Create a new Heroku App using the Heroku CLI

In this step, we’ll deploy our Spring Boot application to the public internet using Heroku.

Logged into CSIL (or one of the machines in the CSTL, i.e. Phelps 3525), use this command to login to Heroku at the command line:

heroku login


Then, use this command to create a new web app running on heroku. Substitute in your UCSBNetId (i.e. your ucsb email without the part.

That is, if your email is, please make your heroku application name jpa02-cgaucho. This name is important, because the Gradescope autograder willbe looking for a Heroku application that matches this naming convention. If there is a reason that you cannot use this naming convention (e.g. your ucsbNetId is not accepted as part of a heroku application name because of special characters, upper case characters, etc.), please note this on the #help-jpa02 channel on Slack.

Note that you should convert your ucsbnetid to all lowercase; heroku web-app names do not permit uppercase letters, and use - in place of underscores or periods.

heroku create jpa02-ucsbnetid-


Step 7: Login to the Heroku Dashboard

Login to and look for the jpa02-cgaucho app (or whatever your name is) that you created.

You should find a place where you can connect your App to Github.

Click on this, and select your repo to connect the Github Repo to Heroku.

Then, click on “deploy branch”.

What if it doesn’t work?

If it doesn’t work, try these things before asking a mentor, TA, or instructor for help.

  1. Make sure you are logged into Heroku at CLI with heroku login. If you exited your CSIL shell (logged out) and logged back in again, you have to login to Heroku again. Then repeat the commands.
  2. Try heroku logs --app appname (substitute the name of your app where you see appname). You’ll see the log output of that app on Heroku.
    • You may find it helpful to open a second Terminal, login to CSIL and the Heroku CLI, and use heroku logs --app appname --tail, which keeps the log output running continously.
    • You can also see your logs in a web browser at: (note that you need to put your app-name in the URL instead of app-name.
    • You can navigate to this from by selecting your app, clicking on it, selecting the More menu at upper right, and the selecting Logs.

Step 8: Changing what is shown on the page

Go into the Java source code under src and locate the file /src/main/java/edu/ucsb/cs156/spring/hello/

In this file, locate the line of code that says:

    public String index() {
        return "Greetings from Spring Boot!";

This method returns the contents of the home page ("/") for the webapp.

Change that code by changing “Spring Boot” to your email address (without the part).

For example, if your email is, instead of:

        return "Greetings from Spring Boot!";

You’ll have:

        return "Greetings from cgaucho!";

If your email contains upper-case letters, underscore (_) or periods (.) click the triangle for special instructions:

Update: The autograder has been modified to handle the cases of:

  • mixed case (upper and lowercase letters) in email addresses
  • underscores _ in email addresses
  • periods . in email addresses

In order to convert each of these to legal Heroku app names, the autograder converts your email by:

  • stripping off the @ and everything after the @
  • converting to all lowercase
  • converting _ and . to - Examples:
  • becomes foo-bar
  • becomes my-lit-tle-pony

So, if your email address is, you should modify your code to replace:

        return "Greetings from Spring Boot!";


        return "Greetings from my-lit-tle-pony!";

If your email presents any other corner cases that are handled above, make a post on #help-jpa02 on slack to ask for help.


If it works, then the words “this github repo” should become clickable links.

Ok, so far, we haven’t really done anything we couldn’t have done with a static web page. But we have gotten a working Java web app running on Heroku, so it’s start we can build on.

Step 9: The test cases

You’ll see that when you run “mvn test” that there are test cases, some of which are now failing.

The test cases are in these files:

Run the tests and see them fail.

Then modify them so that they pass. Note that we are doing TDD “wrong” this time; to do it “the right way”, we should have modified the tests first, and then modified the code so that the tests pass. We’ll pivot to this style of working once we have a better grasp on all the moving parts here.

Step 11: Adding links to repo in the

Edit your You’ll find some TODO items inside indicating what edits you need to make.

All quarter long, we want you to develop the habit of adjusting the in your repo to include a link to your repo.

The link to your repo may seem redundant, but it helps your mentors, TAs and instructors; when you submit your work for grading to either Gradescope or Gauchospace, having those links handy really helps us navigate through your assignments quickly to evaluate them and assign grades.

Step 12: Submitting your work for grading

When you have a running web app, make a submission under jpa02 on Gradescope.