Java 3 - 2026

Week 9

Week 1 - Setup Pet Clinic App. Deployment using Docker.
Week 2 - Domains, AWS, ER Diagrams and Databases, Understand the Pet Clinic Setup.

Week 3 - MVC, Repository interfaces, Thymeleaf, Internationalization, Controller Unit Tests,

Week 4 - Use Case Narrative, Sequence Diagram, State Chart Diagram, Create new objects.
Lesson 5 - Users, roles, and permissions setup from Java 2. Unit Tests. Show object details.

Lesson 6 - User Registration, flash messages, Session Cookies

Lesson 7 - Login and logout. Midterm Review. Manage the user profile. More form controls.

Lesson 8 - Midterm exam. Prevent duplicate insert records.

Lesson 9 - Edit and delete user profile. Password reset. GitHub Actions. Recipe API.

Lesson 10 - User permission access.
Lesson 11 - Update and delete existing objects. Filtering and limiting records by category.
Lesson 12 - Web Sockets. Date and currency formatting.
Lesson 13 - Email and SMS messaging. Failed login attempts.
Lesson 14 - Shopping Cart. Payment processing. Homepage with content from the database. Custom not found and error pages.

Course Plan

• Add this abstract method to the UserRepository interface:
  boolean existsByEmail(String email);

• This @PostMapping manages fetching the user data for the form and carefully processing the updates. It handles the specific alternative flows outlined in the sequence diagram: checking for duplicate emails and only hashing the password if the user actually typed a new one.

ProfileController

• When a user is updating their profile, we do not want the strict password rules to fire automatically (so they can leave it blank).

• Because we used standard @Valid, Spring only validates the Default group. It completely ignores the @NotEmpty password rules, allowing the form to submit successfully even if the password field is blank!

• Because we bypass the entity annotations during profile updates, if the user does type a new password to change it, the manual checks we wrote in the ProfileController earlier—like checking if (!newPassword.matches("^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z]).{8,}$"))—will step in to protect the system.

ProfileController

• Since we updated your loginForm and profile pages to use the new fragments after you had built your registration page, your registerForm.html is still using old HTML inputs that don't know how to look for the BindingResult errors.

• Open your registerForm.html. Replace your manual inputs with the fragment calls.

Registration Error Msg Disappear

• Spring Security keeps a SecurityContext in the server's memory for the logged-in user, which has the user's old email written on it.

• A POST "/users/profile" successfully changes their email in the database.

• The user is redirected back to the GET /users/profile page.

• Your controller asks Spring Security, "Who is this?" Spring Security looks at the badge and says, "This is [old email]."

• Your controller asks the database to find the user with the old email.

• The database says, "User not found" (because you just changed it), which triggers your .orElseThrow() exception.

• The ProfileController needs to use your UserDetailsService to rebuild the Spring Security user object.

New Email, User Not Found

• Scroll down to the bottom of your @PostMapping("/profile") method. Right after you save the user to the database, we will check if the email changed. If it did, we dynamically swap out the old security token for a new one.

Refresh the Session

• All of these phone numbers are perfectly valid: 3199999999, 319-999-9999, (319) 999-9999, 319.999.9999, and even +1 (319) 999-9999

• It is highly recommended to normalize data input.

• By stripping away the formatting before saving to the database, your data remains clean and predictable. Then, you can always format it back into a readable string exactly when you need to display it.

• In the ProfileController, update your @GetMapping("/profile")

Phone Number Normalization

• When the user submits the form, the @Pattern regex we just wrote will still do its job verifying that the input is a valid phone number.

• Once it passes validation, we will strip out everything except the digits (\D means "non-digit") right before saving it to the database entity.

• Update the updating block inside @PostMapping("/profile") method:

Sanitize for Database

• To display the logged-in student's information on their specific school's page, we need to pass their User object to the view and then use Thymeleaf to format it. We can also add some visual indicators so the student knows which of their contact details are public to other players.

• Open SchoolController.java. We need to capture the Principal object, look up the user, and add them to the model.

