Resources

Resources

2024. 11. 15. 15:05ㆍSpring Framework/Resources

이 챕터에서는 Spring이 리소스를 처리하는 방법과 Spring에서 리소스를 다루는 방법에 대해 다룹니다.

Introduction

자바의 표준 java.net.URL 클래스와 다양한 URL 접두사에 대한 표준 핸들러는 저수준 리소스에 대한 모든 접근에 충분히 적합하지 않은 경우가 종종 있습니다. 예를 들어, 클래스패스에서 가져와야 하는 리소스나 ServletContext를 기준으로 상대적인 리소스에 접근하기 위한 표준화된 URL 구현이 없습니다. 특수한 URL 접두사(예: http:와 같은 기존 핸들러와 유사)에 대한 새로운 핸들러를 등록하는 것은 가능하지만, 이는 일반적으로 매우 복잡하며, URL 인터페이스는 리소스의 존재 여부를 확인하는 메서드와 같은 일부 필요한 기능이 여전히 부족합니다.

The Resource Interface

Spring의 org.springframework.core.io 패키지에 위치한 Resource 인터페이스는 저수준 리소스에 대한 접근을 추상화하기 위한 더 강력한 인터페이스로 설계되었습니다. 다음 목록은 Resource 인터페이스의 개요를 제공합니다. 자세한 내용은 Resource의 javadoc을 참조하세요.

public interface Resource extends InputStreamSource {

    boolean exists();

    boolean isReadable();

    boolean isOpen();

    boolean isFile();

    URL getURL() throws IOException;

    URI getURI() throws IOException;

    File getFile() throws IOException;

    ReadableByteChannel readableChannel() throws IOException;

    long contentLength() throws IOException;

    long lastModified() throws IOException;

    Resource createRelative(String relativePath) throws IOException;

    String getFilename();

    String getDescription();
}

Resource 인터페이스의 정의에서 볼 수 있듯이, 이 인터페이스는 InputStreamSource 인터페이스를 확장합니다. 다음은 InputStreamSource 인터페이스의 정의를 보여줍니다:

public interface InputStreamSource {

    InputStream getInputStream() throws IOException;
}

Resource 인터페이스의 가장 중요한 메서드 중 일부는 다음과 같습니다:

getInputStream(): 리소스를 찾고 open하고 리소스에서 읽을 수 있는 InputStream을 반환합니다. 각 호출은 새로운 InputStream을 리턴해야 하며, 스트림을 close하는 것은 호출자의 책임입니다.
exists(): 이 리소스가 실제로 물리적 형태로 존재하는지 여부를 나타내는 boolean 값을 리턴합니다.
isOpen(): 이 리소스가 열린 스트림을 가진 핸들을 나타내는지 여부를 나타내는 boolean 값을 반환합니다. true인 경우, InputStream은 여러 번 읽을 수 없으며, 한 번만 읽고 닫아야 리소스 누수를 방지할 수 있습니다. InputStreamResource를 제외한 일반적인 리소스 구현의 경우 false를 리턴합니다.
getDescription(): 이 리소스에 대한 설명(Description)을 리턴하며, 리소스를 처리하는 동안 에러 출력에 사용됩니다. 종종 완전한 파일 이름이나 실제 URL을 나타냅니다.

기타 메서드는 리소스를 나타내는 실제 URL이나 File 객체를 얻을 수 있도록 합니다(디폴트 구현이 해당 기능을 지원하는 경우).

Resource 인터페이스의 일부 구현은 쓰기 지원 리소스에 대해 확장된 WritableResource 인터페이스도 구현합니다.

Spring은 자체적으로 Resource 추상화를 광범위하게 사용하며, 리소스가 필요한 많은 메서드 시그니처의 아규먼트 타입으로 사용합니다. Spring API의 일부 메서드(예: 다양한 ApplicationContext 구현체의 생성자)는 문자열을 받고, 단순한 형식의 문자열을 사용하여 해당 컨텍스트 구현에 적합한 Resource를 생성하거나, 문자열 경로에 특별한 접두사를 사용하여 특정 Resource 구현이 생성 및 사용되도록 호출자가 지정할 수 있습니다.

