Хотя вы можете явно настроить свой собственный компонент источника данных, это обычно не требуется. Вместо этого проще настроить URL-адрес и учетные данные для базы данных с помощью свойства конфигурации. Например, если бы вы должны были начать использовать базу данных MySQL, вы могли бы добавить следующие свойства конфигурации к приложению в формате YML:
spring:
datasource:
url: jdbc:mysql://localhost/tacocloud
username: tacodb
password: tacopassword
Хотя вам нужно будет добавить соответствующий драйвер JDBC в сборку, вам обычно не нужно будет указывать класс драйвера JDBC; Spring Boot может выяснить это из структуры URL базы данных. Но если возникнет проблема, вы можете установить свойство spring.datasource.driver-class-name :
spring:
datasource:
url: jdbc:mysql://localhost/tacocloud
username: tacodb
password: tacopassword
driver-class-name: com.mysql.jdbc.Driver
Spring Boot использует эти данные подключения при автоконфигурировании компонента DataSource. Компонент DataSource будет объединен с помощью пула соединений JDBC Tomcat, если он доступен в пути к классам. Если нет, Spring Boot ищет и использует одну из этих реализаций пула соединений в пути к классам:
-HikariCP
-Commons DBCP 2
Хотя это единственные параметры пула соединений, доступные через автоконфигурацию, вы всегда можете явно настроить компонент источника данных для использования любой реализации пула соединений, которую вы хотите.
Ранее в этой главе мы предположили, что можно указать сценарии инициализации базы данных для запуска при запуске приложения. В этом случае,будут полезны свойства spring.datasource.schema и spring.datasource.data:
spring:
datasource:
schema:
- order-schema.sql
- ingredient-schema.sql
- taco-schema.sql
- user-schema.sql
data:
- ingredients.sql
Возможно, явная конфигурация источника данных не ваш стиль. Вместо этого, возможно, вы предпочтете настроить источник данных в JNDI и Spring найдет его там. В этом случае настройте источник данных, настроив spring.datasource.jndi-name:
spring:
datasource:
jndi-name: java:/comp/env/jdbc/tacoCloudDS
Если вы установите свойство spring.datasource.jndi-name, другие свойства соединения с источником данных (если задано) игнорируются.
5.1.3 Настройка встроенного сервера
Вы уже видели, как установить порт контейнера сервлета, установив server.port. Я не показал вам, что происходит, если server.port 0:
server:
port: 0
Но базовый сервер-это не просто порт. Одна из наиболее распространенных вещей, которые вам нужно сделать с базовым контейнером, - настроить его для обработки HTTPS-запросов. Чтобы сделать это, первое, что вы должны сделать, это создать хранилище ключей с помощью утилиты командной строки keytool JDK:
$ keytool -keystore mykeys.jks -genkey -alias tomcat -keyalg RSA
Вам будет задано несколько вопросов о вашем имени и организации, большинство из которых не имеют никакого отношения к результату. Но когда вас спросят пароль, помните (а лучше запишите), что вы задаете. Для этого примера я выбрал letmein в качестве пароля.
Затем вам нужно будет установить несколько свойств для включения HTTPS на встроенном сервере. Вы можете указать их все в командной строке, но это было бы ужасно неудобно. Вместо этого вы, вероятно, установите их в файле application.properties или In application.yml формате YML. В In application.yml, свойства могут выглядеть следующим образом:
server:
port: 8443
ssl:
key-store: file:///path/to/mykeys.jks
key-store-password: letmein
key-password: letmein
Тут свойство server.port имеет значение 8443, что является общепринятым значением для разработки HTTPS-серверов. Свойство server.ssl.key-store должно быть задано значением пути, где расположен создаваемый файл keystore. Здесь он задан с file:// URL для загрузки его из файловой системы, но если вы упакуете его в файл JAR приложения, вы должны использовать classpath: URL для ссылки на него. И оба свойства server.ssl.key-store-password и задаются значением пароля, который был задан при создании хранилища ключей.
При наличии этих свойств приложение должно прослушивать HTTPS-запросы на порту 8443. В зависимости от используемого браузера может появиться предупреждение о том, что сервер не может подтвердить свою личность. На это можно не обращать внимание при работе с localhost во время разработки.
5.1.4 Конфигурация логирования
Большинство приложений обеспечивают некоторую форму логирования. И даже если ваше приложение ничего не регистрирует напрямую, библиотеки, которые использует ваше приложение, обязательно логируют свою активность.
По умолчанию Spring Boot настраивает ведение журнала через Logback (http://logback.qos.ch) для записи на консоль на информационном уровне. Вероятно, вы уже видели множество записей INFO уровня в журналах приложений при запуске приложения и других примерах.
Для полного контроля над конфигурацией ведения журнала можно создать logback.xml-файл в корневом каталоге пути к классам (в src/main/resources). Вот пример простого logback.xml-файл, который можно использовать:
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
Помимо шаблона, используемого для ведения журнала, эта конфигурация Logback более или менее эквивалентна используемой по умолчанию, которое вы получите, если у вас нет logback.xml файл. Но путем редактирования logback.XML вы можете получить полный контроль над log файлами приложения.
ПРИМЕЧАНИЕ: Особенности настройки logback.xml выходят за рамки этой книги. Обратитесь к документации Logback для получения дополнительной информации.
Наиболее распространенные изменения, которые вы внесете в конфигурацию логирования, - это изменение уровней логирования и, возможно, указание файла, в который должны быть записаны логи. С помощью свойств конфигурации Spring Boot вы можете вносить эти изменения без необходимости создания файла logback.xml.
Чтобы установить уровень логирования, нужно задать свойства, которые начинаются с logging.level, за которым следует имя регистратора, для которого вы хотите установить уровень ведения журнала. Например, предположим, что вы хотите установить корневой уровень (root logging level) логирования WARN, а логирование Spring Security в уровень DEBUG. Следующие записи в application.yml позаботятся об этом для вас:
logging:
level:
root: WARN
org:
springframework:
security: DEBUG
При необходимости можно свернуть имя пакета Spring Security в одну строку для удобства чтения:
logging:
level:
root: WARN
org.springframework.security: DEBUG
Теперь предположим, что вы хотите записать log-и в файл TacoCloud.log в /var/logs/. Свойства logging.path и logging.file могут помочь в этом:
logging:
path: /var/logs/
file: TacoCloud.log
level:
root: WARN
org:
springframework:
security: DEBUG
Предполагая, что приложение имеет разрешения на запись в /var/logs/, записи журнала будут записаны в /var/logs/TacoCloud.log. По умолчанию log файлы создаются новые по достижении размера 10 МБ.
5.1.5 Использование специальных значений свойств
При настройке свойств вы не ограничиваетесь объявлением их значений как жестко закодированных строковых и числовых значений. Вместо этого можно получить их значения из других свойств конфигурации.
Например, предположим (по какой-либо причине), что вы хотите установить свойство с именем greeting.welcome на основе значение другого свойства с именем spring.application.name. Для этого при настройке приветствия можно использовать маркеры-заполнители $ {} для задания свойства greeting.welcome:
greeting:
welcome: ${spring.application.name}
Вы даже можете использовать этот заполнитель как часть другого текста:
greeting:
welcome: You are using ${spring.application.name}.
Как вы уже видели, настройка собственных компонентов Spring со свойствами конфигурации позволяет легко вводить значения в свойства этих компонентов и настраивать автоконфигурацию. Свойства конфигурации не являются эксклюзивными для bean-компонентов, которые создает Spring. Приложив небольшое усилие, вы можете использовать свойства конфигурации в ваших собственных bean-компонентах. Посмотрим как.
5.2 Создание ваших собственных свойств конфигурации
Как я упоминал ранее, свойства конфигурации - это не что иное, как свойства bean-компонентов, предназначенных для получения конфигураций из абстракции среды Spring. Что я не упомянул, так это то, как эти компоненты предназначены для использования этих конфигураций.
Для поддержки внедрения свойств конфигурации Spring Boot предоставляет аннотацию @ConfigurationProperties. При указании аннотации в любом Spring bean-компонен туказывается, что свойства этого bean-компонента могут быть внедрены из свойств среды Spring.
Чтобы продемонстрировать, как работает @ConfigurationProperties, предположим, что вы добавили следующий метод в OrderController, чтобы вывести список прошлых заказов аутентифицированного пользователя:
@GetMapping
public String ordersForUser(
@AuthenticationPrincipal User user, Model model) {
model.addAttribute("orders",
orderRepo.findByUserOrderByPlacedAtDesc(user));
return "orderList";
}
Наряду с этим вы также добавили необходимый метод findByUser() в OrderRepository: