Spring Boot Essentials | Matt Speake | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Spring Boot Essentials

teacher avatar Matt Speake, Principal Trainer

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

48 Lessons (2h 19m)
    • 1. Welcome to the Course!

    • 2. Getting Started - Section Introduction

    • 3. Creating a Spring Boot Application with Spring Initilizr

    • 4. Exploring a Spring Initilizr Generated Spring Boot Project

    • 5. Using Maven with Spring Boot

    • 6. Using Gradle with Spring Boot

    • 7. Running and Debugging Spring Boot Apps in the IDE

    • 8. Understanding Layered Architecture in Spring Applications

    • 9. Important Spring Boot Resources You Should Know

    • 10. Tour of a Spring Boot Application - Section Introduction

    • 11. Downloading Spring Pet Clinic

    • 12. Building the Sprint Pet Clinic Application

    • 13. Running the app and taking a tour of the application

    • 14. Examining the project and it's dependencies in the IDE

    • 15. Examining the controllers and web layer

    • 16. Examining the repositories and data layer

    • 17. Examining the startup of a Spring Boot application

    • 18. Examining the application properties, logging configuration and profiles

    • 19. Summing Up the essence of how a spring boot application works

    • 20. Understanding Starter Dependencies - Section Introduction

    • 21. Understanding Spring Boot Starter Dependencies and their resolution

    • 22. Relating the Spring Boot dependency graph within your IDE

    • 23. Looking at the Flattened Resolved Dependencies Set

    • 24. Changing the Starter Dependency to Bring in a Different Spring Boot Technology Stack

    • 25. The Relationship of Starter Dependencies with Autoconfiguration

    • 26. Autoconfiguration - Section Introduction

    • 27. How Spring Boot Creates the Spring Application Container

    • 28. How @SpringBootApplication Configures a Spring Boot App

    • 29. Spring Factories for Autoconfigured Libraries

    • 30. Understanding a Typical Autoconfiguration

    • 31. Property Injection in Autoconfiguration Classes

    • 32. Understanding Conditions and Excluding and Overriding Autoconfiguration

    • 33. Debugging Autoconfiguration by Enabling Autoconfig Reporting

    • 34. Properties - Section Introduction

    • 35. Common Properties in Spring Boot Which You Can Configure

    • 36. Injecting Properties into Spring Managed Beans

    • 37. Providing Default Values for Properties

    • 38. Overriding Properties at Runtime with System Properties

    • 39. Specifying Properties in YAML File Format

    • 40. Accessing Nested Properties and Strongly Typed Property Values

    • 41. App Startup - Section Introduction

    • 42. Examining a Foundational Spring Boot Project

    • 43. Registration of Important Spring Application Listeners

    • 44. Preparing and Establishing the Spring Application Context

    • 45. Creating the Beans of the Spring Runtime

    • 46. Creating the Embedded Tomcat Web Server

    • 47. Publishing Spring Events to Application Listeners

    • 48. Wrapping Up and Thanks!

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

How would you like to master what actually happens inside a Spring Boot application and start your journey with the most important technology to hit Java enterprise development since the Spring Framework itself was launched!

Well then this course is for you!

In this course we take you step-by-step on a fascinating journey into how Spring Boot applications work.  We'll uncover and decode the complexities of the following:

  • how to get started with Spring boot using Spring Initializr to create our projects and tap into the rich set of technology that Spring Boot offers

  • how to build our Spring Boot projects with both Maven and Gradle

  • how to run and debug Spring Boot applications in our IDE

  • understanding layered architecture in Spring applications with controller, service and repository annotations

  • looking at a sample Spring Boot application's code, seeing how it works together

  • understanding starter dependencies and how these let you access a myriad of Java technologies almost "for free" and wee how they work with Maven and Gradle's dependency resolution mechanism

  • decode how autoconfiguration works in Spring Boot looking at conditions, overriding and how to see what's going on!

  • use properties in Spring Boot projects through injection and see common and important Spring Boot properties you need to know!

  • explore how a Spring Boot application starts up by stepping through the code and seeing exactly what happens under the hood!

This is a course which empowers you by unlocking the complexities of how Spring Boot works so that you understand what's going on.  In this way you get an excellent foundational basis of Spring Boot understand that will stand you in good stead so you'll feel at ease exploring further and tapping into the amazing power that this versatile and powerful platform offers.

I'm so excited to teach you all about Spring Boot - so enrol today and I'll see you inside! ;)

Meet Your Teacher

Teacher Profile Image

Matt Speake

Principal Trainer


Matt Speake is a professional software engineer specializing in Java technologies. He has over 20 years experience working at small startups to large global corporations and is the principal trainer at Zention in the UK.