Resource 인터페이스는 Spring과 함께 또는 Spring에서 자주 사용되지만, 다른 Spring 기능을 알거나 신경 쓰지 않더라도 자체 코드에서 리소스에 접근하기 위한 일반적인 유틸리티 클래스로 매우 편리하게 사용할 수 있습니다. 이는 코드가 Spring에 결합되지만, 실제로는 이 작은 유틸리티 클래스 집합에만 결합되며, URL을 대체할 수 있는 더 강력한 도구로서 사용할 수 있고, 이 목적을 위해 사용할 다른 라이브러리와 동등하다고 간주할 수 있습니다.

Resource 추상화는 자바의 리소스 기능을 대체하지 않고, 가능한 경우 이를 래핑합니다. 예를 들어, UrlResource는 URL을 래핑하고, 래핑한 URL을 사용하여 작업을 수행합니다.

Built-in Resource Implementations

Spring은 여러 빌트인 Resource 구현을 포함하고 있습니다

Spring에서 사용 가능한 Resource 구현의 전체 목록은 Resource javadoc의 "All Known Implementing Classes" 섹션을 참조하십시오.

UrlResource

UrlResource는 java.net.URL을 감싸며, 파일, HTTPS 타겟, FTP 타겟 등 일반적으로 URL을 통해 접근할 수 있는 모든 객체에 접근하는 데 사용할 수 있습니다. 모든 URL은 표준화된 문자열 표현을 가지며, 적절한 표준 접두사를 사용하여 URL 타입을 구분합니다. 예를 들어, 파일 시스템 경로에 접근하기 위한 file:, HTTPS 프로토콜을 통해 리소스에 접근하기 위한 https:, FTP를 통해 리소스에 접근하기 위한 ftp: 등이 있습니다.

UrlResource는 Java 코드에서 명시적으로 UrlResource 생성자를 사용하여 생성할 수 있지만, 일반적으로 경로를 나타내는 문자열 아규먼트를 받는 API 메서드를 호출할 때 암묵적으로 생성됩니다. 후자의 경우, JavaBeans PropertyEditor가 최종적으로 어떤 타입의 Resource를 생성할지 결정합니다. 경로 문자열에 PropertyEditor가 인식하는 접두사(예: classpath:)가 포함된 경우, 해당 접두사에 적합한 특수 Resource를 생성합니다. 그러나 접두사를 인식하지 못하면 문자열이 표준 URL 문자열이라고 가정하고 UrlResource를 생성합니다.

ClassPathResource

이 클래스는 클래스패스에서 가져와야 하는 리소스를 나타냅니다. 리소스를 로드하기 위해 스레드 컨텍스트 클래스 로더, 지정된 클래스 로더, 또는 지정된 클래스를 사용할 수 있습니다.

이 Resource 구현은 클래스패스 리소스가 파일 시스템에 존재하는 경우 java.io.File로의 해석을 지원하지만, 클래스패스 리소스가 JAR 안에 있고 파일 시스템으로 확장되지 않은 경우(서블릿 엔진이나 환경에 따라)에는 지원하지 않습니다. 이를 해결하기 위해 다양한 Resource 구현은 항상 java.net.URL로의 해석을 지원합니다.

ClassPathResource는 Java 코드에서 명시적으로 ClassPathResource 생성자를 사용하여 생성할 수 있지만, 경로를 나타내는 문자열 아규먼트를 받는 API 메서드를 호출할 때 암묵적으로 생성되는 경우가 많습니다. 후자의 경우, JavaBeans PropertyEditor는 문자열 경로에 있는 특별한 접두사 classpath:를 인식하고, 해당 경우 ClassPathResource를 생성합니다.

FileSystemResource

이 클래스는 java.io.File 핸들을 위한 Resource 구현입니다. 또한, Spring의 표준 문자열 기반 경로 변환을 적용하면서 모든 작업을 java.nio.file.Files API를 통해 수행하여 java.nio.file.Path 핸들도 지원합니다. 순수하게 java.nio.file.Path 기반의 지원이 필요한 경우에는 PathResource를 사용하는 것이 좋습니다. FileSystemResource는 File 및 URL로의 해석을 지원합니다.

PathResource

