Java Blog

Внедрение зависимости должно сделать ваш код менее зависимым от контейнера, чем это было бы при традиционной разработке Java EE. POJO, составляющие ваше приложение, должны тестироваться в тестах JUnit или TestNG с объектами, экземпляры которых создаются с помощью оператора new, без Spring или любого другого контейнера. Вы можете использовать фиктивные объекты (моки) (в сочетании с другими ценными методами тестирования) для изолированного тестирования вашего кода. Если вы будете следовать рекомендациям по архитектуре для Spring, полученное в результате чистое разбиение на уровни и компонентность вашей кодовой базы облегчит модульное тестирование. Например, вы можете тестировать объекты уровня сервиса, вставляя заглушки или имитируя интерфейсы DAO или репозитория, без необходимости доступа к постоянным данным во время выполнения модульных тестов. Истинные модульные тесты обычно выполняются очень быстро, так как не требуется настраивать среду выполнения. Акцент на истинных модульных тест

Переменные - это не что иное, как зарезервированные ячейки памяти для хранения значений. Это означает, что когда вы создаете переменную, вы резервируете некоторое место в памяти. На основе типа данных переменной операционная система выделяет память и решает, что можно сохранить в зарезервированной памяти. Таким образом, назначая переменным разные типы данных, вы можете хранить в этих переменных целые, десятичные дроби или символы. В Java доступны два типа данных: Примитивные типы данных Ссылочные/Объектные типы данных Примитивные типы данных Java поддерживает восемь примитивных типов данных. Примитивные типы данных предопределены языком и названы ключевым словом. byte Тип данных byte - это 8-битовое знаковое целое число с дополнением до двух. Минимальное значение -128 (-2^7) Максимальное значение 127 (включительно)(2^7 -1) Значение по умолчанию - 0 Тип данных byte используется для экономии места в больших массивах, в основном вместо int, поскольку byte в четыре раза мень

FileSystemResource, который не присоединен к FileSystemApplicationContext (то есть, когда FileSystemApplicationContext не является фактическим ResourceLoader), обрабатывает абсолютные и относительные пути, как и следовало ожидать. Относительные пути указываются относительно текущего рабочего каталога, а абсолютные пути - относительно корня файловой системы. Однако по причинам обратной совместимости (историческим) это изменяется, когда FileSystemApplicationContext является ResourceLoader. FileSystemApplicationContext заставляет все присоединенные экземпляры FileSystemResource рассматривать все пути к расположению как относительные, независимо от того, начинаются они с косой черты или нет. На практике это означает, что следующие примеры эквивалентны: Java ApplicationContext ctx = new FileSystemXmlApplicationContext("conf/context.xml"); ApplicationContext ctx = new FileSystemXmlApplicationContext("/conf/context.xml"); Kotlin val ctx = FileSys

