Java Blog

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 и напрямую использовать предо...

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 создает соответствующий специализиро...

Стандартный класс Java java.net.URL и стандартные обработчики различных префиксов URL, к сожалению, недостаточно для любого доступа к низкоуровневым ресурсам. Например, не существует стандартизованной реализации URL-адреса, которая может использоваться для доступа к ресурсу, который необходимо получить из пути к классам или относительно ServletContext. Хотя можно зарегистрировать новые обработчики для специализированных префиксов URL (аналогично существующим обработчикам для префиксов, таких как http:), это, как правило, довольно сложно, и в интерфейсе URL по-прежнему отсутствуют некоторые желательные функции, такие как метод проверки наличия ресурса, на который указывает. Интерфейс Resource Интерфейс Resource в Spring призван стать более функциональным интерфейсом для абстрагирования доступа к ресурсам низкого уровня. В следующем листинге показано определение интерфейса Resource: Java public interface Resource extends InputStreamSource { boolean exists(); boolean isO...