이 클래스는 java.nio.file.Path 핸들을 위한 Resource 구현으로, 모든 작업과 변환을 Path API를 통해 수행합니다. File 및 URL로의 해석을 지원하며, 확장된 WritableResource 인터페이스도 구현합니다. PathResource는 FileSystemResource의 순수한 java.nio.file.Path 기반 대안으로, 다른 createRelative 동작을 제공합니다.

ServletContextResource

이 클래스는 ServletContext 리소스를 위한 `Resource` 구현으로, 관련 웹 애플리케이션의 루트 디렉토리 내에서 상대 경로를 해석합니다.

항상 스트림 액세스와 URL 액세스를 지원하지만, 웹 애플리케이션 아카이브가 확장되어 리소스가 물리적으로 파일 시스템에 존재하는 경우에만 java.io.File 액세스를 허용합니다. 해당 리소스가 파일 시스템에서 확장되었는지, JAR에서 직접 접근되었는지, 또는 데이터베이스와 같은 다른 위치에서 접근되었는지는 Servlet Container에 따라 결정됩니다.

InputStreamResource

InputStreamResource는 주어진 InputStream을 위한 Resource 구현입니다. 특정한 Resource 구현이 적용되지 않는 경우에만 사용해야 합니다. 특히, 가능한 경우 ByteArrayResource나 파일 기반의 다른 Resource 구현을 사용하는 것이 좋습니다.

다른 Resource 구현과 달리, 이것은 이미 already-opened 리소스를 위한 디스크립터입니다. 따라서 isOpen() 메서드는 true를 리턴합니다. 리소스 디스크립터를 다른 곳에 보관하거나 스트림을 여러 번 읽어야 하는 경우에는 사용하지 말아야 합니다.

ByteArrayResource

이 클래스는 주어진 바이트 배열을 위한 Resource 구현입니다. 주어진 바이트 배열로부터 ByteArrayInputStream을 생성합니다.

단일 사용만 가능한 InputStreamResource를 사용하지 않고도 주어진 바이트 배열로부터 콘텐츠를 로드할 때 유용합니다.

The ResourceLoader Interface

ResourceLoader 인터페이스는 Resource 인스턴스를 리턴(즉, 로드)할 수 있는 객체에 의해 구현되도록 설계되었습니다. 다음은 ResourceLoader 인터페이스 정의를 보여줍니다:

public interface ResourceLoader {

	Resource getResource(String location);

	ClassLoader getClassLoader();
}

모든 애플리케이션 컨텍스트는 ResourceLoader 인터페이스를 구현합니다. 따라서 모든 애플리케이션 컨텍스트를 사용하여 Resource 인스턴스를 얻을 수 있습니다.

특정 애플리케이션 컨텍스트에서 getResource()를 호출할 때, 지정된 경로가 특정 접두사를 포함하지 않으면 해당 애플리케이션 컨텍스트에 적합한 Resource 타입이 반환됩니다. 예를 들어, 다음 코드 스니펫이 ClassPathXmlApplicationContext 인스턴스에서 실행된다고 가정해 보겠습니다:

Resource template = ctx.getResource("some/resource/path/myTemplate.txt");

ClassPathXmlApplicationContext에서는 해당 코드가 ClassPathResource를 반환합니다. 동일한 메서드가 FileSystemXmlApplicationContext 인스턴스에서 실행된다면 FileSystemResource를 리턴하며, WebApplicationContext에서는 ServletContextResource를 리턴합니다. 이와 같이 각 컨텍스트에 적합한 객체를 리턴합니다.

결과적으로, 특정 애플리케이션 컨텍스트에 적합한 방식으로 리소스를 로드할 수 있습니다.

반면, 다음 예제와 같이 특별한 접두사 classpath:를 지정하면 애플리케이션 컨텍스트 타입에 상관없이 ClassPathResource를 강제로 사용하도록 할 수도 있습니다:

Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");

마찬가지로, 표준 java.net.URL 접두사 중 하나를 지정하여 UrlResource를 강제로 사용할 수 있습니다. 다음 예제는 file https 접두사를 사용하는 경우를 보여줍니다:

Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt");

Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt");

다음 테이블은 문자열(String) 객체를 Resource 객체로 변환하는 전략을 요약한 것입니다:

Table 1. Resource strings