Пути к ресурсам в значениях конструктора контекста приложения могут быть простыми путями ( как показано ранее ), каждый из которых имеет однозначное сопоставление с целевым ресурсом или, альтернативно, может содержать специальный префикс "classpath*:" или внутреннее регулярное выражение в Ant-стиле (сопоставлены с помощью утилиты Spring PathMatcher). Оба последних по сути являются подстановочными знаками. Одно из применений этого механизма - когда вам нужно выполнить сборку приложения в компонентном стиле. Все компоненты могут "публиковать" фрагменты определения контекста по хорошо известному пути местоположения, и, когда конечный контекст приложения создается с использованием того же пути с префиксом classpath*:, автоматически выбираются все фрагменты компонентов. Обратите внимание, что этот подстановочный знак специфичен для использования путей к ресурсам в конструкторах контекста приложения (или когда вы напрямую используете иерархию служебных классов PathMatch

Конструктор контекста приложения (для определенного типа контекста приложения) обычно принимает строку или массив строк в качестве путей расположения ресурсов, таких как файлы XML, составляющие определение контекста. Когда такой путь местоположения не имеет префикса, конкретный тип ресурса, созданный на основе этого пути и используемый для загрузки определений компонентов, зависит от контекста конкретного приложения и соответствует ему. Например, рассмотрим следующий пример, который создает ClassPathXmlApplicationContext: Java ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml"); Kotlin val ctx = ClassPathXmlApplicationContext("conf/appContext.xml") Определения bean-компонентов загружаются из пути к классам, поскольку используется ClassPathResource. Однако рассмотрим следующий пример, в котором создается FileSystemXmlApplicationContext: Java ApplicationContext ctx = new FileSystemXmlApplicationContext("conf

Если сам bean-компонент будет определять и предоставлять путь к ресурсам посредством какого-то динамического процесса, для него, вероятно, имеет смысл использовать интерфейс ResourceLoader для загрузки ресурсов. Например, рассмотрим загрузку какого-либо шаблона, в котором конкретный необходимый ресурс зависит от роли пользователя. Если ресурсы статичны, имеет смысл полностью исключить использование интерфейса ResourceLoader, сделать так, чтобы bean-компонент раскрыл необходимые ему свойства ресурса и ожидал, что они будут внедрены в него. Последующее внедрение этих свойств делает тривиальным то, что все контексты приложения регистрируются и используют специальный JavaBeans PropertyEditor, который может преобразовывать String paths в Resource объекты. Итак, если myBean имеет свойство template типа Resource, его можно настроить с помощью простой строки для этого ресурса, как показано в следующем примере: <bean id="myBean" class="..."> <property name

Интерфейс ResourceLoaderAware - это специальный интерфейс обратного вызова, который идентифицирует компоненты, которые должны быть предоставлены со ссылкой на ResourceLoader. В следующем листинге показано определение интерфейса ResourceLoaderAware: Java public interface ResourceLoaderAware { void setResourceLoader(ResourceLoader resourceLoader); } Kotlin interface ResourceLoaderAware { fun setResourceLoader(resourceLoader: ResourceLoader) } Когда класс реализует ResourceLoaderAware и развертывается в контексте приложения (как компонент, управляемый Spring), он распознается контекстом приложения как ResourceLoaderAware. Затем контекст приложения вызывает setResourceLoader(ResourceLoader), предоставляя себя в качестве аргумента (помните, все контексты приложения в Spring реализуют интерфейс ResourceLoader). Поскольку ApplicationContext является ResourceLoader, bean-компонент может также реализовать интерфейс ApplicationContextAware и напрямую использовать предо

Интерфейс ResourceLoader предназначен для реализации объектами, которые могут возвращать (то есть загружать) экземпляры Resource. В следующем листинге показано определение интерфейса ResourceLoader: Java public interface ResourceLoader { Resource getResource(String location); } Kotlin interface ResourceLoader { fun getResource(location: String): Resource } Все контексты приложения реализуют интерфейс ResourceLoader. Следовательно, все контексты приложения могут использоваться для получения экземпляров ресурса. Когда вы вызываете getResource() в конкретном контексте приложения, а указанный путь к местоположению не имеет определенного префикса, вы возвращаете тип ресурса, соответствующий этому конкретному контексту приложения. Например, предположим, что следующий фрагмент кода был запущен для экземпляра ClassPathXmlApplicationContext: Java Resource template = ctx.getResource("some/resource/path/myTemplate.txt"); Kotlin val template = ctx.ge

UrlResource UrlResource является оболочкой для java.net.URL и может использоваться для доступа к любому объекту, который обычно доступен с помощью URL, например к файлам, цели HTTP, цели FTP и т. д. Все URL-адреса имеют стандартизованное строковое представление, так что соответствующие стандартизированные префиксы используются для обозначения одного типа URL-адреса другим. Сюда входят file: для доступа к путям файловой системы, http: для доступа к ресурсам по протоколу HTTP, ftp: для доступа к ресурсам через FTP и другие. UrlResource создается кодом Java путем явного использования конструктора UrlResource, но часто создается неявно, когда вы вызываете метод API, который принимает аргумент String, предназначенный для представления пути. В последнем случае PropertyEditor JavaBeans в конечном итоге решает, какой тип ресурса создать. Если строка пути содержит хорошо известный (то есть, для PropertyEditor) префикс (например, classpath:), PropertyEditor создает соответствующий специализиро