1

00:00:00.05 --> 00:00:01.04

- [Instructor] In Spring Boot two,



2

00:00:01.04 --> 00:00:03.01

there's some pretty significant changes



3

00:00:03.01 --> 00:00:06.00

to the configuration system in addition to



4

00:00:06.00 --> 00:00:09.04

many of the configuration

properties being changed.



5

00:00:09.04 --> 00:00:10.04

One of the things to note



6

00:00:10.04 --> 00:00:12.09

is the way that environment is bound.



7

00:00:12.09 --> 00:00:14.08

The binding mechanism, for instance,



8

00:00:14.08 --> 00:00:18.09

for @ConfigurationProperties

has been completely overhauled.



9

00:00:18.09 --> 00:00:20.00

Now for the average user,



10

00:00:20.00 --> 00:00:23.00

this isn't going to

provide a lot of changes,



11

00:00:23.00 --> 00:00:24.04

but you may see some changes



12

00:00:24.04 --> 00:00:27.03

if you are writing custom starters.



13

00:00:27.03 --> 00:00:28.05

The rules around binding



14

00:00:28.05 --> 00:00:30.06

have become a little bit more strict,



15

00:00:30.06 --> 00:00:31.08

and those are really designed



16

00:00:31.08 --> 00:00:34.07

to help you maintain your contract.



17

00:00:34.07 --> 00:00:38.07

Now one of the new changes is

the ability to do API binding,



18

00:00:38.07 --> 00:00:42.03

so you get access to that

API, that binding API,



19

00:00:42.03 --> 00:00:44.03

from anywhere within your code,



20

00:00:44.03 --> 00:00:47.09

not just within configuration properties.



21

00:00:47.09 --> 00:00:50.07

Now some of those

property file rule changes



22

00:00:50.07 --> 00:00:51.06

and how they work



23

00:00:51.06 --> 00:00:55.03

is that every property is now

converted to all lowercase.



24

00:00:55.03 --> 00:00:58.01

Special characters are removed.



25

00:00:58.01 --> 00:01:00.02

You can define lists of properties,



26

00:01:00.02 --> 00:01:02.09

so if you have a property that

there isn't a list expected,



27

00:01:02.09 --> 00:01:05.06

you can provide those with

traditional array notation,



28

00:01:05.06 --> 00:01:08.01

which is the open square bracket,



29

00:01:08.01 --> 00:01:10.02

a number, and then the

closed square bracket.



30

00:01:10.02 --> 00:01:12.05

It's a zero-based index.



31

00:01:12.05 --> 00:01:13.07

Or you can simply provide



32

00:01:13.07 --> 00:01:16.03

a comma-separated content list



33

00:01:16.03 --> 00:01:19.00

and have that mapped into a list, as well.



34

00:01:19.00 --> 00:01:20.06

Now if you're not using property files,



35

00:01:20.06 --> 00:01:22.03

but instead using YAML,



36

00:01:22.03 --> 00:01:25.01

you're going to have very similar results.



37

00:01:25.01 --> 00:01:26.08

So, the similar practice with the way



38

00:01:26.08 --> 00:01:28.00

the property files works



39

00:01:28.00 --> 00:01:31.02

as far as the case and special characters,



40

00:01:31.02 --> 00:01:33.07

but you also get standard

YAML formatted lists,



41

00:01:33.07 --> 00:01:36.09

which is the little hyphen

in front of the line.



42

00:01:36.09 --> 00:01:39.01

You do not get the

square bracket notation,



43

00:01:39.01 --> 00:01:42.01

but that's okay because

YAML provides its own way.



44

00:01:42.01 --> 00:01:45.02

You do have support for

comma-separated lists still,



45

00:01:45.02 --> 00:01:47.01

if you need to use that.



46

00:01:47.01 --> 00:01:50.01

Now I mentioned a moment

ago about this binding API,



47

00:01:50.01 --> 00:01:52.08

and I just want to talk

a little bit about this.



48

00:01:52.08 --> 00:01:54.04

This provides a mechanism



49

00:01:54.04 --> 00:01:57.08

for binding properties

directly into your code,



50

00:01:57.08 --> 00:02:01.07

so if, for instance, you want

to provide a list of values



51

00:02:01.07 --> 00:02:03.09

as configuration property,



52

00:02:03.09 --> 00:02:05.08

you can very easily create a class



53

00:02:05.08 --> 00:02:08.00

and bind those to that class



54

00:02:08.00 --> 00:02:10.02

through the traditional

configuration properties



55

00:02:10.02 --> 00:02:12.07

or through this binding API.



56

00:02:12.07 --> 00:02:15.07

I actually kind of like

the idea of binding API



57

00:02:15.07 --> 00:02:18.04

because then I can see it in my code.



58

00:02:18.04 --> 00:02:21.04

Now this supports single

values as well as lists,



59

00:02:21.04 --> 00:02:23.08

and you still get a converter support.



60

00:02:23.08 --> 00:02:25.00

And this is really powerful



61

00:02:25.00 --> 00:02:26.08

when you're dealing with

things like duration,



62

00:02:26.08 --> 00:02:30.03

or other traditional standardized formats,



63

00:02:30.03 --> 00:02:34.02

so for instance 10s becomes

10 seconds in a duration.



64

00:02:34.02 --> 00:02:35.09

There's several converters built in



65

00:02:35.09 --> 00:02:37.08

outside of lists and duration.



66

00:02:37.08 --> 00:02:40.00

Take a look at that in the documentation



67

00:02:40.00 --> 00:02:41.08

and it'll give you an idea of how



68

00:02:41.08 --> 00:02:44.01

this binding API can help you.



69

00:02:44.01 --> 00:02:45.09

Now, configuration is one of those things



70

00:02:45.09 --> 00:02:48.09

that we tend to set once

and never look at again,



71

00:02:48.09 --> 00:02:52.03

so it's not really that

critical for an upgrade path



72

00:02:52.03 --> 00:02:54.02

unless you run into issues,



73

00:02:54.02 --> 00:02:56.06

which is why I wanted to talk about these



74

00:02:56.06 --> 00:02:58.09

because if you had things

that were previously accepted



75

00:02:58.09 --> 00:03:01.06

that have now been excluded

based on the rule changes,



76

00:03:01.06 --> 00:03:03.06

it's important to make note of that



77

00:03:03.06 --> 00:03:07.04

and to be aware as you're doing

your upgrade from 1.5 to 2.0