Prefix	Example	Explanation
classpath:	classpath:com/myapp/config.xml	Loaded from the classpath.
file:	file:///data/config.xml	Loaded as a URL from the filesystem. See also FileSystemResource Caveats.
https:	https://myserver/logo.png	Loaded as a URL.
(none)	/data/config.xml	Depends on the underlying ApplicationContext.

The ResourcePatternResolver Interface

ResourcePatternResolver 인터페이스는 ResourceLoader 인터페이스를 확장한 것으로, 위치 패턴(예: Ant 스타일 경로 패턴)을 Resource 객체로 해석하는 전략을 정의합니다.

public interface ResourcePatternResolver extends ResourceLoader {

	String CLASSPATH_ALL_URL_PREFIX = "classpath*:";

	Resource[] getResources(String locationPattern) throws IOException;
}

위에서 볼 수 있듯이, 이 인터페이스는 클래스패스에 있는 모든 일치하는 리소스를 위한 특별한 classpath*: 리소스 접두사도 정의합니다. 이 경우, 리소스 위치는 플레이스홀더가 없는 경로여야 합니다(예: classpath*:/config/beans.xml). JAR 파일이나 클래스패스의 다른 디렉터리에 동일한 경로와 이름을 가진 여러 파일이 포함될 수 있습니다. classpath*: 리소스 접두사를 사용한 와일드카드 지원에 대한 자세한 내용은 "Application Context Constructor Resource Paths의 와일드카드" 및 해당 하위 섹션을 참조하세요.

전달된 ResourceLoader(예: ResourceLoaderAware 의미 체계를 통해 제공된 것)가 이 확장된 인터페이스를 구현하는지도 확인할 수 있습니다.

PathMatchingResourcePatternResolver는 독립 실행형 구현으로, ApplicationContext 외부에서도 사용할 수 있으며, Resource[] 빈 속성을 채우기 위해 ResourceArrayPropertyEditor에서도 사용됩니다. PathMatchingResourcePatternResolver는 지정된 리소스 위치 경로를 하나 이상의 일치하는 Resource 객체로 해석할 수 있습니다. 소스 경로는 대상 Resource와의 일대일 매핑을 가지는 단순 경로일 수도 있고, 특별한 classpath*: 접두사 및/또는 내부 Ant 스타일 정규 표현식을 포함할 수도 있습니다(이는 Spring의 org.springframework.util.AntPathMatcher 유틸리티를 사용하여 매칭됩니다). 후자는 모두 효과적으로 와일드카드로 간주됩니다.

표준 ApplicationContext에서 디폴트 ResourceLoader는 실제로 ResourcePatternResolver 인터페이스를 구현한 PathMatchingResourcePatternResolver의 인스턴스입니다. ApplicationContext 인스턴스 자체도 동일하게 ResourcePatternResolver 인터페이스를 구현하며, 디폴트 PathMatchingResourcePatternResolver에 위임합니다.

The ResourceLoaderAware Interface

ResourceLoaderAware 인터페이스는 ResourceLoader 참조를 제공받기를 기대하는 구성 요소를 식별하는 특수 콜백 인터페이스입니다. 다음은 ResourceLoaderAware 인터페이스의 정의를 보여줍니다:

public interface ResourceLoaderAware {

	void setResourceLoader(ResourceLoader resourceLoader);
}

클래스가 ResourceLoaderAware를 구현하고 애플리케이션 컨텍스트에 배포되면(Spring에서 관리되는 빈으로), 애플리케이션 컨텍스트는 해당 클래스를 ResourceLoaderAware로 인식합니다. 이후 애플리케이션 컨텍스트는 setResourceLoader(ResourceLoader) 메서드를 호출하며, 자신을 아규먼트로 제공합니다(참고로, Spring의 모든 애플리케이션 컨텍스트는 ResourceLoader 인터페이스를 구현합니다).

ApplicationContext는 ResourceLoader이기 때문에, 빈이 ApplicationContextAware 인터페이스를 구현하여 제공된 애플리케이션 컨텍스트를 직접 사용하여 리소스를 로드할 수도 있습니다. 그러나 일반적으로 필요한 것이 리소스 로딩뿐이라면, 특화된 ResourceLoader 인터페이스를 사용하는 것이 더 좋습니다. 이렇게 하면 코드가 전체 Spring ApplicationContext 인터페이스가 아니라 리소스 로딩 인터페이스(유틸리티 인터페이스로 간주 가능)에만 결합됩니다.

