Часто полезно реализовать проверку ввода для наших API, чтобы избежать непредвиденных ошибок позже, когда мы обрабатываем данные.
К сожалению, в Spring 5 нет возможности автоматически запускать проверки на функциональных конечных точках, как мы это делаем на аннотированных. Мы должны управлять ими вручную.
Тем не менее, мы можем использовать некоторые полезные инструменты, предоставляемые Spring, чтобы легко и просто проверить, действительны ли наши ресурсы.
Иногда нам приходится обслуживать статический контент в наших веб-приложениях. Это может быть изображение, HTML, CSS или файл JavaScript.
В этом руководстве мы покажем, как обслуживать статический контент с помощью Spring WebFlux . Мы также предполагаем, что наше веб-приложение будет настроено с использованием Spring Boot .
По умолчанию Spring Boot предоставляет статический контент из следующих мест:
В этой статье мы очень кратко рассмотрим, что такое Exception , и углубимся в обсуждение связанных исключений в Java.
Проще говоря, исключение — это событие, нарушающее нормальный ход выполнения программы. Давайте теперь посмотрим, как именно мы можем сцепить исключения, чтобы получить от них лучшую семантику.
И ClassNotFoundException , и NoClassDefFoundError возникают, когда JVM не может найти запрошенный класс в пути к классам. Хотя они выглядят знакомыми, между ними есть некоторые основные различия.
В этом уроке мы обсудим некоторые причины их появления и их решения.
Исключение ClassNotFoundExceptionClassNotFoundException — это проверенное исключение, которое возникает, когда приложение пытается загрузить класс с помощью его полного имени и не может найти его определение в пути к классам.
В нашем руководстве по основам проверки Java Bean мы видели использование различных встроенных ограничений javax.validation . В этом руководстве мы увидим, как группировать ограничения javax.validation .
Есть много сценариев, в которых нам нужно применить ограничения к определенному набору полей компонента, а позже мы хотим применить ограничения к другому набору полей того же компонента.
Например, давайте представим, что у нас есть двухэтапная форма регистрации. На первом этапе мы просим пользователя предоставить основную информацию, такую как имя, фамилия, идентификатор электронной почты, номер телефона и капча. Когда пользователь отправляет эти данные, мы хотим проверить только эту информацию.
В этом уроке мы обсудим сопоставители файлов Hamcrest.
Мы обсуждали Hamcrest Matchers в целом ранее в предыдущей статье « Тестирование с помощью Hamcrest ». В следующих разделах мы сосредоточимся только на File Matchers.
Во-первых, нам нужно добавить следующую зависимость в наш pom.xml :
Помимо встроенных сопоставителей, Hamcrest также поддерживает создание пользовательских сопоставителей.
В этом уроке мы подробно рассмотрим, как их создавать и использовать. Чтобы получить краткий обзор доступных сопоставителей, обратитесь к этой статье .
Чтобы получить Hamcrest, нам нужно добавить следующую зависимость Maven в наш pom.xml :
В этом руководстве мы рассмотрим текстовые сопоставления Hamcrest.
Мы обсуждали Hamcrest Matchers в целом перед тестированием Hamcrest , в этом уроке мы сосредоточимся только на Text Matchers.
Во-первых, нам нужно добавить следующую зависимость в наш pom.xml :
В этом руководстве мы узнаем , как проецировать свойства объекта с помощью JPA и Hibernate .
Во-первых, давайте посмотрим на объект, который мы будем использовать в этой статье:
@Entity
public class Product {
@Id
private long id;
private String name;
private String description;
private String category;
private BigDecimal unitPrice;
// setters and getters
}