You can find him writing and recording about all things Java at the Java Easily website and also releasing videos on the YouTube channel at https://www.youtube.com/channel/UC7zPsQMhlU5LtEeMKpk8yxw?sub_confirmation=1

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Welcome to the Course!: Hello there and welcome to this course, which gets you acquainted with the essentials you need to know about Spring Boot. Now I've designed this to be a concise course which will give you the foundational knowledge you need to know to be able to start developing spring roots applications. And in particular, instead of this being a code along style, of course where the instructor types one thing and then you just return the same. Instead of this, this course concentrates on building up your understanding of how spring boots applications work and how they build on top of spring technology to provide a super quick and robust platform for application development. So what I actively encourage you to do is to use this course alongside reading up on the elements of spring itself that you want to incorporate into your applications. And in this way, you'll get hands-on practice in the areas of interesting. This is a course on just a Spring Boot and its operation. So we're assuming that you're already familiar with spring basics. If there are any areas, though, which are unclear, just shoot me a male in the Q and a section. And as always, I'll be happy to help you. We also have another course on spring foundations to which you might like to take before this one, if you're unsure of spring best development, right? I'm super excited to show you all about how Spring Boot works now. So without further ado, let's get started. 2. Getting Started - Section Introduction: In this first section, we're going to jump in and get our hands dirty as we see how to create a spring bruce application completely from scratch using the spring initializer website. This is a one-stop shop to creating your Spring Boot applications and comes with tons of technology ready to plug in C. Once we have the project generated from there, we'll see how to build it with the two men build systems for Java, Apache, Maven Gradle, of course. And then we'll look at how we can run our stars replication. Have a quick look at the layered architecture which underpins all spin best enterprise development. And I'll show you some spring resources you should know about too. So this section is all about getting up and running. So let's jump in. 3. Creating a Spring Boot Application with Spring Initilizr: In this video, we're going to see how we can create a springboard application completely from scratch using spring initializer. So first off, let's go to the spring initialized a website. So if we go into Chrome and so I've been start spring the IR. You can see it's daring my history already. And so here we are at the spring initializer website. So what this allows us to do is basically create a Spring Boot web app completely from scratch using whichever technologies you choose from the dependencies section. So let's just talk through some of these options. First of all. So first off, you can see we can choose the actual build technology of the projects we're going to use. And you've got two choices here. You can either use Maven or Gradle. If it use a Maven best project than that will come with a palm. The XML file in the root of the project, which describes the project object model which is coming in Maven projects. And if you choose a Gradle project, then the project will be generated with a build doc Gradle file, which again is the convention in Gradle based projects. In either of those cases, you end up with a build file which enables you to specify the group ID, artifact ID, and version of the application you are developing. In addition to an area where you'd specify the dependencies which are including into the project. So the project knows how to go out and grab those dependencies. There's libraries and frameworks from the Maven central repository or any other repositories you choose to add. And also what's nice is that both of these bill technology types come with a wrapper for the built-in logging question. This is basically a small starter version for the build technology, which effectively enabled you to bootstrap and installation of the build tools. And they'd be Maven Gradle locally within the project itself, such that you can then use that to build your project, which saves you from any up front work of actually having to install Maven or Gradle onto your local system. First, of course, if you do have Maven or Gradle installed, that's also fine. You can use that. But it's nice to have a rapper because then it means that everything self-contained and available in that one project. So that's the bill Technology section. We also have a choice of languages as well. So there are three languages supported with spring boots applications, and those are Java, which is obviously the most popular one, which the Spring framework, which Spring boot is built on top of what's coded in and designed for from the outset. We also have two other options, which are other JVM languages, those languages which provide a different programming syntax than standard Java that we're used to, but can still become pile down to the same target byte code that runs in the Java virtual machine. And there's a whole host of other JVM languages which are out there in the Java ecosystem, the scholar enclosure as well to name another to put spring initializer currently gives us these two options, which are the main ones we'd like to use anyway in terms of primary alternatives to Java. And yet those are Katlyn and groovy. So Collins, the programming language from JetBrains, which is a company that and behind the ID IntelliJ idea. And Groovy is more of a released, it's viewed as more of a scripting language because it's used in so many scripting context. For example, in Jenkins pipelines, putting continuous builds off or build scripts in itself. In Gradle for example, Imelda groovy is a much bigger language and it's personally the language that I favor most, but it's viewed as a scripting language. Nevertheless, it's been around for quite a while, much longer than cotton has, and it's from the Apache Foundation. Both Katlyn and groovy gives you a more lighter touch way of being able to develop applications than Java does. So those are definitely some alternative you might want to look up later down the line as you expand your knowledge of Java and programming in general. But yeah, it's certainly possible to design spring goods applications with Katlyn or groovy, with Java, of course, being the primary choice than most people, just because of Java's pervasiveness in the Spring framework and the development community around that. Underneath here you can see we've got the different versions of Spring Boot which we can use. There was an older version of Spring Boot before, which was the 1.2x branch of Spring Boot, but that's now been superseded by the two branch. So for New Spring Boot projects, you always want to use Spring Boot tool and above. And the latest stable production version you can see here is version two dot three dot one. Underneath here you will see the section where you can add the project metadata. So this is where you basically set up their group ID, artifact ID of the project. This means that in your local bill repositories the built artifacts. So JAR file, a WAR file or whatever you might be building, will appear in a directory which reflects that. So for example, if you're using Maven, it'll be in the home directory. Then a dot M2 directory, then endo M2 sub-directory underneath there, then repository sub directory, and the directory structure which is calm slash example slash demo. You can also specify the name of the project, a brief description, and also the package as well. So when the projects generated, you'll get started class which starts the application and bootstraps the springboard runtime, and that will then be placed under that package. You can also underneath choose the packaging of the project. So it was Spring Boot applications. You can either run them as a standalone JAR file. And how that works is that standalone JAR file is executable and he has an embedded version of Tomcat in there. The web container which your sprint with application runs in y can go for more traditional approach and packaged application as a WAR file, which can then be deployed into an external web container. Again, such as Tomcat or some of the more enterprise level ones like with logic server, webs, FieldGlass fish. For Java versions, you've got three options. Java eight, Job 11, or Java 14. So if you want to use the latest and greatest version of Java and all that entails, you can use version 14 if you just want to use and take advantage of Java as modularity system, modular system, you can use Java 11, since that was introduced in Java nine plus. But most folks are gonna be using Java eight. Also note as well as the minimum version required for spring bruce applications and actually for spring itself after spring version four and Java eight as a language version which supports the newly introduced functional programming stuff. So for example, lambda expressions, pipelines and streams, method references, that kinda thing. Now underneath this panel, you'll see the panel of buttons here. And there are three main options for this, depending upon what you actually want to do. So once you've filled in all these details. But we will talk about the dependencies section a second, since that's probably the most interesting part, because it gives us access to all the different technologies that we can possibly use. An a Spring Boot application, where there were three options here. So the first option is share. So if you click this link here, then what this will do is we'll take all of the settings that you put in here and just compacted into a single link that you can then email off to somebody. So for example, supposing you have somebody, you're working within your team, your tech lead, and you want them to NACA quick application to implement, say, a simple Java app that runs a schedule job every hour, for example. Then you could just basically fill up all these fields at the dependencies that you want to add and then just send them this link. And then what they can do is they can visit that link by clicking on it all, putting into the address bar in the browser and hitting Enter. And then they'll see that spring initialize a website with all the settings set, but you had before you send them the link. And that can be nice because it can save you having to send around zip files, maybe if they're not allowed. For example, if you count sends it files in a corporate environment. Because of firewall configuration or things like that. So it's just nice to be able to do that. So that's a nice feature for sharing initial spring initializer configuration. So you can close that by hitting escape. The other option is explore. So if you hit explore, then you basically gets a browsable view of the projects that he's going to put into a demo dot zip or acronym dot zip file for you. And you can choose, for example, to look at different artifacts. You can see here. Here we can see the pond XML file and the dependence is that it's added. You can see we've got the group ID and artifacts or any name and description, those kinds of things that the Java version that we selected before. You can go into and have a look at the source files that it generated will speak about those later. And basically have a look around and see what it's going to generate for you. The files onto editable by the way, but it's nice to be able to browse them and is also good as well. So for example, when you add an extra dependency or if you want to add a new facet to Spring Boot to bring in a different technology type. You can select it from the dependency section, which we'll see in a second. Go back into here, browse the pond XML file and then just grab the dependency and put it in your own projects has always nice to do as well. So we can close that off by paying escape, or you can just hit the button. Before doing that though, we have a choice to just download the whole project. Or alternatively, we can just download the individual file. So if I wanted to just download this pond XML file, I can hit download here only to copy the XML file to my clipboard. I can hit that as well. So just escape out of this. And finally we come to generate. Generate is basically what it's going to allow you to download the whole zip file. So the whole project in a zip file that you can then unzip and get started with straight away without having to set up an extra tooling, which we'll see. Now let's have a look at the dependency section. So this for me is the most interesting parts of the spring initializer application because it gives us access to all of the different technologies we've got in Spring boot, which pretty much is not just Spring Boot itself. It's pretty much the whole technology stack available throughout the spring ecosystem. So everything's in there that you could possibly want to look at, possibly want to include in your projects. So I just have a look here. So we're going to add dependencies. As you add a dependency, by the way, each time you'll see the dependencies added underneath. So we hit add dependencies. And now at the top you can see you can start typing to search for the facets that you want to bring into your project. So for example, if I know I'm gonna connect to a database and a relational database management system. I could hit GPA. And here it filters out to show us the spring data GPA dependency that we can bring in the so-called started dependency. That's not a dependency, is a dependency which brings in the whole set of dependencies required for a given facet of technology. So when I say facet, I mean kind of like broadly a specific area of technology. So a facet might be, for example, dealing with databases or dealing with a messaging system, killing very broad technology area choices, those kinds of things. So anyway, so underneath a we can see it's highlighted the one option now based on upstream that we've searched for which your GPA, it's pulled back spring data GPA. And there's a brief description here. So it says persist data in SQL stores where Java persistence API using Spring and Hibernate. So if you want that, just press Enter. And if you press Enter, it'll take you back out. But if you want to add multiple things, multiple dependencies, you'd just click add dependencies is if just hitting Enter. We can also do as well is when you're filtering these. So for example, let's supposing I filter on a tag this time. So SQL. And you can see here we've got a whole set of dependencies that we could add, which has to do with SQL. What I can do as well is I can press and hold down command at the same time and then click. So for example, let's assume that I want to have liquid based migration that could just go down here and I'm holding down command. And then when I click, notice what happens in the background. You can just about see it there, the y her, I'll pick one which is bit longer. Probably this'll MySQL, for example, Microsoft SQL server. So now if I hit command and press on the dependency, you can see here it's added, so we just escape out of this. You'll see that it's also allowing you to add multiple dependencies in Mongo. And you can delete dependencies and remove them from the configuration is by pressing these whiteness is each time you invite to Aunt dependencies, you can also hit Command B to do that. And looking at these different technologies, you can see that we have different categories available. So you can see developer tools. We've got web scrolling up, we've got template engines, security, SQL. So really, now it's really phenomenal that we're in a world where we can just like plug and play different technologies that we want to include an application and all the stopping you creating an app with these technologies is just really understanding how they work together and understanding the various APIs and paradigms behind them. So it's a really powerful place where we're in now with spring boots in the Java world, you know the fact that I can just create an application completely from scratch and it just runs out of the box, which we'll see shortly. Also minor things as well. But if you want to have a dark mode which is kind of nicer as you can choose this, for example, if you're working late at night humanoids to do that anyway. Okay, back out to, we'll have to add any independencies and we'd still get a Spring Boot application which works completely from scratch. So we'll just teach in a rate now to download them. Because it's downloading now. And at this point, we click into this. And I've been at the project. You can see here that all of this here is our Spring Boot application generated by spring initializer. And it's all ready to go out of the box. And they run and develops with and we'll see how to do that in later videos. 4. Exploring a Spring Initilizr Generated Spring Boot Project: In this video, we're going to see how we can use Maven. We are spring goods application. So if I get a Finder window up and look into Downloads folder, and here's a spring routes application I just created from the spring initializer website. And from there I could download the demo dot zip. So I downloaded that to my machine and then unzip it. And that gave me this directory structure here. So let's just lose a demo dot zip pronounce. We don't need it anymore. And let's just quickly talk about what we actually have in here. So this project inside the demo folder will run completely out of the box. So it's a fully functioning spring Boot application already. So this particular one is built on Maven. And we know this because we've got a pond XML file here, which is a standard build file you'll find in Melbourne based projects and infer project object model. And inside that Pando XML file, you'll see a description of what's required to make the project run and compile. So for example, if we open this that we've Sublime Text, you can see here we've got the usual suspects. We've got Group ID, artifact ID version, which are the so-called gulf coordinates under which this project will live in any Maven repository in the ecosystem. And we also see we've got some dependencies here as well, which we'll speak about later. But these basically bringing in the Spring Boot runtime infrastructure to make all the Spring Boot magic happen, which is also this parents section here specifying the parent palm, palm, the XML file. In addition, at the roots of the projects, we've also got these two files here, m, v and w, and v n w dot CMD. And these are basically the Maven rappers. So a rapper basically is a small distribution of a bill technology such as Maven or Gretel, which just enabled you to bootstrap downward and use the proper version or the full version if you like, the full distribution of that build tool. And this is available in both Maven and Gradle projects generated with spring initializer. But here we can see the Maven replicas we chose me as the built-in audio for this project. There's also a help dot AMD markdown file which will give you helpful links to Maven to understand how to build the project. To the Spring Boot Maven plugin Guide to understand how to use the specific integrations we have Spring Boot that the spring but Maven plugin provides and also about creating an OCR image. If you want to do that as well. So if we open up the source folder next, so if weight down old and then click, it'll expand the whole tree recursively silicon, see everything in one go. So if we just open this out a little bit, so we can see here we have three files which are into discrete, in separate source trees. So in this section here, in this source trees or source main Java, this one here, this is basically the production source Good. So in source main Java, this is the production application here, which is demo application dot Java, which is generated for us. And also on the source men per Salzman resources. These are the production application properties. So in other words, these are the properties which are gonna be supplied and available to the demo application when the application starts up. So we can have access to those boys, for example, doing property injection, which we'll see later down the line in the course. So everything on the source main, that's all to do with the production application than otherwise, there's nothing about tests. There are any throw-away code or any helper code that we might need just to check things out or test that things are working in that kind of thing. Everything that's under source men is gonna comprise the actual application that we deployed to production. So in other words, if you generate a WAR file, you'd expect to see demo application dot class and application that properties in the webinar classes directory. And similarly, we would expect to see those artifacts in a self-executing JAR file as well as a sibling to source men though, sibling to this one. In other words, it's on the same level. We can see we have a source test directory tree and specific and resource test Java. These are the test Java sources. So he can see a demo application tests or Java, which is basically an empty Spring Boot test, which you can then plug integration tests into. And just like we go source main resources with any properties that are production code needs. We could also have other, we'd have to create it ourselves a source test Resources folder with any properties that our test classes might need. But the main part about this is that this whole application here, comprising of just 1234567 files. The soil application just comprising those seven files, is a complete spring goods application with tests, Rawlings, one with the build tool, Rogan too as well, all ready to go. So everything under here now is runnable and buildable. And we can do that using the Maven wrapper, which we've just spoken about. And we'll see how to do that in the next videos. 5. Using Maven with Spring Boot: In this video, we're going to see how we can use the Maven wrapper, which is supplied by default in a spring Boot application, which has been generated by the spring initializer website. So let's jump in and have a look at this now. So if I get terminal up, and if I cd into my downloads folder And the demo project which has been generated, Let's just make this a little bit larger. Expand that and clear. So let's just double check. We have the project in here, and yet there's our project. And we can see we have two files which are of interest, which are these two files here, w and w dot cmd. And we also have a hidden directory. Hidden directory is start with a dot in Mac and Unix and Linux systems, and that's the dot m V1 directory. So if we look at what's inside the ambient directory, we'll see that there's a rapper folder. So if I go into this wrapper folder here, we can see we've got three files here. We have maven rapid dot jar, Maven rapid up properties. And you can't quite see it but Maven rapid downloaded dot java. So these three files together form the Maven wrapper and inertia. What happens is the scripts which are here. So this Maven W or maven W dot CMD, depending upon whether using a Windows system or a Linux based system, awesome derivative there ofs or for example, MAC, that depends which of these files are going to use. So maven W dot cmd is the one for Windows, Nevin W is the one for Linux based systems and Mac. And these files are basically aware of this directory and the execute this Maven rapid downloaded that Java, which looks inside the Maven rapid dot properties. And it will look inside that. And we'll see what's there. And what this file does that downloaded that we've just seen, uses the properties in here to download this specific version of m7. So you can see Apache Maven 3-6 X3 is the version of maven. Then it's going to download and install locally within our project. And it's retrieving that from you can see here the Maven central repository. So we've got an HTTPS repo Maven apache.org, Maven to what that means is that when you run them MW command for the first time, it's going to download and install that version of m7 into local project. And then as long as you keep invoking, moving through that command, it will continue to use the downloaded version that is placed in your project. So let's see that in action now. Say if I commend kay, to clear that, so I'm on Mac, so I need to use m, v, and w. If you're on Windows, you'll have to use M, V and W dot Cmd from a command prompt or a DOS prompt, which you can access going to the start menu and just typing cmd, which I'm sure you'll be aware of. So if I do dot m, v, and w, By the way, I'm prefixing it with a dot slash because I haven't included the current directory on my system path. So if I just typed in m, v, and w, because the current directory isn't defined in the system path, it wouldn't know that I was referring to the Maven wrapper which I want to execute. So I'll just put dot slash m, v, and w. Now for example, we could just type Spring Boot column. And so as part of the Pando XML file and started dependency, we also have a plugin that's been added to our project object model. Or you can't see explicitly Plug-in exists in the spring dashboards as its prefix. So you can see we're specifying a plug-in of spring dash Boot and the goal of R1. So if we press Enter there, what's going to happen now is the memory map is going to download the version of maven that requires an ac to kick off the build. And finally is going to start the application for us. And you can see here, it's done just that. It's, it's not a demo application in No.5 for four seconds, of course, because it was nothing for it to actually do because we didn't specify any extra dependencies in there. For example, to make it into a web application or anything like that. It just basically starts and then ends because that's how we get set up with the Melbourne Wrapper. If we clear this off with command K and then re-execute the command, we'll see that this time it won't download a whole heap of stuff. The reason is that now it's cached the dependencies which it requires inside the dot IMG slash repository folder. So on my system, for example, inside the home directory, there'll be MDM2 subdirectory and their repository sub directory. If I open that up, we can see here that these are all of the dependencies which are available in my local Maven repository. And in fact, if we look under org Spring framework, boot, which is a group ID for the spring with dependencies. So all of that spring framework dot boot, we can see here we've got a whole heap of dependencies which had been added. See if I extend that out. We can see here we've got Spring Boot and the version of sprinkler that we're using, we can just see here is version 231. So we can see here we've got the 2.3.1 release, which corresponds to that. And I haven't used Spring Boot 2.3.1 on this machine before. So you nitrified. If I click this, we should see that it's been downloaded just now. So today at three o'clock and I'm recording this. You can see here it's just being downloaded Now. See, that's why those dependencies and L safely cashed in our local repository. And once you have this setup command cages to clear that, once you have this setup, we can now execute any Maven commands which we're familiar with. So for example, M, V and W, clean, which will clean the project. So you can see here it's deleted. The target directory which the Maven build process would compile source artifacts into today, bill versions S other class files, for example. Or I could choose to compile the source code. Okay, so now we can see compiling one source file again to the target directory and so on. So anyway, if that's a good overview of how we get started with the Maven wrapper and how to use Maven with a Spring Boot project generated from the spring initializer website. 6. Using Gradle with Spring Boot: In this video, we're going to look at how we can work with the Gradle wrapper, which is provided with a default spring Boot application created with the spring initializer website providing, of course, you've chosen Gradle as they build technology you want to use. So let's go into terminal. I ever just increase that size and maximize it. If I go into my Downloads directory, then we can see here a demo projects which have just created with the spring initialize a website. It's on the project's doesn't have any dependencies in it. And it's just got all the default settings to the spring initializer website provides deliverance being absorptive from using Maven as-built technology to using Gradle instead. So if I just see the into here, here we can see the contents of the generated project. So we can see we have a build.gradle file in the root of the project. So let's open that up in sublime text and just have a quick look. So this defines the usual things will expect to see or expect to see. So the group ID and version that Java source compatible in which here is 1.8 repository that's gonna use to resolve dependencies which are standard is the Maven central repository located at Repo one dot moveon.org. You can see some plug-ins we should project also uses to provide integration. We have Spring Boot itself, which we'll see in a second test section, which has this using JUnit. And finally a dependency section where the Spring Boot started dependency and also test dependency just so that it can access a Spring Boot test framework to enable us to do testing as well, out-of-the-box. So if we close that and go back out to terminal. So let's discuss what we have here as pertaining to Gradle. So we can see we've got a settings doc Gradle file which defines global properties. If we have a multi-modal project, which is project isn't, it's a single level, top level project. But nonetheless, most Gradle projects have a settings not Gradle there anyway, just to facilitate the move into multimodal projects if the project evolves in that way, we also have the build-up Gradle file, which we've just seen, which defines the actual configuration to do the build itself with Gradle, to build a project and be able to run it and that kind of thing. We see two scripts which are Gradle w and Gradle w dot Pat. And these are basically Scripts which we'll use to invoke the Gradle wrapper, which enables that wrapper to download the actual real griddle installation locally into our system, such that subsequently whenever we invoke riddle commands through these scripts or through either script which you're using. It will use the downloaded Gretel distribution, which will wrap a setup for us. By the way, as far as these two scripts go, we have two scripts for the two different operating system flavors. So if you're running a Windows machine developing with Windows, you'd use Gradle w dot bat from a DOS prompt, command prompt. And if you're in the Linux world on Mac or Unix, you'd use Gradle w. So yeah, those are the two scripts there in general, you'll be using to do the Gradle builds to build your Spring Boot project with. This leaves us with just one more artifact to talk about now, and that's the Gradle repository which is here. So let's just have a quick look inside there. So if we open up our Gradle directory, we can see here that we have a rapper subdirectory. So if we click on wrapper to get into that directory, we can see that we have two files. We have Gradle, wrapper, dot, jar and grid or rapid properties. So if we just have a look at Gradle rapid at properties. And look at this alongside the contents of the folder. So what's going to happen is, and how the Gradle wrapper works is that the first time you invoke Gradle command through one of these scripts. So Gradle w or Gradle w dot bat. It's gonna check and see if you have the Gradle version it specifies in this.properties file here is going to check if you have Gretel 64, one bin dot zip. And if you don't have it, it's gonna use the code inside here, acquittal rapid or jar, to basically download this distribution which is here. You can see that services Gradle.org distributions and then this distribution filename. And it's going to unzip that then into griddle user Home, which is a doc Gradle folder under your user home directory. So on Mac that's tilda Slashdot Gradle, and on windows in my B, C colon backslash uses and then your username in the latest versions of Windows. And it's going to unzip that insulin wrapper disks folder under a subdirectory of the same name. So Gradle six dot 4.1a. So this wrapper mechanism is nice because it means that you don't have to set up the bill to yourself when your system, this rapid mechanism is gonna take care of downloading the version which the project requires and installing onto your local system for you. And it's always going to use that same version. That's nice because particularly with Gradle, sometimes you can run into issues where because of differences in the Gradle DSL, the syntax you use to create Gradle files because of differences in syntax between different versions. Sometimes you can get some very obscure errors in Gradle, and it means things just weren't built the way you expect in the best-case and worst-case, they've just won't build at all. So it's nice to always have a consistent version when you're building your projects. And this rapid mechanism gives you that facility. So let's clear that now. Now we've command k. You can also type clear and hit Enter or CLS on Dawson Windows Control L in Unix. And now we're going to use the Gradle wrapper to run the Spring Boot project. So it's Gradle w because I'm on Mac, that's the version that I need and I'm prefixing it here. You can see we have a dot slash and that's because I don't have the current directory which is represented by dots. I don't have that in my current path. So by prefixing it with dot slash, I'm telling the system to look for that file in the current directory, which is where it is. And then the command, we're going to use his boots and run. And notice it's camelcase here as well. So Boot R1 is basically the task which is made available to us from the Gradle Spring Boot plug-in. And it allows us to run a Spring Boot application. So if I hit Enter now, you can see I didn't have this specific version of Gradle, so Gretel 64 when I didn't have it on my system. Now it's downloading them from services.net or.org in that location there. That'll take a few moments. And now you can see it's building the project. So behind the scenes it's actually downloading all of the dependencies which the project itself needs, which are the Spring Boot started dependencies included in the project. Although it's not as obviously is doing that as it will be with a Maven build. For example, Nevin tends to be very verbose with its output. Whereas the newer versions of gradle output, the progress messages on the same line, pretty much, which keeps things tidy up. And yeah, it's finished. So now you can see we're using Version two dot three dot one of Spring boot, and it started a demo application. He is the Started demo application in zero-point for five seconds. And in this particular demo application, I didn't include any other dependencies. So Because I didn't include any dependencies which would have caused the application to keep running. So for example, if you're developing a web app and include Spring Web for the spring web MVC stuff in your application that when you do a boot run, then it would keep the application going because it's a web container. So it keeps him willing to actively listen and report, which by default is 8080 to listen to web requests or HTTP requests. Because I didn't include anything like that in my dependencies. The application just starts up and then it finishes, which is fine. And it's what we expect. Now if I commend k and if I do that command again, we'll see this time it'll be much quicker. And you see it's just a few seconds, actually 1 second new fact. And the reason being is because it's already downloaded that Gradle wrapper. So that distribution we saw downloading before. It's already downloaded that it's already using it. And furthermore, it's already got the dependencies which it requires in its local cradle cache. So if we command K again, let's just see where it is installed. Gradle distribution seems if I look inside the doc Gradle folder in my home directory, you'll see here we've got a wrapper. If I open that up, which is probably a better way of looking at things, then you will see or have a rapper, some directory here and a distal subdirectory. And if I just open this up now, you should see the inhere this specific directory. Then this is the actual grill distribution. Nice downloaded. See if I go back out. I if I just right-click and it gets info. You can see here it's open for the July 344, which is if you look here just a few minutes ago. And it's done that because I didn't have that specific version of Gradle on my system. I did have other versions. As you can see, I didn't have that specific version. It's nice because it means that through this mechanism you're always gonna get the exact version that you need. And also it's gonna reuse and make available. These are the versions for other Gradle projects. And the reason for that is because it's not stored inside the project itself. Instead, it stored it inside the doc Gradle folder in your home directory. If I go back out and then jump up to caches and go into modules two, and then files to one. So it was a bit strange and Gretel with these strange-sounding folders, mavens much more straightforward, this dot M2 slash repository folder. However, if we go inside caches, modules tomb files to one will see that these are all of the dependencies which exist in my griddle repository. So if I maximize that, and for example, now if I look for 4G, see OLG Spring framework. Yet all spring from o dot boot. That's where all the Spring Boot dependencies live. And we can see here Spring Boot and we can see 2.3.1 release. And if I go back out and re-run the app again quickly, you will see that here we're using 231 release. Here it's downloaded 2.3.1 release. And also for it get the info and then you can see here that it downloaded shortly after we downloaded the Gradle wrapper as well as 345. So now at this stage, the rapper has downloaded the Gretel distribution that was specified in the project is cashed out. It's available for future invocations of Gradle and the Spring Boot dependencies are downloaded to. Say if I close down and close down the command key here, I can now just execute gradle commands like you could do in any regular Gradle based projects. So for example, I could choose to clean the project. When, if I look now, you will see that there's no build folder. So normally with Gradle projects, you have a build folder where all the built artifacts are placed. So for example, class files and resources generated artifacts, that kind of thing. I can again Command K and I could choose to, for example, compile Java, which would compile to production Java source code. So that's done that. And now if I look, we can see we've got that built folder here. And we can see if we look inside the Build folder. Meso class file of the Spring Boot production Java application. Say yeah, that's a nice introduction to how you can get up and running using the Gradle wrapper and the Gradle build tool itself to work with your Spring Boot application projects. 7. Running and Debugging Spring Boot Apps in the IDE: In this video, we're going to see how we can open up a Spring Boot project in intelligence idea, the popular Java IDE, and demonstrate how we can run the application and also how we can debug the application so we can step through it and see exactly what's happening within the application itself. So first off, if why open up idea? So I'm using intelligent idea, Community Edition 20.119, which is the free version. You might be using, the ultimate version if you're working for a large organization, which has a few more features. But this is perfectly good for starting out with an in general for day-to-day development. I'm a professional Java software developer and actually I've never bought IntelliJ idea Ultimate Edition, although I've used in other companies which are provided it, but this is perfectly adequate for most needs. So I have a basic demo projects which are generated with the spring initializer website, doesn't have any dependencies in there. It's best on Melvin. Let's just open it now. Say if I go to open an inside my downloads folder doesn't demo project here you can see where the pond XML file. And if I just click the, the XML file and open that it's going to open it as a project if you choose this one. And what that means is it's going to interpret as a Maven project, which means that the Maven plugin, you can see here has been initialized. So if I click there, you can see that gives me an overview of the lifecycle. So those are the different phases that I can execute as part of the default build lifecycle. And you can see I've also got plugins, which are there particular plugins that this project is going to use. And a particular interest in the Spring Boot project, of course, is a Spring Boot plug-in here. But if I open up that, you'll see the actual goals I can execute on that plugin, which effectively gives us helpful build targets we can call to work with Spring boot camps plus m. And then we can see we've got dependencies. It's all Maven projects have a dependency section. And you can see here this particular project. If I just go over here to the project explorer and double-click to open upon the XML file. You can see here I have two dependencies which are explicitly included in the dependency section. Spring Boot starter, Spring Boot starter test. And you can see here that corresponds to these two here. So Spring Boot starter, it's been bootstrapped the test. And what's nice about this view as well as if I open up one of these. So for example here, you can see that under Spring Boot starter, underneath this dependency, These are the dependencies which it depends on c, you'll notice for example, Spring Boot starter also depends on sprinkle five to seven because 2.3.1 of spring bu is based on five to seven of the Spring framework. And in turn, spin core for example, brings in spring Jesse L, which is its logging library. And in fact, if I close that, I go over here into external libraries, we can see the full collection of libraries that have been brought into this project through just those two top-level dependencies. So Misha's close those and quickly demo how we can run the project them. So we can run the projects by double-clicking the Spring Boot run goal of the Spring Boot plug-in in the Maven pens. If I double-click there. You can see now that when the application, Of course, the application doesn't have any dependencies in there which would keep the application running. So for example, a web dependency, so closest straight away. But nevertheless, that's one way how you can run a project. And other waived if I close this off, is to go inside source, main, Java and look for the actual demo application. This is the spring of application itself. I, if I just right-click on there and do run demo application domain. And this time it's running the application, but it's not running the application through M7 itself. Instead it's running it through this command line here, which you can see. Similarly, if I wanted to debug the application instead of running it, then I could just select to debug instead. So if I just open disappear, for example, and set a breakpoint here. So the debugger will stop at this point when we're running in debug mode. If I right-click and go to debug. Now you can see that we're actually debugging the application. So here you can inspect any variables. So for example, here are the dogs that passed him, of course are no arguments passed in. So this is why this is empty and you can double-click on it to expand or see any values. This is where you have a coal hierarchy, which shows you the sequence of coals leading up to the current call. But of course, since this is a main method, is the top-level method and an application, we only see one so-called stack frame here, or one call here, which is inside this class demo application itself. And we can also see as well the threads used in the application. So here we're just effectively got one thread which is a consequence to us, which is the main thread. So things you can do once you are in a breakpoint, you can either step into code. So for example, if I hit F7 to step into, you can also see this as well. If you go into R1, you can see the various debug navigation shortcuts you can use here to find you step into with F7. And that's now stepping into spring boots card itself. And you can see here we've got an extra frame now because we've made an extra course and our insights spring application, you could do F7 again, for example. Now we are in another method which happens to be in the same class. And you can also press F8 to step over the current line, which basically executes that line and goes to the next line. Or if that line is the last line in a method, we'll jump back up to the calling method and you can do Shift F8 to jump out, a method to jump back out to the caller and effectively play the rest of the method you've actually stepped into. Or you can hit F9, which just means run the rest of the application from here, which I've just done there. So in one step through the Spring Boot application code, the framework, or that is now because obviously we don't wanna get too carried away with things and we don't want to run before we can walk. But I was just a nice introduction. Or you can run and debug your spring two applications in the ID using intelligent idea. 8. Understanding Layered Architecture in Spring Applications: In this video, we're going to talk about how we can structure an application in today's modern Java world of Enterprise Application Architecture by looking at the different layers which we typically have in an application and just talking through what we'd expect to see. So if we first off goods your idea. And here we have a demo projects that we just opened up this project. So source, main Java package and demo application. So we don't have any code in here now, we're just going to create a few skeleton classes just to see what learning looks like in a real world application. So typically what you have in an application is you have different layers. So each layer is responsible for a different technical aspects of the application. And so I'll just put packages in now to demonstrate this layering. But for example, you might have layers such as packages, such as web, business data, for example. Now the actual names of these packages might change. Sometimes business might be called service or services. Sometimes data may be called persistence or database or db, what might be called web, or controllers, or presentation or something like that. But the key parts are that typically in a web-based application which is splits into lead architecture, you have a controller. So here we'll just see we got a controller. And the controller will be marked with the app controller annotation. And inside this controller, it'll basically need to access the layer underneath, which is the service layer on the business layer, to execute the actual business logic that we'll ever fulfills the needs of whatever web request that comes in. So for example, here, you'll see we've got a service and we don't have a service and the millets delicious create that for example. So credit class my service. And this isn't going to exist in the presentation layer. Instead, this is going to exist in the layer underneath, which is the business layer. Now the service will be annotated with announced service sanitation. And we'll encapsulate the business logic of whatever needs to be done. And in order to execute our business logic, and it's gonna delegate out itself to a repository. So for example, here we can see with a repository, and again, that's going to be also a wired in. And that's not gonna exist in the business layer. It's gonna exist a separate layer, which is in the data layer. And this is going to be of type repository, so it's gonna be annotated with Repository notation. So going from the top we have a controller which has also widen through dependency injection access to a service in the layer beneath. And then in turn that service, which is in the business layer, as we can see here, has dependency injected into a repository. And that repository in turn lives in the data layer. And that's gonna be responsible for doing the actual database access logic. So what we're really seeing here is the fact that the controller only knows how to deal with things at the Presentation level. So only knows how to interpret HTTP server requests, how to produce HTTP cellular responses or whatever abstraction the framework you're using, like spring and vc, for example, might use to represent those concepts. And there is no business logic in here whatsoever. That business logic is contained inside this business or service layer in separate services, which can be injected into this controller. But it doesn't have to have just one service. It could be many different services injected into our controller. And also there can be many different controllers as well, serving different types of use case for end users. So you might have a controller for placing orders, like an order controller, my over controller for looking at the product catalog, some kind of product controller, that kind of thing. But ultimately the business logic you have for being able to return product catalog views to the user, to be rendered in the browser, or to place an order for a product, those kind of things. The logic for that will be done in the service layer in individual services. But similarly, that service layer will just contain business logic. And it doesn't know at all how to communicate with the database. Doesn't know anything about the actual structure of the database tables or anything like that whereby the entity relationship model, that's the responsibility of the data or persistence layer. And that's gonna be coded in individual repositories. So in the repository, you'd expect to see methods in here, like find all products or find products by ID, find products by name, that kind of thing, or save order and things like that. The advantage of lead architecture as well is that because you don't end up polluting an individual layer with any concerns of the layer beneath. In other words, because we don't have any business logic which is leaking into the controller. Or we don't have any data access logic which is leaking into services because we have a very clear separation of concerns. And we partition things off into very discreet and very well-defined layers. Because of this, it means that we can actually swap out layers if he wants it at a later date. So for example, women that you might be using a relational database store for a particular repository, for example, the product catalog. And then supposing your product catalog really grows, really balloons up and this becomes huge. Then it might make sense to move away from a relational database model because the database you're using, maybe it's creaking under its own weight, maybe using SQL Server. And there's just too much information in there. It's not really working. And you might decide you wanna go to a no SQL store, or you might want to go to like a big datatype in that aspect, offer the service you might, instead of just making plane villa calls out to repositories, you might decide that you need to have some kind of big data batch repository instead. And layering gives you the flexibility of being able to swap one layer out and replace it with another layer, providing you stick to the same interface. And that brings us to the other thing as well. We can also put interfaces around these objects. So typically you'd have an interface for each service, interface for each repository, interface for each controller. So they can have that facility to be able to just Programs at the interface and that allegedly swap out for different implementation as an integral application develops. Anyway, that's a very quick overview of how learning works in enterprise applications. And now you're in a good position to be able to understand and start developing your own enterprise apps. 9. Important Spring Boot Resources You Should Know: In this video, we're gonna talk through a few key resources that are really useful to know about when you're starting to learn about Spring boot. So let's jump into crumb. I'm first off the main spring website where everything is located at Spring de ir. So this is the main website for all the spin projects. So not just spun boom, but all the other projects to Silver Spring framework itself. Other projects which deal with different technology areas, for example, spring integrations, spring batch, and that kind of thing. So it's a really good place to look at because it's the home of spring. So you can always find whatever documentation hereafter, pretty much by starting at Spring the iron. Anyway, if you jump into projects, you'll see. And we have Spring Boot. Yeah, so just click on there. And then this takes you to spin boots home. So this is the main website for Spring boot. And you can see here you've got three tabs. You've got overview, learn and samples. So the overview is nice specific about just taken a few small steps to get started. So it was a quick start guide here, more general guide about how to build an application with spring and spring boots and a son talks and videos, which will also useful if that's useful to start off with, to get some background context of that kind of thing. If you're more involved, are getting more involved. If you go into the Learn tab, then I recommend you basically bookmark to links in here. So you can see here we have all the different versions of spring boots or 231 is the current one. So whenever you see currency means the latest version, and whenever you see Ga means generally accepted, which basically means the most stable version that you can use. So it doesn't have experimental features, is not bleeding edge nightly build. It's just basically the general release if you like. So the generally accepted version. Anyway, there are two links here. There's reference Docker, API docs. So if I just hit command while clicking to open them up in a new tab for the reference doc and also for the API doc. And then we can have a look at those as well. So go into the reference documentation. I do recommend you create a bookmark for this so you can keep going back to it and referring to it as you learn more about springboard. So as you get more into the technologies, you can see here the men sections for me and the men such as don't recommend, we'll be getting started first of all, so you can have a look at that, but then actually using spring bumps. So then we're looking at build systems, how to structure the code configuration and how Spring works under the hood with beans and dependency injection, those kind of things. Spring Boot features which cover, as it says, things like profiles, logging, security and caching. So basically the main enterprise development features if you will, and also some useful how-to guides there as well. And then jumping back up to here, this is basically the Java doc or Spring boot. So if you ever need to get into the code itself and have a look through the individual components that Rotter configured, that kind of stuff. Then you'll find all of those classes in this particular section. So you've got all the packages of Spring boot, the classes there as well. And if you click on a particular class, for example, then you can see here underneath you'd have the methods which detail the input parameters and the return types which are passed yet, but it's always useful to have as well. Oh, it's more advanced use of Spring Boot if you're going into the actual code level because most of them it's just auto configured anyway. You don't really have to dip down into those kind of areas, but it's useful to see how it works under the hood. Going back to the first tab to the men's Spring Boot homepage and going down to the third tablet. Something interesting behind here, because basically spring initializer, which we've seen before, which enables you to create Spring Boot projects from scratch and then download them that initialize a website located at start dot spring the IR. So I'll just show you that here. Start that spindle here, just to refresh your memory. This website which we've used before to be able to create spring with applications with different dependencies on different bill technologies using different languages, that kind of thing. This website actually powered by Spring Boot, and it's available down here in the initializer project. So you can actually physically check out this project and run it as a spring grew application and step through the code to see how this particular web app is designed, developed, and see how it runs, as useful as multiple lookup. So the main points always make sure the minimum, you've got this dual spring boots documentation homepage in your bookmarks and feel free to book might be the ones as well, and to reference those materials as you go on learning more about spring and spring boot and you Spring Boot journey. 10. Tour of a Spring Boot Application - Section Introduction: So we've seen how we can get started creating and building Spring Boot projects. So now it seems like a good time to look at an actual proper project. So in this section we're going to have a deep dive into spring pet clinic, which is the main demo projects and technology showcase for Spring boot. So let's dive in right now and explore it together. 11. Downloading Spring Pet Clinic: In this video, we're going to look at the conventions that are used in a Spring Boot application and spin boot project. So to do this, what we're gonna do is we're going to look at the pet clinic sample application, which is one of the demo applications for Spring Boot. And we'll just explore that project structure and we'll talk through some of the conventions that we see. So first off, if we go to github.com, spring projects and we're looking here. These are the main spin projects which we have in the spring ecosystem. And if you just go down here and find the repository and search for pet clinic. And you can see here we've got spring peck clinics, it is. Click on that. So this is a demo application which uses best practices for Spring Boot. So we're just going to download it. We could chlorinate with get. We can also just as well download the zip machine to Auckland with given instead. Why not copy and paste them and go into a terminal session. A little bit bigger. So go to the desktop. And we're just gonna do a git clone pasting in that URL. Now it's floating the repository locally. It's so We should then be able to go into a directory. It's made hold spring pet clinic. And here we can see the project itself. 12. Building the Sprint Pet Clinic Application: So we can see because we've got the Maven wrapper and we'll just be able to build this project. So close out this m, v and w. And we're just going to call Package, which is going to create the runnable artifacts, which is a standalone java. So I can see it's downloading penances and needs to be able to do the build for the plugins is using. And then shortly afterwards it will download the dependencies for the project itself. And then I'll do the actual build. So that took a while to do. And if we run it again, we'd see that it would just do a straight build without downloading all the dependencies and initializing all the plugins and everything. So once you've done it once and Joe Maven, local repository cash is primed with the dependencies that it needs and it was a libraries that the Spring Boot application is going to use. You don't have to do anymore. Which is in this time, you did a full build in just 19 seconds. Second time around. 13. Running the app and taking a tour of the application: So let's just run this application so we could do Java minus jar. And basically when you do package inside the target directory, which is where all of the build artifacts go. In a Maven project, you'll see this should be a JAR file there, which is named after the project's names here we've got spring tectonic 2.3.1, bills, snapshot jar. And so if we run that, it's a self-executing job by the way. So we can just run it with Java minus jar. If we run that. You'll see the pet clinic application starting. And here you can see it started successfully. So whenever you see Tom caste started on ports, have you seen that message? And started then the application name, you know that the application started. Okay, so then we can just go then into local host 8080. And here we have it. This is actually now the pet clinic application that's running in this window here. On 2.3.1 release of Spring boot. Quick tour of it, we can find vets. So these are the list of events which we have in this fictional peck clinic. We can also find donors. You can click find owners. And these are all the honest own pets. So we can click on Eduardo Rodriguez for example. And this lists the pets and the visits. Who's got to pets, Joule and rosy. We can see both dogs, dog and dog. And we could either edit the pet here to change it to a hamster. For example, update the pet hamster. You could add a visit. See general checkup. For example. Visit. He received what was visit? General checkup on the third of July and go back to Han. So it's a very simple application, but nevertheless it's meeting of, for you to be able to have a look through and see how all the different technologies hang together. Or spring web MVC For example, springing ORM spin JDBC or that kind of stuff. 14. Examining the project and it's dependencies in the IDE: So let's take a look now, Lord the project into intelligent idea and take a look around and see how it's structured. So if I close this and you stop this causes two and jump into idea. So we'll just open the project desktop, spring pet clinic and points in the pond XML file just to open. Open as a projects, not as a single file. And it's basically preparing the project, doing some indexing is done. So if we jump into here, you can see here's the project spring pick clinic. And we've got a source main Java folder. So with this being a Maven project, our production sources run the source main Java, which has signaled by this blue folder here. And similarly we have got a source test Java folder signified by the green folder there. So anything green is test, anything blue is production in idea. So you will see that the test sources mirror the production sources in the respect that, for example, if we look inside system and welcome controller in the production sources and then look inside the test sources. We can see we've got under System crushed controller tests, which corresponds to the system crash controller then protesting for everything. They've just put a few tests to, to give you a flavor of what testlet like in Spring Boot. Key point here is though that the tests exist in the same package as the production class that the testing lives in. And guess and that's testing. Here's the production sources live in here. We've got a pond XML file, which is that the root of the project, which describes the project object model. And inside here, we've got the dependencies. So these dependencies, you'll notice they all start with Spring Boot starter dash. So these role, so-called Spring Boot started dependencies. And what those are are basically dependency holders, if you like, which bring in different facets of a certain technology and allow them to be used in the application. So for example, here, this is bringing in springs caching abstraction. Here, this is bringing in the ability to use spring data and GPA. This is bringing in spring web, so we can use Spring Web NBC with the dispatcher cellular mechanism, that kind of stuff. And so they all follow this convention of Spring Boot starter and then the actual facet Nim. And these correspond as well to the same dependencies that you can introduce when you look at the spring initialize app on start dot spring to iron. Okay, so that's the main production dependencies. We'll see. We've got some standard dependencies here for testing. We're using JUnit Jupiter, which has unit five with Mockito to allow MOOC best testing. We're also including Spring Boot dev tools. So that's to enable a more rapid development workflow. So without having to like do code changes, stop the server restarted, are willing sprinkled application with this dependency installed will detect those changes on the class path and automatically restart the app by refreshing the context. So there's more stuff here in the file is not too much stuff that's not interesting. And mostly stuff you can just pretty much leave as it is really to be honest, when you developing springboard applications, you really just concerned about adding the dependencies. So the Spring Boot started dependencies and any extra third-party things you might need. So for example, JDBC drivers, that kind of thing. 15. Examining the controllers and web layer: So let's have a look at the actual code itself. So if I look for controllers in the project by using, for example, this regular expression here, we can see that we've got a few different controllers here. And the way they've structured this application is instead of having packages for the actual layers of the application like we've seen before. So instead of having a presentation layer, a business layer, a persistence layer, you'd have your controllers, services, and repositories respectively. Instead of doing that, what they're doing is they're kind of grouping it by the actual domain objects instead. So for example, if we look at the vet, we can see here that's a handle vets. We first off got the vet controller. So what I mean by this, by the way, is the fact that they have all artifacts across all layers under one package, instead of having packages which separate the layers, they've done it this way, which is OK. It's also another style of doing things. And arguably at least you can keep things together than as well. So this is all to do with processing of vets. So here we've got the vet controller. Here you can see it's annotated with a controller, which shows that it's a controller. We've got a vet repository, which is also soundness as well. And then these are spring and VC methods here annotated with these annotations to provide the mapping. So we've gotta get mapping here. When the browser requests slash vets dot HTML, you can see it's gonna create the vets domain object, put things in the model, and then returning vets slash embed list. So we're going to look inside resources and templates. And then we'll see is gonna get the vets, that list. So it's going to return this time leaf template in them. So in this case that just returns a string which is an identifier used to retrieve view which resides on the resources templates. And then this path which is here. And then they get mapping as well is to slash vets. So slush vets, again, it's gonna create the vents object, get all of the vets by delegating to this, which is actually the repository and doing a fine doll. And then it's gonna return all of that back as a response body. In other words, inside vets, this is actually, if you look inside here, findable to an XML representation. So X naught root element is Vets an XML elements and list of vet. 16. Examining the repositories and data layer: Jumping into repository. We see that this is Repository which deals with vets objects of classes. The vet class, it's key type is integer. And on this particular repository just has one method which is findall, which returns a collection of vectors. And because it's extends the spring data repository, then the implementation of this is dynamically generated and just available for us out of the box. Also, you'll notice as well that it's cacheable. So this is hacking into Springs caching framework. And how this works is that this string which is passed in here, establishes a so-called cache region, which is effectively a map. And what's inside that map is going to be a set of all the different responses on the, all the different combinations of keys that come in are rather request paths that come in. So because the requests Parthia doesn't change, then we'll only have one collection of vet inside this vets cash region. But it just means that the next time when a request is made to this repository is just gonna return it from the cache instead of going back out to the database. Okay, let's have another look around. Everything else. It's interesting. Okay, so let's close those down for now. And these two. 17. Examining the startup of a Spring Boot application: Okay, so we've had a bit of a look round. We've seen the controllers, the repositories, and the pond XML file. The hearts of the application where everything starts from is from this peck clinic application here. So all spring will applications start like any other job application with a public static void main method. And inside that method, we use the spring application.rb. I'm passing the class reference to this class with any arguments as past and crucially annotates it with Spring Boot application was sprinkled application does behind the scenes is it's actually a combination of three different annotations. If we command click into this, we'll see that includes Spring boot configuration and enable auto configuration and components scan. And so in a nutshell, what that does is sets of components scanning under the root package, which is this one here where the men spring Bu application class is found, enables properties to be passed in and to be absorbed from the environment and made available to the application. And enables this auto configuration mechanism, which is really where all the magic happens. And we'll look at that in the next videos. 18. Examining the application properties, logging configuration and profiles: We also have application properties as well. So as an application dot.properties file, which will always finding the source main and resources is the standard properties file. You can see that just name equals value pairs. But one convention we have in spin will applications is that each technology facet that we use registers a specific prefix. So for example, spring data registers, spring dot data sources its prefix timely. The template engine reserves spring dot time leaf as its prefix mis for spring GPA, and so on. And they underneath, underneath these actual properties, we've got something slightly different, may appear to look the same, but it's not really, this is basically where we're configuring, logging in the application. So we've Spring Boot. You don't need a separate logging file. Instead you can register the categories are loggers, does the individual packages or even classes that you want. Second figure logging on. And you just prefix them with logging HDL level. So login dot level dot, and then the package name, and then the level that you require. So for example, here, as we said, if wanted to go into, see more debugging in what's happening in spring and BC spring web, we could just enable this line here. Now it is also possible through springs profile mechanism that you can have a profile specific set of properties. And that's what we're doing here. So in addition to our application dot properties, you can also have application dash and then a profile ID dot properties. So if we click on here, what this is doing is this is actually overriding certain properties, which are the default properties if the MySQL profile is enabled. So for example, here we can see we've got database equals h two. If we pass in a MySQL profile when we run the application, which we can do by passing in a spring dot profiles to active flag, where there is a minus D switch, mortar, an environment variable, or by whatever other means. If we have that, then you'll see it changes and overwrites the database to be MySQL. And similarly as well, spring dot data source dot URL is that in a MySQL profile? Otherwise is not specified if it's running in the default profile. And that's because Spring Boot sets up an embedded H2, so it doesn't need to have this URL suggests an in-memory when does a few other things as well? Was a.gitignore suffer when you're committing files under version control using gates. For example, ignore anything under the target directory because that's where the built artifacts GO. They shouldn't rejecting middle also ignore some MID specific files and folders. So for example, these its deal with Eclipse, the zoo with idea. And these have a Visual Studio Code. 19. Summing Up the essence of how a spring boot application works: So anyway, that's just a quick look to get a feel for what's inside a spring, we'll application. And as you can see, there's not actually that much. They're really in terms of infrastructure code. So boilerplate code to, for example, set of database connections or connection factor's rather or view resolvers and that kind of thing. Everything's done by convention as opposed to configuration. So it is convention over configuration idea. In nutshell, in a Spring Boot application, you just include the starter dependencies that you're interested in to bring in the technology facets that you want to use. There'll be a set of properties which are configurable for that particular technology facet which you can push into your application.properties file of your application to customize it. And because we have an application with an app Spring Boot application annotation that configures components scanning, which picks up classes annotated with that component service at repository. That controller. And that configuration makes those available of spring managed beans. And it also has the app enable auto configuration as well, which introduces other technology facet specific configuration classes, again, annotated with that configuration where the actual individual spring components that the technology facets bring in are initialized. And those are initialized conditionally based on analyzing glasses which are available in the classpath or beans that are present inside the application context. And that's pretty much power Spring Boot application works and another view of it, and we'll see more in the next videos. 20. Understanding Starter Dependencies - Section Introduction: The foundational parts of Spring Boot, which gives it its ability to pull in the text stacks and libraries that it needs, those of you select in spring initializer. This is done by the starter dependencies available in Spring boot. So to understand how Spring Boot projects can pull in all this cool, shiny technology, we need to get a handle on how that works. So let's explore this now in this section. 21. Understanding Spring Boot Starter Dependencies and their resolution: In this video, we're going to look at how the starter dependencies work. So spring boots based on started dependencies is concepts of having dependencies which can bootstrap and pulling certain technology facets. And it works pretty much by exploiting the dependency resolution mechanism and transitive dependencies, which is common in the two main Bill frameworks today, which is Apache, Maven and Gradle, and also IV as well, which is another dependency management system. Although it's much less used, that's actually used internal inside greatly itself. So to understand what happens, let's jump into Chrome and let's go to start that spring ion. This is the spring initializer website that we've seen before. And what we're gonna do is if we just go, we're not going to Adelaide dependencies for now. We can add extra dependencies if you want to. And what I'm gonna do that for now suffice escape there. We're just gonna explore the existing project. And this is a Maven project we'll see. So we're going to explain the Started dependencies in terms of Maven. So if we just hit explore, then we'll see that the first file it takes us to is the Pando XML file. And this is the build file for maven, the standard Bill file, which defines the project object model. That's basically a representation of the project, which details how the project should be built in terms of dependencies, which needs to be pulled in, plug-ins, which needs to be executed, properties to Bill might use that kind of thing. Ci in the roots of the project, we have this pond XML file. So if we look inside here, if we look into the dependencies section, we can see that out of the box. If we exclude the test scopes, dependencies, and just look at the production ones, which are ones which don't have a scope. With a default scope is going to be compiled, which means independent civil independent production application. And both the compile class path and the run-time class path. And therefore bundled limit JAR file or in the more file in the women's lib directory. If we just focus our attention on this particular dependency here, we can see we've got the group ID of org dot Spring framework dot boot, and an artifact ID of Spring Boot starter. So armed with that knowledge, if we take this group ID, just take that and do command c to copy it. And then we're gonna leap over to search dot moveon.org. But we can get more information about the dependencies available in the Maven central repository, which is where all dependencies are pulled from, regardless of whether the projects are built with Maven, Gradle or IV or whatever, they're always pulled from the Maven central repository. So if we just put into the search bar here, org dot Spring framework dot boot and then colon. And then we go back to spring initializer. And we're just gonna take this artifact ID here. Again, command C to copy, go back into here, and just after the colon command V to paste. So now we can see we have this particular Spring Boot module mock dependency, if you like, piloted. And what we're looking at here is the men dependency in any Spring Boot project. So any spring wheat projects, regardless of whether it's a web app using spring NBC or if it's a command-line application, maybe doing some courts scheduling. Or if it's some kind of connector which have developed, which is again probably run from the command line or from a batch job, which is like doing some kind of publishing a messages or consuming from a queue whatever it might be. Regardless of the actual technology types which are used in the spring Boot application itself, this dependency will always be present. And this is an absolutely critical without exception number independence in the offspring boot projects need and without in fact you don't have a Spring Boot project. So very important. So let's take a look at it now. So we can see here we have the latest version of two dot three dot one that release. So we click on here. And this then takes us to the palm file for this dependency itself. So whereas before we saw the palm file for the sample project or the project that's gonna be generated from this spring, initialize a website here. In other words, our sprinkle application that we're about to develop or that we would be about to develop rather. Instead of thinking about something that dependency, what we're seeing here is actually the project object model of this dependency here. So however, works when we include this dependency, it doesn't just bring in one jar file called Spring Boot starter. Instead, it downloads the palm file for this Spring Boot starter. So I downloaded this file here effectively. And then it goes through and it grabs all of the dependencies which are declared in this file tube. So it's going to grab this Spring Boot starter. You can see here, he's gonna grab Spring Boot test. It's going to be grabbing Spring Boot test auto configure and all these other ones. And similarly as well, we could keep going. So if we copy this into another tab, and if we copy this to here. So now we're looking at the first dependency, which Spring bu itself or other which the Spring Boot started dependency will bring in. Goingto here, oops, I missed out on Esther. Then you see that V2 also has a palm file and it also brings in some dependencies. So this one's bringing in Ogden spring from the boot. Spring boots. And spring boots also configure Spring Boot starts a logging. Now it may well be that there's some overlap between what different dependencies bringing and that's okay. There won't be brought in twice. What happens is Maven or greater will make a unified, consolidated view of the full graph of dependencies and pull them all in separate jar files. And it does that by effectively recursing through, in other words, visiting each dependency, pulling its palm file, getting its dependencies. For each dependency there, pulling its palm file, getting its dependencies, and so on until the number of dependencies to be resolved, it works out that full dependency set. And then the complete set of jar files, which that corresponds to it'll download those into your or the local Melbourne repo cash or your local Gradle cash. And include those Jar files in the class path of the project. And then you'll see those in your IDE. You will see them included in your more file. If you're building a web app and you building a more file, you'll see them in the command launched. Use the JVM If you're willing the spring but application from, for example, inside intelligent idea. Those are the places where you'll see these particular classpath. 22. Relating the Spring Boot dependency graph within your IDE: So if we just get rid of that for a second. And this two. So now we've got an understanding of how dependency resolution works. Let's look at what that means for us actually in the ID. So if I open up idea, so this is basically the project which is the default we've just seen. So we've got demo here and we've got this pond XML file. And it's formed XML file. You can see here we've got Spring Boot starter, Then we've got spring bookstore to test. We've generally vintage excluded. If we're going to side-by-side almost with the palm file as it's shown inside that it's been initialized project. You can see that these are the same. So it's the same project. And we're going to plug in here as well because I'm going to plug in here. So exactly the same project, the default project you'll get from a spring initializer created project. So just killed up there and reopen the project inspector. So we can make this dependency resolution mechanism, this graphic dependencies a little more tangible by basically going into the Maven window over here. And if we look inside the dependency section, we can see here we've got Spring Boot starter and 2.3.1, which corresponds to this dependency here, Spring Boot starter. We've also got this other one here. Spring was not a test, which is a test scope dependency, which corresponds to this one here spring would start to test, but the test scope dependency. But again, let's focus on the production one because that's really where all the magic happens with how spin boots bringing in all of the technologies which you specify in your dependencies. So if we open this up, we can see that Spring Boot starter requires these unnatural fact. If I go back search.org very quickly, a prohibition that close that window up. And nevertheless, if we go into here again, here, again, back here, this side, nobody fully, otherwise, it just shows you the right-hand pain. But if we're looking inside here, we can see the top-level dependencies in this dependency section, which we saw before. We can see it's getting Spring Boot, spring Bu auto configure, Spring Boot started logging, which corresponds to Spring Boot. Spring Boot also configure spring boots data logging and so on. And also we looked inside the Spring Boot one before. I won't go back to social moveon.org and show you that again. But again you can see, but it brought in spring K4 and spring context. And you can see that this one is actually grayed out because maybe been smart enough to not include that because it's already included by another dependency. And you can see here that's the dependency which has included it as well. So yeah, so we can actually take this and go through and we can see all of the different dependencies in we can expand, expand the tree and one explain the entire tree, but you get the idea. 23. Looking at the Flattened Resolved Dependencies Set: Now this complete consolidated dependency graph which has been generated, leads to if we jump over to the external libraries window, all of these libraries here being included in your Spring Boot application. So there's a lot of libraries there. There's probably, I guess, maybe like 40 ish, 35-40 libraries, I guess, just by looking at them. So you can see here we've got a cluster of Spring Boot ones and we've got some core Spring framework ones as well, which had been brought in transitively. In other words, the Spring Boot dependencies have also brought those Spring framework ones into. And then we've got some other third party ones as well. And because we haven't specified any specific technology facets for now, so we haven't brought in spring dates or anything to do with messaging or transactions or NoSQL databases, cashing, anything like that. Because of that, we just tend to have kind of like standard dependencies. So here you can see we've got just things that we've logging. We've got some Mockito stuff and Jane is due for testing along with the surgery and ham crest, that's all sorts through a testing log for J logging again, we've got bite buddy, which has to do with bytecode manipulation that's used by Mockito for example. So the key part being with one started dependency, which is just this thing he needs to include. We brought in the men spin loop framework and also the Spring framework itself. Alongside JUnit Makita, which you can then use to test with. So that's how they started dependencies. 24. Changing the Starter Dependency to Bring in a Different Spring Boot Technology Stack: Now if I went back to start dot spring to IR, and I decided, for example, Genome What I want to make this into a web application that I could just go down here to Spring Web or can even type in web. For example, click that. And then I can see I've added this new dependency here. So now if I go into explore and look at the pond XML file, you'll now see there's a new dependency which has been added, which is this one here. And the only has it been added? It's actually if you notice, is replaced, the Spring Boot starts at one, and that's because Spring Boot starts web also brings in Spring Boot starter, so the applications intelligent enough to know that as well. So if we were to also replace the standard Spring Boot starter dependency, we've started dependency for web like so. Then if we click down here, Enable Auto Import. And we'll see that this dependency graph is then rebuilt. As you can see here. We no longer have Spring Boot starter as a top-level dependency. We have Spring Boot Starter web as a top-level one in our production app. But that also, you'll see brings in Spring Boot starter. And again, whatever's needed is brought in transitively as men and builds its dependency graph. So he can see Spring Web and spring with MVC, which are the two main dependencies. They're used for web apps. And we've also got the Spring Boot starter for Tomcat too. Because the spring Blap can also run inside an embedded Tomcat container. In other words, it's inside the jar file itself and it, you don't have to then create a WAR file of your Spring Boot project. It'll just wanted to self-executing JAR file. We've Tomcat bundled into that jar file itself. And as you can see as well now, obviously it's changed the jar files that have been brought in, as you can see here, we've got Tomcat, we've got web and web NBC and that kinda thing. 25. The Relationship of Starter Dependencies with Autoconfiguration: So that's how I started dependencies work inside spring boots. And when you bring these dependencies in, your bringing in a lot of different technology to the table is a really quick way of being able to get the library's note. Your application depends on inside the app and get up and running with it really quickly. So this is one of the main cornerstones of spring Bu applications. This dependency resolution mechanism was seeing here. But the other key parts of app to the key par is the fact that one's dependence is abroad in the Spring Boot runtime will look at these dependencies. And depending on which dependencies are being brought in by inspecting which had been brought in. It will selectively auto configure them and also make linkages between different components. And this is now getting into the realms of auto configuration, which we'll see in the next videos, which is a very exciting aspects to spring boom, which I'm excited to talk about z or these two features, dependency resolution plus auto configuration. It really is the heart of Spring Boot. Just good to understand this, and I've seen it firsthand. You'll be in a good place to understand auto configuration next. 26. Autoconfiguration - Section Introduction: Right, once we have understood how the actual technologies are pulled into our Spring Boot projects, we've just seen that through their started dependencies. The next logical question is, well, how does it just use what it needs? And this is what also configuration is all about. There's more to it than that though, as we'll see. But the next part of your Spring Boot journey is an understanding spring boots also configuration mechanism. So let's jump in now and see exactly how this works. 27. How Spring Boot Creates the Spring Application Container: In this video, we're going to explore how Spring Boot auto detects different technology facets that you include into your spring of applications. So let's jump him. So first off, we're going to idea. And here you can see we've got a demo project. And inside the source main Java, we've got our demo application, which is just a bare-bones spring application, which has this Spring Boot application annotation them. And inside the Resources folder we've got an application dot properties with just some basic configuration to establish data source. So close that down. So I offspring boots auto detection mechanism works is that when we run this spring application, this effectively, if we jumping through the methods, kinda scroll this up a little bit. This is the mainspring application here. This is actually now in the Spring Boot framework code. And in a nutshell, it creates an application context. So regular spring application context, a configurable application context in this case. And then it does a refresh context and refresh context ultimately delegates down. If we go through to the actual application context itself, to its refresh method. So we jump into here. We can see this is an interface method on configurable application context. But it's implemented by, if we just get our command age type hierarchy up is implemented by concrete implementations. So if we expand all of these, it will be implemented in, for example, an annotation config web application context if you happen to be developing a web application. So at any rate, whichever one of these, which is the one which is selected by Spring Boot to instantiate. So whichever application context it decides it's going to create. Jumping back up to the top, which it does in this method call here. It's going to call the refresh method on the application context. And that's gonna basically build the spring consider itself. 28. How @SpringBootApplication Configures a Spring Boot App: So if we jump back out to the demo application, you can see we've got this Spring Boot application, which are spring Boot application class is annotated with a demo application. And if we go into here, you'll see that it's actually a shorthand for annotations which switch on components scanning, handle configuration, which again is also a configuration being class. And the key part is that we have this enable auto configuration. And this is really the thing that creates all of the Spring Boot magic. Now you'll see here in enabling also configuration, we've got this extra thing which it imports, which is auto configuration impulse vector. And if I click into there, we see the implementation for the Spring Boot class, which is responsible for loading in all of the auto configuration classes. So if I scroll down, you'll see this method here, load factor nims. And if I go into that, we'll see load spring factories. And the key point is it's going to load this in here, which is meta INFP, spring dot factories. So let's RNF spring dot factories. If you do command shift though, to look for Spring Dock factories, will see that each specific technology area which are started dependencies abroad in they also include the spring door factories file. So the main one is spring boots. If I double-click this and you can take a look at this now, this is basically configuring all of the components which are going to be dynamically brought into scope by the spin boots framework. So for example, we've got application context listeners. These are classes which are going to listen for lifecycle events and the application context. So in other words, when the application context is created started when it's refreshed, that kind of thing. We've got application listeners, which again are event listeners on the application itself. You've got post-process for the environment and a few other bits and pieces. So what we're looking at here basically is a set of very low-level components in Spring Boot itself, to be able to do the bare minimum required of the framework itself. 29. Spring Factories for Autoconfigured Libraries: Now, if we search again for spring factories, and actually before we do that, if we just look at what we brought in, so in the pond XML file, I didn't explain this in beginning, sorry. In this particular projects are brought in Spring Boot Starter web, Spring Boot starter data GPA, which will bring effectively spring NBC's technology stack and spring data and the Java persistence API technology stack. And also a hedge to database as well so we can get the PhD driver. And if we look inside the Maven tab here, we will see that in bringing in Spring Boot Starter web, it's brought in these dependencies as well. So other Spring Boot dependencies to do with auto configuration. And also the Spring Boot started for Tom cap, so we can have Tomcat as embedded. And it's also brought in the standard Spring framework, spring and VC stuff as well. And then we can see h two at the bottom. So those the actual dependencies that it's brought in. Now each one of those Jar files will appear then inside this classpath in external libraries, just a complete set of flattened jars. And four. If we go back to the file again for some of those Jar files for the Spring Boot starter libraries that are brought in other technology areas of those Which abroad when we'll have the spin dot factories. So for example in here, a spring data GPA, we double-click that. We can see we've got some extra things that JPL is bringing in. If we go back out and we'll look into auto configure, which is more interesting. This is basically the full configuration for the auto configuration framework. And this really is what we're talking about in this particular lesson. So inside here, inside Spring Boot auto configure spring factories. We can see we have under this enable auto configuration for the qualified className here, the complete set of configuration classes which are gonna be brought in whenever we have this enable auto configuration annotation on our Spring Boot class. So the gym workout here demo application has spring with application as an invitation. And it also has this enable auto configuration here as well. So because we have this enable auto configuration protein, because we have spin Bu application there, because we have that. Then basically these springs or factories inside this jar file. Because it's inside the jar file there because it ends with a JAR file name. That's gonna exclamation mark, which means it's inside the jar file. If we double-click that, these configuration classes here have the potential to exist in our Spring container. 30. Understanding a Typical Autoconfiguration: Let's turn now to the idea of like potential to exist. So for example, if we look at data source auto configuration, okay, so this is part of spin JDBC, but if you look at data source auto configuration as a class, so let's just do command to search for the type and search for dead source auto configuration. We can see it's also a part of the Spring Boot also configure dependency. In fact, if we scroll to source and look inside the JDBC, So package inside here of the auto configure Jerry itself. We can see that these are all the classes which to do with the auto configuration mechanism. And we can see we got all the different technology aspects here as well. So all of these are bundled together in one jar file, which is the auto configure dependency. And effectively it's driven by these so-called auto configuration classes. So when I say auto configuration class to Commander, if we type in also configuration, whoops, configuration and put a star on the front, we can see that spring we also configure it gives us all these different auto configuration classes. And these are to do with auto configuring different types of technologies inside your spring will applications based on detecting what technology you have present in the class loader, which in turn, those technologies have been brought in by the various started dependencies which have included. So let's take a look at this one. So I've got some break points here already. I'll just get rid of those for now. We don't need those. So datasource auto configuration. So we have our Enable Auto configuration on our spring Bu AP class, which brings in all of those auto configuration or star auto configuration if you like, classes which we just saw as candidates to be instantiated as spring manage beans inside the Spring container. And these are just regular configuration classes, but just some extra annotations. So you'll see here we've got ICP configuration and that configuration is just the, the same annotation in offspring Framework concepts to annotation. So inside that package, we've got our configuration and we do the classes it needs. And if we go back out, we see some other annotations as well which are on here. I just collapses finance and make it a bit cleaner. So in addition to this configuration imitation being present, which if we didn't have any of these other things, what our mean is it would be configuration being so be treated by the spring runtime as a special spring manage being which can provide configuration. So it can either provide configuration to the container to, for example, flick on components scanning or established properties being replaced, that kind of thing. And also when contain factory methods annotated with aspirin, which has been containable use to be able to create instantiate different types of objects which are driven by the dependency injection invitations that you caught. So for example, when you've got auto wired on say, a couple of fields in a constructor, which is also an AC component or service, our repository or a controller. When you have those couple of beans which have Atwater wired on the constructor, then the spring container would look inside the configuration class and look for any methods annotated with at bean which return objects of those types. And it would invoke those methods to be able to create instances of those objects and independence inject domains or set them in past him into the constructor. So that's the standard use of a configuration class. Okay? Now Spring Boot actually add some extra stuff there because he doesn't want to bring in all of the configuration classes for all different technologies across the entire stack. Number one, that would be too much on memory. And the material that we've clashes between different technologies. For example, if you had two different implementations of platform transaction manager or multiple implementations of data sources, as well as a good example. Instead, you'll find that these auto configuration classes are driven by annotation. And there is a condition evaluation framework which goes on behind the scenes. So in a nutshell, I'll talk through these conditions now when you have AC conditional on class. And this basically means that if datasource dot class or embedded database Time dot class is found in the class loader. Then this configuration will be evaluated. Also if there's a bean of type iota R2, DBC, SBI collection Factory. And that's missing. In other words, that hasn't been established already. But also means this gets a chance to kick in because that's the conditional aspect. 31. Property Injection in Autoconfiguration Classes: Also there's this enable configuration properties, which basically means it's gonna apply configuration properties based on this data source properties not class. And what this is saying is populate these fields here, these members here in this picture, by looking at all the obligation properties, are all the properties available in the application and commonly IPS or either from source, from application to properties application or YAML or afterall, the profile processing is being done. So that combined, unified set of properties there. It'll basically copy properties which start with spin, not datasource onto this Poggio here. So for example, we'll expect to see a spring door datasource dot URL and a spring dot data source or use an m and a spring dot-dot-dot source dot dr or dash, dash name. The reason for that is because it converts case to the hyphenated form. So each auto configuration will also have its own set of properties. And in doing that, you can actually then use those properties to evaluate some conditions. 32. Understanding Conditions and Excluding and Overriding Autoconfiguration: So conditions can either be on the class, that can be on beans missing or being present, that can be on properties being present. So for example, here we can see spring dot data source name type, which is a condition which evaluates to true if there's a property in a set of properties called Spring and, or deaths or StructType, which has been defined. And so inside this data's all sorts of configuration, we have other configurations which define this protected static classes. There are two, in this case, one for an embedded database configuration, if we're running a database and embedded mode. So the database is running inside the Spring container itself. And another one which is for pooled data source configuration. If instead, we're using a connection pool to be able to access our connections to the datasource. So if we look at the pooled data source one. So in the pull data source configuration, again, it's only gonna kick in if we don't already have data source dot class or exceeded source dot class. By the way, this means that if you also have extra configuration, the evaded and you haven't been annotated method which returns the data source then because that's already present, it means effectively you will overwrite this. So then you won't get a chance for Spring Boot to do its auto configuration. So in that respect, the spring will auto configuration is non-invasive. Respect the little creates and wire up low-level spring components supporting the technology stacks. You brought him with sensible defaults as long as you provided a minimal set of properties, which it requires from your application property set. But it doesn't get in the way if you want to put your own things in, in which case then it wants trying create its own configuration. And you can also explicitly exclude just while we're on the topic cern auto configuration by adapting your spring Bu application annotation. So if we go here, demo source, main, Java, back to our demo application. It's actually possible in here to put in an excludes And you can exclude other classes or names. So for example, here you can exclude datasource auto configuration, for example. And if you do that, then spring move or do anything to do with datasource auto configuration. It won't create any debt sources for you, but it does expects that you're doing that yourself. And if there were any other components in here which required a data source, the onus will be on YouTube, prepared that and given suitable factor methods inside your class to be able to create those data sources. And what I mean by that is you'd have, for example, public data source, data source. And in here you return a custom data source. And then you annotate that with that bin. So in other words, you're doing really exactly the same thing that it is also auto configuration is doing. So let's jump back into datasource auto configuration, and let's just look at how this one works. So the pull data source configuration, if we don't have data source or Excel data source, that's for distributed transactions. If we don't have those present in the classpath, That's okay, this gets an opportunity to evaluate to true. It'll pull in all of the property sets across all the different connection pools that you can use with spring boom. So for example here we can see the decimals configuration for DBC P2, which will pull properties beginning with spring-loaded subsidy MECP2. Haven't got this explicitly, by the way, on the classpath. There's a connection pool, which is why that's read there. But don't worry about that. If we go to the Hickory woman, for example, that won't be right because that's actually already supplied as part of the default. And you can see there that's going to be loaded from properties beginning with spring 0.8c, hostile hickory gets a going back up and across to datasource auto configuration. Cso is ongoing provided data source or exceeded source. It'll load all of the properties across all the different collection pulls it supports, make those available for evaluation, and then evaluate this condition here. So in addition to having, for example, conditional on class, like we've seen here, or conditional missing been, I've seen them, or even conditional property. You can also just do conditional on a specific class. And when you pass in that class than you're actually giving an implementation in code to evaluate that condition. So these are felt more richer or more complex conditions which you want to evaluate. So if we click on say here, we can see we've got a pool data source condition which extends this any nested condition here, three different condition times basically. So if we go all the way up to springboard condition and new control Haidt, it'll get a hierarchy. You can see what all different conditions here which are doing this decision-making in a distributed way to establish all these auto configuration, this technology. Silhouettes are going back. We have this agonistic condition and that basically means that if I, this one is true or this one is true, that's good enough for the pooled data source condition to be true. So explicit type is just depending on a property being present, spring-loaded sauce dot type. So if we have spring not datasource dot type, this would evaluate to true, which means that pool data source condition would evaluate to true. Which means in turn that the pull deciles configuration will be the being the exists at runtime plans created by spring. Alternatively, we've got another one here which is pulled data source available. And again, this relies on another condition here. So pulled data source available condition. Now this is different. What this is doing is it's using a data source builder. If we look inside here to be able to find the type which extends a data source. In other words, it could lead to data source control education for type hierarchy. We're looking for any subclasses of this in the current class loader, which is what that clustered input parameters therefore. And so if it finds that, if it's not equal to null, and it's gonna say yet there's a match, which is this condition outcome don't match. The words evaluates the true when this message. Otherwise don't match. 33. Debugging Autoconfiguration by Enabling Autoconfig Reporting: So to go back now to look inside the actual code of spin boo. So we get an understanding of how the auto configuration hangs together. I'll just say one last thing now or close this down. And what I'm gonna do now is run the application, but I'm going to run the application in a special mode. Because you run an Edit Configurations. I'm going to program arguments and just put minus-minus debug. And so now when we run will actually get a report. And this is now a report of the auto configuration. So much I'll just double-click that. Extended all is a very big report. If you look right at the top, you can see here it's initializing the springboard application. And then we have this condition evaluation report logging listener. And this is really useful because it just basically spits out a report of how those conditions have been evaluated. So you don't have to go into the code and understand what's going on and everything to work with Spring boot, I just showed you that you can get an idea of what's going on under the hood. But through this report you can see basically which beans have been matched positively. In other words, they're now part of the spring runtime on the positive matches. And conversely, which ones didn't match on the negative matches. So for example, negative match. Elastic Search, for example, the edge cache configuration, for example, because it didn't find net RSA-FDH cached dot cash as a class in the class loader due to this ONE class condition. Because we didn't include that dependency, because this application doesn't have any caching. Because we didn't have that. It hasn't included the H cache, cache configuration, which is sensible because we don't want caching, so Washington glued it. Conversely, if we go back up and we'll see here we've got datasource, transaction manager auto configuration That's matched because it's found that we've got JDBC template as a class and the class loader and also the platform transaction manager there as well. So because of that, this auto configuration would kick in as well. So you should now have a good overview and understanding of our spring boots auto configuration works under the covers, which will put you in good state to be able to configure Spring boot with different technologies do you want to employ in your applications? 34. Properties - Section Introduction: Now parts of any good application these days is to make the app configurable. In other words, avoid hardcoding of any values inside the code itself, and instead, allow the app to be configured externally to the code itself. This is what we'll look at in this section. So let's get to it. 35. Common Properties in Spring Boot Which You Can Configure: In this video, we're going to look at common properties that you can configure in spring boots applications and when we can find those properties. So first off, let's jump into Chrome and go to spring the IR up to projects into Spring Boot lingo to learn and jump into Reference doc for the version that you're using. And if we just scroll up, we'll see here that we have this application Properties section. So if we just click into here, then what we're looking at now is basically the complete set of properties available in the 2.3.1 of Spring Boot, which we can configure in our application to properties files. So these are split up into core properties. These are properties that are common across any spring Boot application regardless of which technology facets you bring in. So here we can see we've got properties relating to how we can configure logging application Nim auto configuration classes we might want to exclude. This is useful if you want to specifically not have Spring Boot bringing certain classes. So for example, supposing you want to use your own platform transaction manager, and you could exclude it there. And spring that profiles to active is another good one. Visa basically spring profiles that you want to apply when you're running the application. So for example, you might have a spring profile for production and a spring profile for development. And so when you're running in production, you'd pass this property springing up refers to active equals production. So that's the spring dot profiles to antsy property, which enables you to pass a set of profiles that are active for the running spring boots application also as well. Not just the all of these are actually arranged alphabetically as well. So whenever you go through any of these sections, all the properties are always alphabetical. But since they all start with a given prefix, depending on the modules of Spring.me for example, or spring the output. Or in the case of core, a prefix which denotes a particular area of the core framework has been configured. Because of that, it means that our properties in the same area are grouped together, which is useful. So let's scroll down a little bit more. And that's pretty much it for the core properties. We'll gloss over cash, male and Jason because they are less used. Benjamin strains or data properties now. So that's Properties which is where you're configuring things like database connections with the JDBC URL in that kind of thing. So the main properties in here, you'll see we all start with Spring dot data and then the particular database thing or just so spring outdated or Cassandra spring that data, that couch base, which is a no SQL store elastic search we can see. And then we've got spring dot data dot JDBC, Silver Spring dot data when you want it to connect to databases through JDBC. There are four main properties which are used for this. But because they're in alphabetical order, the four men properties aren't grouped together, but I'll just go through them now. So just scrolling up. We're gonna pass TBC P2, which is the connection pulling stuff. We can see we've got spring not datasource, don't drive a dashed class_name. So here you'd put the fully qualified name of the JDBC driver that you using. So in the case of MySQL, for example, they'll become dot MySQL dot JDBC driver. In the case of H2, there'll be org dot TH2, that driver and so on. And actually it's probably easier if I just type in spring datasource. Use an m, which is gonna be the username of the database. We've also got password, which is the password we use to log into the database. And finally, we've got the JDBC URL itself, which is effectively the connection string, which data source is going to use to be able to connect to the database. So those are the four main properties in each user working with databases in Spring Boot. And when developing web applications. Going down to serve a properties. The main properties here are going to be served at port, which is the ports that spring boots. It's gonna listen on the HTTP connections and requests. And just underneath this, the other one, which is the context path. So server.js and the context path. This is the context path under which the web application is going to be available. And finally one more. And they can still logging, which is also useful. We can enable debug lungs with debug. And we can also pass in a specific logging framework configuration file as well. That's if you want to configure logging in more advanced way after the default. So for example, if you wanted to create different dependence with different pattern layoffs, that kind of thing. In terms of setting natural log levels themselves for individual packages though, you can just use this property here. Also properties of this. So you do logging the level dot and then you basically put in either the package name or the fully qualified name of the class that you want to have logging emitted from a controller logging off. And you can do it. You see that here, for example. So login dot level to all the Spring framework equals debug. So that would set everything in the Spring framework package or classes under that and also packages under that contained in those classes. Debbie said to be in the debug level. And you can also change the logging pattern as well if you'd want from within the configuration itself. So those are the main properties that you can set. And you can set them in either an application dot.properties file or internal application dot yaml file, whichever you prefer to do. Sometimes application dot yaml nicer because you can see the nesting of individual properties, which can be nice. Application dot properties files are also nice as well. If you have a large set of properties and sometimes you want a grip them, or to be able to do some search for specific keys. It's easy to do that in an application that.properties file because all the property keys have flattened out and the non-nested structure, which you'd have any YAML file, but that's entirely up to you. And also you can set them through command line switches as well. When you actually start the JVM, you can pass it a minus D switch with any of these properties to effectively override the existing property, which is an application that.properties file obligation YAML file bundled with the application. So yeah, those are the main properties which you'll want to get started with. And what I do is add a bookmark to this particular page. If we go back out, we can see we had that from the main Spring Boot homepage. We went into the Reference doc. And then at the bottom we have this application properties. So just set that as a link in your bookmarks and you'll always have it available and you can always just basically look through to find specific properties. So for example, if I wanted to find out about connection timeouts, because all of this is in boxes. All of these properties are in one page. I could just do Command F and then search for timeout. And keep looking until I saw the specific timeout. There was of interest to me. So for example, here, if I was using the Hickory connection pool, which is the one that comes as default inside spring boom. I can see that here. This is the property that I'd set. So a spring DO datasource to Hickory connection time out. But yeah, but my webpage always have it by your side. And those are the most common properties to get started with any Spring Boot project. 36. Injecting Properties into Spring Managed Beans: In this video, we're going to take a look at configuring an accessing properties in spring two applications. So let's get started. Let's go into idea. So here we can see we've got a simple application. So we're going to source main, Java are production source code folder. We've got a demo application here. And we'll just set up a beam. Then we can use spin manage being just so we can demonstrate how that being connected as a property inside the screen runtime. So let's imagine we've got just an application info class for example. And I just going to be a component which is picked up three components scanning. I want to set a property which is releasing them, for example, is very arbitrary contrived example, but just bear with me for a second. Spring will actually does give you the ability to manage dual properties and so on, versioning and everything. But we just want to have a spin managed beam in which we inject a property from the environment into IP so we can use it. Ok, so all applications will have an application that.properties file which lives inside the source main resources folder. So application dot properties. And so again, that's Application Info. We have a release name. So maybe we've got a property which is called myapp dot release name equals and then an int for the release codename on something other than a Golden Eagle. The level have a released called Golden Eagle book, whatever, some kind of property we're passing him. Now notice in this property, we have a space that's perfectly fine. Notice as well that we've named the property. We have a prefix and the prefix is the name of our application. So that's a best practice to do that. And also we've got this hyphenated style of having separate budget keys, which are kinda composed of two different words or two or more different words. So release dash M, and that's because that's in the same style as the Spring Boot for EMOC does it. So image will stick to the same style since the same convention. Okay, so we've got this myapp dot release name. If we wanted to get this into the application, then you want to get into this application info object. Or we need to do is to use an add value. So if we use our value from this package a or the Spring framework beans the factory annotation. We can specify an expression in here, which enables us to access the property and de reference its actual value. So here we can see we'd have, for example, myapp dot release national m. So now we can show that we get this. Maybe we have, for example, we could either implement initializing being to get a callback when the beans being initialized. And we could have a method which is annotated with post construct sprints at that property will probably just listened to an application started event. So application started, implement the method that I just put release name and the value is injected m. So now if we run this when the application context is created and the application started, so everything's fully loaded, initialized all the properties have been injected in. We should be able to see the value which has been assigned to this field, which comes from my appetite released dash m as part of the application property set. And that's been defined in here. So let's just run our application now. And here we can see we have Golden Eagle, muslim, they're actually for the previous video. I included this debug flag will just remove this similar just run demo application domain. We can see here we have released them, golden eagle. Now if you don't set this and we run it, then we can see we just have an empty value and that's okay. 37. Providing Default Values for Properties: But if we physically remove that key from the file itself. So how should we just comments out in coming out properties using the hash symbol by the way. So now if we run it, we'll get an error. And that's because spring is now trying to dereference this property and it can't find them. So it cannot resolve placeholder because this is a place holder expression to resolve property names to their values. So to get around this, we can actually provide a default. So how defaults work are you basically put a colon and then put the default value afterwards. So for example, here, we can have green parrot instead. And now when we run, we should see the default values picked up because that key was missing. And we can see here we've got released Nim wind power instead. 38. Overriding Properties at Runtime with System Properties: After necessarily just passing applications from an application.properties file which is bundled with the application with because it is part of the production sources, it means that it's actually going to go down into the target classes directory as part of the build process. And it will be physically embedded inside the jar file or the waterfall depending on which packaging type you use. So that means that your application properties effectively when you have them in dislocation here, they're packaged up inside the deployable unit that you're gonna run. It's nice to be able to override those at times and you can do that as well. So you can override, for example, if I go into R1 here and look at the wrong configuration for our application demo application. We could override by passing in a minus D switch. That's the set a system property that the JVM level, and we can just give it the same property key. So my app door release dash M equals, and we'll just call this yellow canary, for example, where the bird references come from. But the mind, if we run now, we should see that it didn't work. And it didn't work because we didn't enclose them in quotes. So it was trying to it was basically trying to set this as a property. And then it was assumed that this was the class name it wanted to execute. So we just put them in double quotes there, then there will be fine. So we re-execute now. And you can see here we have yellow canary. So even if we reintroduce this property back, Golden Eagle and ran, it would still say yellow canary. And that's because the minus d system property is overriding the property that's been bundled with the application. 39. Specifying Properties in YAML File Format: The other thing to mention is that you have two ways of being able to specify properties. You can specify them as property files like this, or you can also specify them as YAML files. So if I rename this YML, the YAML file, then the syntax then is like this. There's basically a property key colon and then the value. So if I take minus D switch out now, because we demonstrated the overriding, we don't need that anymore. Okay. And then re-run. You'll see we have Golden Eagle again. But with yaml, you don't have to give flattened property names like this where you have a BBB, CCC kind of thing. You can actually nest them as well. So it's common in most YAML configuration is you'll have a top-level Qi, for example, of my app. And then underneath we'd have nested keys. So this line here released dash m with this value, it's actually defining a property of myapp dot released on them. So just to prove that if we run that again, we should see that it resolves to the same thing. And you can arbitrarily nest however many levels deep you want it to go. So we can put extra things on here. For example, we could say and released on manager, maybe there's a person who gave the release. Let's see, speak. Maybe we have another plug for release cycle which maybe has sprint number three, for example. Programming Grumman too, if you're doing scrum or whatever, it doesn't matter. Whatever these minima and these irrelevant for the purposes of this demo. 40. Accessing Nested Properties and Strongly Typed Property Values: If you're wanting to access, for example, the sprint number, you'd put in my app, WE cycle spin number. So let's just do that as well. To show that we can inject multiple values. Just create a new one. String, string. Split number, giving you hat value of my app. Don't release. Cycle dots. Sprint number. So release name, sprint number, for example. And then rerun with control are. And now we can see we've also got knowledge, Golden Eagle, we've also got spin number three as well. Now when there's been a number, it's actually possible to change that to an int and everything would still work too. So control are and that also works now. But now we've got the actual real type. And that's because Springs using its property converters to be able to do that, which is also a nice feature. So yeah, that's how you deal with properties in spring boom, inject them into your application and can provide default values of right values. And a look at how you can do that using properties notation or YAML notation. 41. App Startup - Section Introduction: The final piece of the puzzle for spring whose applications is knowing how all spring boots application startup. In other words, what the sequence of events are which happened from start to finish when we first run the app. So in this section, we'll get to know exactly how Spring Boot itself hooks into the Spring framework to be able to be effectively be once it's up and running a regular spring application. At this point, you can then harnessed the existing spring knowledge. You have to be able to develop applications just as you would with any irregular spring app. So let's dive in now and see exactly how Spring Boot applications startup and hook into the spring runtime. 42. Examining a Foundational Spring Boot Project: In this video, we're going to step through the spring boots application framework code to get an understanding of what happens when a spring to application starts and how Spring Boot makes use of the existing Spring framework features to be able to provide a runtime environment based on whatever technology facets we brought in through the starter dependencies. So it is going to be a lot of stuff here. Don't worry if you don't get it first time. And in fact, if you don't get it all, that's also fine as well because you don't really have to understand what happens under the hood to be able to use Spring Boot. But if you're anything like me, you like to know what happens under the covers so you can get a deeper appreciation of the framework you're using. Such you can be able to troubleshoot better and even extend that if you need to as well. It's always, it's always useful services. Very advanced stuff now though, we're just gonna jump right in and get started and step through the code. So I have here a demo projects. So in the pond XML file, I've made it fairly representative of a typical web app projects which uses a database. So you can see we've got a Spring Boot Starter web dependency, which means we can use Spring MVC. We've got spring whoops, data, data GPA, which means that we can use spin data and the Java persistence API to be able to access the database. And here you can see we've got a database dependency installed, which is H2. I've also configured in spring main resources application two properties, the standard application properties file. Just basically simple set of properties to enable us to create a data source. So you can see the JDBC URL. So JDBC page to file desktop demo. It means it's a file based database which you'll appear on my desktop here. And username is SA password is blank. And this is the JDBC driver which the application's gonna use. So jumping out to the actual source code itself, we can see here we've got the main starter class. So this is demo application. This is just basically a project which is completely out of the box or haven't customized anything apart from adding those three dependencies for Spring Web, spring that a GPA and H2. And this is what it generated. So we can see all Spring Boot applications, we have a main method or Java application start with a main method regardless of what the application is. Even web containers like Tomcat with logic, they all start with a main method somewhere. So there's never any exceptions there. And we can see here what it's doing is spring application doctrine. And it's passing in this reference to its own class, which is demo application and any arguments that are passed to it as well. Not as critically, this is annotated with at Spring Boot application. And if we didn't have that, none of the spring with magic would work. So just a quick recap here. If we go into spring, application is actually shorthand for these other annotations of Spring boot configuration to loading the config enable auto configuration, which basically enables detection of the different technology facets that using, based on looking at what classes are available inside the class loader itself on the class path. And components scanning as well. So components getting so we can use the annotation based way of configuring our spring manage beans. So that's using annotations like that component at service, that repository, our controller, and our configuration for configuration classes. So nothing terribly interesting. 43. Registration of Important Spring Application Listeners: So if we took out of here and we just create a breakpoint here, and right-click and do debug. So nothing terribly interesting at the minute we're at the main first line in our application. But if we step into this run method of the spring application with F7, now we're actually inside the Spring Boot code itself. And it's telling you as well, by the way, this spring application class here, I've also chosen to download the Java sources as well, which you can do. But you can actually see from which dependency. Discuss CMS systems from offspring framework built as a group ID. Spring Boot as the artifact ID. And 2.3.1 releases diversion. And that comes from this dependency here, which is brought in by the main Spring Boot starter dependency, which all spring with applications will import either explicitly or more commonly, implicitly because they'll bring in a different starting dependency to pull in a particular technology. And here we can see that it's the Spring Boot starts a web started dependency that brings in the men one peer. So which close it off. Now if we step in here with F7 into the run method, and if we step in again until the constructor and again, okay, so now what's going to set up some fields which it needs. It's not too interesting for now. We're getting a resource loader. A few of the bits and pieces is determining the web application type, which is useful. So it notices now that we are actually running on a server. And it does that by inspecting wasn't the classpath. Then it's setting up some initializers and some listeners and finding out what the main application classes. So these are gonna be used if we now step into the run method itself. Now we've constructed the spring application object. Just get some more space here. These event listeners are gonna be used to emit events to other components so they can respond and do any kind of extra work they need to do or postprocessing there might need to do. And we'll see that in a second. And you can see the serum fact. So there's actually a spring application run listener. So spring application run listener here, event publishing one listener. And when we jump into there, that's going to receive this listen end up starting callback, which is using this initial multicasting object here to throw out this application starting event and initial multicast itself. If we get into that and look inside the default retriever, we can see that we've actually got these application listeners here, which are registered to listen to application events. So here we can see these listeners, and here we can see these instances. These beans are going to listen to these application events. And some of them might just be normal straight up event listeners, which just have a listen method and do some extra stuff. Other ones might actually be post processes. So in other words, they might take some aspect of a spring component and do some post processing on it, which we'll see as well anyway. So all these application listeners will get a chance to describe two different application events and they receive the events that they subscribe to. So for example, if we go into multicast event, create the event first. Go into multicast event. Again, resolve the type. And now you'll see there's this resolvable type, which is an application starting event. So from the event instance that's passed in is getting the actual type. And then what it's gonna do is it's gonna go through all of the listeners and basically filter out the ones which have raised an interest in that specific type. And then you can see here, if we step into it's gonna actually invoke the listener. Do invoke listener by actually emitting the core vacuum itself. So listener that on application event. And again that comes from the application listener interface here. So application listener is a callback interface which can allow interested parties to receive any extensions of application event. So we do control hitch here. We can see these are all the listeners which are available anymore. If we expand, these are all the listeners which are available currently. And so the classpath. And similarly, if we click on into application events, also do control hedge. Expand all we can see that these are all the event types which are available in the classpath as well. And these are typically event types that will be passed around dilemma spring will infrastructure up to orchestrates tasks. So here we see we've got events extending from spring application event about when the application context is initialized, about when it started, if there's a failure. And that kinda thing that's useful to know suddenly. So if we backtrack out from there, simply close that, close that and shift if I go back up. So now we're going to back up the call stack with shift F8. And now we're back into the main spring application here. 44. Preparing and Establishing the Spring Application Context: So now we're back to the top level. Let's carry on. So, so far, we've notified some listeners to say the application starting and mixed it. We've got this prepare environment. So prepare environment gives us basically the environment which we have access to in the spinning what application. So that's the collection of all the application properties along with profile information, that kind of thing. Okay? And then we get down to Create application context. So if we step inside this, what happens here did determines the fully qualified class name of the application context to create. So all spring applications, we will start by instantiating an application context and the usual ones we're used to in plain vanilla Spring applications are the file-based XML application context, classpath XML application context, which both read XML configuration for configuring the Spring container from a file, often the classpath, or alternatively from the annotation configuration application context. And that's the application concepts we use if we are going to be doing the annotation base configuration. So not using an XML file, but using annotations on our Java classes, those annotations links them from AC components or the configuration annotation for Java configurations with the API mechanism, that kind of thing. In this case, however, it's a web application, so it's detected it as an addition conflicts server, web server application context, which adds some extra stuff in there. And then it's basically instantiate that through reflection, which is not this bin utils to instantiate clusters. So at this point, what we have returned here in context is an actual application context. So if we look inside that context, we can see here it's in blue because it's the last variable is being touched and initialized. We can see here we've got our bean factory. And inside our bean factory, we haven't been definition map. And so far these are the Spring framework classes which had been instantiated and been placed as part of that being definition map. Okay. And if we look down, we'll see there are now being post processes currently. And also if you look for C, there are no bean factory post-process as either. But that's about to change very shortly, as we'll see. 45. Creating the Beans of the Spring Runtime: Okay, so let's continue on then, stepping through the code within this prepare contexts now. So I'll just let that prepare it and then we'll see what changes it's made. So now if we look inside the context, we can see we do have been factory pulse processes. And specifically we have these three here. And what these are going to do, they're basically post-process the bean factory. So there was the plain vanilla bean factory, which is produced from a spring code. What's going to happen now is each one of these is going to post-process it in some way. And we've also got application listeners as well, which we saw before. And if we go into our bean factory, because you've got the beans in there as well. So when we do refresh context, are we step into this, casting it to an application context and doing refresh application context to refresh during a stupid or refresh. So when we're in this class here, which is now abstract to application context. This method here, which is the refresh method, is basically the main sequence of steps which the Spring container goes through to get itself set up for use. So stepping through this, when we see post-process bean factory for example, if we step in here, step into this. We can see that this is a hook in the Spring framework which allows any subclasses of the application context to post-process the bean factory in any way they see fit. And so for example here we can see the beam factories adding a bean post processor, which is web application context serve that context aware processor. Which will, if you look inside, they're mostly it's providing extra functionality to set the web application context and get the cellular context and config. Jim poverty, we shift F8, then we're now into this invoke bean factory boss processes. So now we've done specific subclass application, context level stuff. We can go into this invoke bean factory post-process as method. Again, step into here. And we'll see that we have our registry, which is basically the bean factory itself. And when we step through here, we see that for each registry processor that we have, each post-process and that we have in our bean factory post processes. So we have those three which we saw earlier from here. Each one's getting a turn to post-process being definition registry. And so bean factory post processor basically gets passed is configurable, listable bean factory. So you can pause, process it in some way. So here for example, in this one, if we go into the shared metadata, read a factory context initializer, registering being definitions then configure configuration, cause post processor. And it's getting a specific bean adding some property values. So shifted out of here, that's not particularly interesting one. And shift a fade back out and do it now back to the top level. So this point now the bean factory here as being post-processed. And now it has the singleton objects which had been created. So the auto detection mechanisms going on and it's greater things like a transaction interceptor for intercepting transactions and doing all the transaction algae stuff on service methods. And those kinds of things. Just close it off. 46. Creating the Embedded Tomcat Web Server: The message source initializing is not too interesting. Initializing the atlas has to do with its nationalization in its application event multicast. That's fine. Now we didn't own refresh. And then when we do on refresh, we can see here it's actually creating the web server. So this is what's creating the embedded Tomcat web server. You can see here is if we open that up, you can see here service connectors that connect to establish ridges on port 8080. And if we shift it out from there, It's going to register listeners. Again, it will emit any events which it needs to emit. But it's going to instantiate any more Singletons, Which employee need most of those, Laura, they've been done in the home, refreshed by the way. 47. Publishing Spring Events to Application Listeners: And then finally it's going to do a finished refresh, which is gonna publish out the events you can see in here on lifecycle process to say on refresh, and also publish this context refresh event as well. And at that point then our application continue to step through here. Let's just step out, step out, step out again. Now we've done the run at that point here. Now when we look inside the console, we can see that now spring with application is started and it's up and running on 8080 waiting to service HTTP calls. Bled off. F9 does a quick walk through of the main start-up sequence. 48. Wrapping Up and Thanks!: Well, we're at the end of the course now. And by now you should have a good understanding of how you can create spring boots applications, the basics of how you can build and run them. Understand how a typical LED application in spring bill will look code wise and be able to find your way around and understand the nuts and bolts of how dependencies are pulled into Spring Boot apps have the components within those dependencies are configured, how you can configure and use your own components, and how springboards hooks into the spring runtime to effectively give you a regular spring burst environments in which to code your application. We've come a long way and cubital lots of grounds. So you should be proud of yourself making it this far and be able to see just how far you've come. Now if you want more of a deep dive into spring itself, you might want to check out our other course, which goes into that. So in fact, this course and that one makes a great pairing together to really get a handle on spring and spring Boot together. But for now, all that remains to say as it's been great having you in this course, good luck with your Spring Boot journey from here and have a great day.