애플리케이션 구성 요소에서는 ResourceLoaderAware 인터페이스를 구현하는 대신, ResourceLoader를 자동 연결(autowiring)하는 방법을 사용할 수도 있습니다. 전통적인 생성자 및 byType 자동 연결 모드(Autowiring Collaborators에서 설명됨)는 각각 생성자 아규먼트나 세터 메서드 파라미터에 ResourceLoader를 제공할 수 있습니다. 더 큰 유연성(필드 및 다중 파라미터 메서드의 자동 연결 포함)을 위해, 애노테이션 기반 자동 연결 기능을 사용하는 것을 고려하세요. 이 경우, ResourceLoader는 @Autowired 애노테이션이 포함된 필드, 생성자 아규먼트, 또는 메서드 파라미터에 ResourceLoader 타입을 기대하는 경우 자동으로 연결됩니다. 자세한 내용은 Using @Autowired를 참조하세요.

와일드카드가 포함된 리소스 경로를 사용하거나 classpath*: 리소스 접두사를 사용하는 하나 이상의 Resource 객체를 로드하려면, ResourceLoader 대신 ResourcePatternResolver 인스턴스를 애플리케이션 구성 요소에 자동 연결(autowiring)하는 것을 고려하세요.

Resources as Dependencies

빈 자체가 동적 프로세스를 통해 리소스 경로를 결정하고 제공하려는 경우, 해당 빈이 ResourceLoader 또는 ResourcePatternResolver 인터페이스를 사용하여 리소스를 로드하는 것이 적합할 수 있습니다. 예를 들어, 특정 리소스가 사용자의 역할에 따라 달라지는 템플릿을 로드하는 경우가 이에 해당합니다.

반면, 리소스가 정적일 경우, ResourceLoader 인터페이스(또는 ResourcePatternResolver 인터페이스)를 완전히 제거하고, 빈이 필요한 Resource 프로퍼티를 노출하며 해당 프로퍼티가 빈에 주입되도록 기대하는 것이 더 적합합니다.

이러한 프로퍼티를 주입하기 쉽게 만들어주는 것은, 모든 애플리케이션 컨텍스트가 문자열 경로를 Resource 객체로 변환할 수 있는 특수한 JavaBeans PropertyEditor를 등록하고 사용하기 때문입니다. 예를 들어, 다음 MyBean 클래스는 Resource 타입의 template 프로퍼티를 가지고 있습니다.

public class MyBean {

	private Resource template;

	public setTemplate(Resource template) {
		this.template = template;
	}

	// ...
}

MyBean 클래스가 애노테이션 기반 구성에 맞게 리팩터링되면, myTemplate.txt의 경로를 template.path라는 키로 저장할 수 있습니다. 예를 들어, Spring Environment에 제공되는 프로퍼티 파일에 저장할 수 있습니다(자세한 내용은 Environment Abstraction 참조). 그런 다음 @Value 애노테이션과 프로퍼티 플레이스홀더를 사용하여 템플릿 경로를 참조할 수 있습니다(Using @Value 참조). Spring은 템플릿 경로의 값을 문자열로 가져오고, 특수한 PropertyEditor가 해당 문자열을 Resource 객체로 변환하여 MyBean 생성자에 주입합니다. 다음 예제는 이를 구현하는 방법을 보여줍니다.

@Component
public class MyBean {

	private final Resource template;

	public MyBean(@Value("${template.path}") Resource template) {
		this.template = template;
	}

	// ...
}

클래스패스 내 여러 위치(예: 클래스패스에 있는 여러 JAR)에서 동일한 경로 아래에 있는 여러 템플릿을 지원하려면, 특별한 classpath*: 접두사와 와일드카드를 사용하여 templates.path 키를 classpath*:/config/templates/*.txt로 정의할 수 있습니다. MyBean 클래스를 다음과 같이 재정의하면, Spring은 템플릿 경로 패턴을 Resource 객체 배열로 변환하여 MyBean 생성자에 주입할 수 있습니다.

@Component
public class MyBean {

	private final Resource[] templates;

	public MyBean(@Value("${templates.path}") Resource[] templates) {
		this.templates = templates;
	}

	// ...
}

이하 생략...

순다랜드