Original subtitles

Instructor: Well, everything's working just fine,

but hey, let's go ahead and break it on purpose.

I wanna see how Spring can handle things if I change up

some of the packages or move things around a bit.

Let's go ahead and select the Java folder in the list here

and we're gonna create a new package.

And the name of the new package,

I'll call it, com.luv2code.util.

And so, the important thing to notice

is that it's not a sub-package of our Spring core demo.

It's outside of that.

So, we may have some issues

with some of our default component scanning.

And what I'll do here is I'll move into the Spring core demo

common package and I will move coach and cricket coach

to this new util package that I just created.

(no sound)

Okay, so that looks okay so far.

Now, notice our main Spring Boot application

is under Spring core demo.

So, Spring will scan everything in this package

and any sub-packages, but by default

Spring will not component scan this new package here

that I created, com.luv2code.util.

So, let's go ahead and test this out and see what happens.

Ah, application failed to start.

Okay.

A parameter of constructor demo controller required

of being of love to code util coach,

but could not be found, hmm.

Because it, just it's not part

of the default component scanning.

It's just that just won't work.

And so you're like, gosh, what's going on here?

Well now, we need to explicitly tell Spring Boot

how to find these other packages out there.

And so, we can accomplish that by editing

our Spring cord demo application

and updating the annotation Spring Boot application.

Inside of here, I'll explicitly list

the base packages to scan.

So, I give scan base packages

and then I simply set up a common delimited list

of the packages that I want it to scan.

So, I give com.luv2code Spring core demo,

and then, I also give com.luv2code.util.

So, remember, by default of the only component scan

Spring core demo, but we have this util,

so we have to list both of those here.

Let's go ahead and run this and test it out,

and yay, the issue's resolved.

So, the application actually starts up successfully.

We don't have the problem that we had before.

And then, we can test this in our browser

by hitting this endpoint and just doing a reload on it

and we get the data back as desired,

so it's able to find everything.

It's able to perform the injection

and we're all set up because we were very explicit here

by listing out those packages.

All right, now I'm gonna go ahead and move things back

to their original packages, just so we can take advantage

of the default component scanning with Spring Boots.

So, I'll just grab coach and cricket coach.

I'll move those back over to the common package.

And then, this code that I had here, I could delete it,

or in this case I'll just comment it out,

kind of leave it around for a little bit

in case you wanted to refer to it later.

And then, I'll just use a regular Spring Boot application

by itself and make use of the default configuration

the default component scanning,

and I'll save all that stuff and test it

and make sure it still works and great.

So, our app starts up just fine

and swing over to our browser, do a reload here,

and the import works out just fine.

So, we kind of put things back the way

they were set up originally.

Alrighty, so this looks really good.

I'm happy with this.

I hope you had a good chance here of learning about

component scanning with Spring Boot,

the default component scanning,

and also being explicit with custom packages.

Alrighty, good job, my friend.