• Because a school page might be public (viewable by people who aren't logged in), we should check if the Principal is null before trying to query the database.

Display logged-in user's info

• principal != null: This ensures that if a random guest views the school page, the application doesn't crash trying to look up a non-existent user.

• ifPresent(user -> ...): Since your findByEmail returns an Optional<User>, this is a very clean way to say, "If you found the user, run this block of code."

• mav.addObject("currentUser", user): This explicitly names the object currentUser, which will matche the th:if="${currentUser != null}" check in the HTML snippet we will build next.

• If you want the phone number to display as (319) 999-9999 on this school page, you can either format it in the SchoolController (just like we did in the ProfileController), or you can use a custom Thymeleaf utility. For now, formatting it in the Controller right before adding it to the model is the quickest method.

How it works w/ ModelAndView

• Now, open the schoolDetails.html file for your school page.

• We will wrap the user's information in a th:if="${currentUser != null}" block. If a guest views the page, this section will safely remain hidden. If a logged-in student views it, they will see their "Player Card."

• Here is a Bootstrap-styled card. It includes logic to prioritize their nickname over their firstName, and adds helpful "Public/Private" badges for their contact info.

Update the School Template

• A two-column design keeps the focus on the active leagues while giving the user quick access to their profile and status on the side.

• Since you are using Bootstrap, we can achieve this easily using its 12-column grid system. We will create a <div class="row">, assign 9 columns (75%) to the left side for your future events, and 3 columns (25%) to the right side for the Player Card.

• col-lg-9 and col-lg-3: The lg (large) breakpoint tells the browser to strictly enforce the 75%/25% split on desktop screens and large tablets.

• Mobile Stacking: Because we didn't specify smaller breakpoints like col-sm or col-12, Bootstrap automatically defaults to stacking the columns vertically on smaller screens. The main content (leagues) will display first, and the Player Card will neatly slide underneath it.

• shadow-sm: I added a slight drop shadow to the cards to give the dashboard a bit more depth and a polished, modern feel.

Bootstrap Styling

• If the first and last name are null in the database, the program displays "null null".

• To fix this, we can use the Thymeleaf <th:block> tag to group multiple HTML elements together to apply Thymeleaf logic (like an if statement) to all of them at once.

• Replace your current <h5> and <hr> tags with this block:

Handling null values

• The th:if check: It checks if any of those three name fields exist in the database before deciding to render the block.

• The #strings.isEmpty() check: It checks for both null and "" at the same time.

• When you submit an HTML form, browsers don't send null for empty text boxes; they send an empty string "".

• While the Thymeleaf fix solves the display issue, you really don't want your database filling up with empty strings instead of proper null values. It makes writing SQL queries down the road harder.

• Spring Boot has a built-in tool called the StringTrimmerEditor that intercepts form submissions, trims off excess whitespace, and converts empty strings back into null before they ever hit your Entity or Database.

• Open your ProfileController.java and add this single method anywhere inside the class:

Handling null values

• Because the User entity has a deletedAt timestamp field, the best practice here is to perform a "Soft Delete." Instead of actually wiping the record from the database (which can orphan records like past league scores or team rosters that depend on this user's ID), we simply stamp the deletedAt column with the current date and time.

• After updating the database, we must also explicitly log the user out so their active session is destroyed.

• Then, add the new @PostMapping method and imports inside the class:

@PostMapping("/users/delete")

• SecurityContextLogoutHandler: This is a Spring Security utility that handles the messy work of clearing the SecurityContext, invalidating the HTTP Session, and removing any "Remember Me" cookies if you have them configured.

• Soft Deletion (setDeletedAt): The user remains in your database so you don't lose historical sports data, but the timestamp flags them as inactive.

• Because we only soft-deleted the user, they still technically exist in the database with their password intact. If they try to log in again right now, Spring Security will likely let them in!

• We need to update your UserDetailsServiceImpl (the class that loads the user during login) to reject users whose deleted_at column is not null.

@PostMapping("/users/delete")

• Locate your loadUserByUsername method. 

• Treat the user as if they don't exist

• If you throw a UsernameNotFoundException, Spring Security treats the login attempt exactly as if the email was never registered. This prevents malicious actors from guessing which emails belong to deleted accounts.

Reject Soft-Deleted Accounts

• Now, if a student decides to delete their account, their historical intramural data stays intact in your database tables.
• However, the exact millisecond they hit that "Delete Account" button, their session is destroyed, and the UserDetailsService acts as a bouncer, permanently preventing them from logging back in with those credentials.

• Update your profile.html file with a DANGER ZONE and a red button to delete a user account.

Form to Delete the Account

• If a guest user visits "/users/profile", the program displays "An internal server error occurred. ... because "principal" is null"`

• Spring Security doesn't have a logged-in user for your controller, so it passes a null Principal. When the code calls principal.getName(), Java throws a NullPointerException and crashes.

• To fix this, we need to tell Spring Security to act as a bouncer and protect that URL for GET and POST requests. When configured correctly, Spring Security will intercept the guest before they even reach your controller and automatically redirect them to the login page.

• Edit the HTTP authorization rules in your SecurityConfig SecurityFilterChain bean.

Edit Profile for Guest Users

• Currently, Spring Security redirects the guest user to the login page before we have a chance to attach a warning message or flash attribute.

• Spring Security has a feature called "SPRING_SECURITY_SAVED_REQUEST" that, when it intercepts a user, saves the URL they were trying to visit in the session so it knows where to send them after they successfully log in.

• In case the user doesn't log in right away, we can drop a second temporary string "WARNED_URL" into the session to keep track of which URL we just warned them about.

• Update the AuthController.initLoginForm method as follows.

Edit Profile for Guest Users

• How this flow works now:

  • The user sneaks into /users/profile. Spring Security intercepts them and saves the request.

  • They arrive at /login. attemptedUrl is /users/profile. warnedUrl is null.

  • The controller shows the warning and sets WARNED_URL to /users/profile.

  • The user clicks "Home", then clicks "Login".

  • They arrive at /login. attemptedUrl is /users/profile. warnedUrl is /users/profile.

  • Because they match, the controller skips the warning, and the user sees a clean login form.

Edit Profile for Guest Users

• Add a "Go to my school" button on Edit Profile page to improve the user's experience.

• We can easily extract the "slug" from their email address and pass it to the view.

• Open your ProfileController.java and update your @GetMapping("/profile") method. We will grab the user's email, extract everything between the @ symbol and the .edu (the slug), and add it to the model.

Go to My School

• Open your users/profile.html file. We can add this button right at the top next to the "Edit Profile" header so it acts like a "Back" button.

• Find your <h2>Edit Profile</h2> tag near the top of the container, and replace it with this flexbox header:

Add the Button to the HTML

• We need to create a configuration file that tells Spring to listen for that ?lang= parameter in the address bar and store it in a cookie.

• Create a new file named LocaleConfig.java (perhaps in a config package)

Language Saved

• Now, we need to tell your ProfileController to append that ?lang= parameter to the redirect URL right after it saves the user's new preference to the database.

• Open your ProfileController.java and scroll to the very bottom of the @PostMapping("/profile") method. Update the return statement:

Change Lang on Profile Update

• A user selects "Korean" from your dropdown and clicks "Save Changes".

• Your controller saves KO to the preferred_language column in the database.

• The controller redirects the browser to /users/profile?lang=ko.

• The LocaleChangeInterceptor sees ?lang=ko, instantly switches the application's locale to Korean, and drops a 1-year cookie in the user's browser.

• If the user logs out and comes back next month, their browser automatically sends the cookie, and Spring greets them in Korean!

How it works

• Instead of you manually running gradle build, docker build, and docker push on your laptop, GitHub Actions can be used to do them automatically every time you push code.

• Here is the workflow:

  • You push code to your GitHub repository.

  • GitHub Actions wakes up, spins up a temporary server (runner).

  • It builds your jar using Gradle.

  • It logs in to Docker Hub (using secrets you provide).

  • It builds and pushes your Docker image.

• Open your GitHub repository. Click the Actions tab. Click one of the red X's. The action names (gradle-build.yml and maven-build.yml) come from your ".github/workflows" folder. You may delete these files.

GitHub Actions

• The petclinic app comes with three workflows `deploy-and-test-cluster.yml`, `gradle-build.yml`, and `maven-build.yml`.

• Here is exactly why it is safe to remove them:

• maven-build.yml: You already committed to Gradle for this project, making the Maven pipeline completely redundant.

• gradle-build.yml: By default, this workflow runs ./gradlew build, which automatically executes all of the Spring Boot integration tests. Because you updated the application properties to require environment variables for your external MySQL database, the GitHub Actions server cannot start the application context to run the tests, which will cause the entire run to crash. Furthermore, your custom deploy.yml file already handles the necessary Gradle building for you (while intentionally skipping those tests using the -x test flag).

Delete other Workflow Files

• deploy-and-test-cluster.yml: This is a highly specialized workflow built for deploying the application to a Kubernetes cluster (specifically using a tool called standard kind). Since you are using Azure Container Apps, this file serves no purpose for your infrastructure.

Delete other Workflow Files

• You should never put your Docker Hub password directly in the file. You use GitHub Secrets.

• Go to your GitHub repository.

• Click Settings -> Secrets and variables -> Actions.

• Click New repository secret.

• Add these two:

  • Name: DOCKERHUB_USERNAME

    • Secret Value: your_actual_username

  • Name: DOCKERHUB_TOKEN

    • Secret Value: (Go to Docker Hub -> Account Settings -> Personal access tokens​ -> Generate New Token)

    • Type "GitHub Actions" as the access token description.

    • For access permissions, select "Read & Write".

    • Use this token instead of your real password.

Set up Secrets

• In your project, create this yml file: .github/workflows/deploy.yml

• Paste this content in, customized for Gradle and Java 17.

• Change petclinic (lines 48, 61-64) to your image name.

• To keep your v1, v2, v3 pattern going without having to manually type it every time, you can use a built-in GitHub variable called github.run_number. (See step 6)

Create the Workflow File

• Commit and push this file to GitHub.

• Go to the "Actions" tab in your GitHub repository. You will see the workflow running. You may click the workflow and annotation name to see its progress.

  • If it turns green, check Docker Hub—your image will have been freshly updated!

  • If it turns red, click the workflow run name. Click the annotation name with a red X. Figure out which step caused a problem. Click the "Re-run jobs" button.

• By doing this, every single push (or merged pull request) to your main branch will create a brand-new, uniquely numbered tag (starting with v1). 

• Right now, GitHub pushes the image to Docker, but Azure doesn't know about it yet.

Trigger it

• You can add additional steps to the GitHub Action that runs az containerapp update to tell Azure to pull the new image immediately.

• To make this work, GitHub Actions needs an "ID badge" (a Service Principal) so Azure trusts it enough to accept the remote update command.

• Run this command in your PowerShell terminal to create a dedicated service account that only has access to your specific resource group, keeping your full Azure account secure.

Azure Step in YAML

• Go to Azure, click "Azure for Students" to see your subscription id.

• To view the service principal, open your resource group, click Access control (IAM), then Role Assignments.

• Go back to your GitHub repository.

• Navigate to Settings -> Secrets and variables -> Actions.

• Click New repository secret.

• Name: AZURE_CREDENTIALS

• Value: (Paste the entire JSON block here)

• Click Add secret.

GitHub Secrets

• Add these final two steps to the bottom of your .github/workflows/deploy.yml file.

• Since your GitHub Actions workflow runs on a Linux machine (ubuntu-latest), we use the bash line-continuation character \ here instead of the PowerShell backtick character `.

• Change petclinic to your image name.

Append to your YAML File

• To securely run your automated tests against your external MySQL database, we need to inject those credentials into the GitHub Actions runner right before Gradle executes.

• Go to your GitHub repository.

• Navigate to Settings -> Secrets and variables -> Actions.

• Click New repository secret and add these three secrets one by one:

  • Name: MYSQL_URL, Value: jdbc:mysql://YOUR_WEB_DB_HOST:3306/YOUR_DB_NAME?useSSL=true

  • Name: MYSQL_USER, Value: YOUR_DB_USERNAME

  • Name: MYSQL_PASS, Value: YOUR_DB_PASSWORD

    • ​or MYSQL_PASSWORD

MySQL database credentials

• Now, we need to update Step 3 in your .github/workflows/deploy.yml file.

• Provide the secrets to the step using the env: block.

• Change the run command to ./gradlew clean build -x jar. (Using build instead of bootJar tells Gradle to explicitly run the test phase before packaging the application).

• If someone submits a pull request or pushes broken code to your repository, the test phase will fail. When a step fails in GitHub Actions, the entire workflow immediately stops. This guarantees that a broken image is never built, pushed to Docker Hub, or deployed to Azure.

MySQL database credentials

• The project uses the Spring Java Format plugin. This is a strict code-styling enforcer that the Spring team uses to guarantee all code looks exactly the same (spacing, indentation, bracket placement, etc.).

• When your GitHub Action runs./gradlew clean build, it triggers the checkFormatMain task. The plugin scans new Java files you add and fails if they don't perfectly match the official Spring style guide. 

• You do not need to format these files by hand. The Gradle plugin can fix them for you automatically.

• Open the terminal in IntelliJ and run the automatic formatter command:

• Windows (PowerShell): .\gradlew format

• Mac/Linux: ./gradlew format

Spring Java Format plugin

• The Spring PetClinic project includes a plugin called NoHttp. Its sole purpose is to scan every single file in your project (Java, HTML, XML, Markdown, etc.) and fail the build if it finds a URL that starts with http:// instead of the secure https://.

• This guarantees that the application never accidentally loads resources over an unencrypted, insecure connection.

• Open the file mentioned in the error: src\main\resources\templates\fragments\layout.html

• Go to line 3.

• Change the http to https so it looks exactly like this: https://www.thymeleaf.org/extras/spring-security

Task :checkstyleNohttp FAILED

• Commit and push this updated YAML file to your main branch. This will immediately trigger the workflow.

• If successful, GitHub will build your app, push the dynamically tagged image to Docker Hub, and seamlessly tell Azure to swap to that exact numbered version!

• If it failed, GitHub provides detailed logs for every single command it runs.

• Click on the workflow run that has a red X next to it.

• On the left side under "Jobs", click build-and-push.

• You will see a list of steps. Click on the step that has the red X (likely Build and Test with Gradle) to expand its terminal output.

• Scroll to the bottom of that expanded log. You are looking for a specific Java or Gradle error.

Trigger it

• Our SiteGround databases currently allow access from any IP address, which is not secure.

• If I limited the IP addresses, while your laptop might be allowed to connect, the GitHub Actions server is a random machine in the cloud. SiteGround will look at GitHub's IP address and block the connection, causing your Gradle tests to hang and fail.

• If it is a firewall issue, you generally have two paths forward:

• Option A (Skip Tests in CI): The easiest fix. You can change the YAML run command back to ./gradlew clean bootJar -x test -x jar. You simply rely on running your tests locally on your computer before you push.

• Option B (Testcontainers): The professional standard. Instead of connecting to your external SiteGround database during the GitHub test phase, you configure Spring Boot to spin up a temporary, throwaway Docker container with MySQL inside the GitHub runner itself just for the tests.

SiteGround Database

• Later, when you are setting up your CI/CD deployment pipeline to push this application to a live server, you can simply pass an environment variable telling the server to run with spring.profiles.active=prod, and it will completely ignore all your local development tweaks.

GitHub Actions