Resource

스프링에서는 Resource 를 추상화하였습니다. 즉, java.net.URL 을 추상화했습니다.

 

이렇게 추상화를 한 이유는 java.net.URL이 기존에는 classpath를 기준으로 resource 를 가져오는 기능이 없었습니다.  이전 포스팅에서 설명한 ReourceLoader 를 이용해서 resource 를 가져와야했습니다. 이런 방법을 통일시켰습니다.

 

ApplicationContext를 생성할때 ClassPathXmlApplicationContext() 의 parameter가 내부적으로 resource 로 추상화됩니다. 내부에서는 resource 가 사용되고 있습니다. classpath 기준으로 parameter의 파일을 찾는 것입니다.

그 외에도 FileSystemXmlApplicationContext가 있는데 이는 parameter에 삽입한 문자열을 filesystem 경로 기준으로 찾아서 bean 설정파일로 사용하게 됩니다. 내부적으로는 둘은 다른 구현체를 사용합니다. 

 

Resource 의 구현체는 굉장히 많지만 UrlResource, ClassPathResource, FileSystemResource, ServletContextResource 등이 있습니다.

읽어들이는 resource 타입은 applicationContext 에 따라 결정이 됩니다. ServletContextResource 의 경우 GenericWebApplicationContext를 주로 사용하게됩니다. 

 

사용하는 ApplicationContext가 classpath 인지, FileSystem 인지, ServletContext인지에 따라 달라지게 됩니다.

ApplicationContext 타입에 상관없이 사용하고 싶다면 접두어를 사용하는것이 좋습니다. 접두어를 사용하게 되면 더 명시적으로 표현할 수 있습니다.

• classpath:test
• file://test.txt

ApplicationContext 과 resource 의 class를 콘솔에 찍어보면 어떤 타입인지 알 수 있습니다.

위와 같은 코드를 작성하면 아래와 같은 결과를 얻을 수 있습니다.

원래는 servlet resource 가 return 되는데 prefix를 classpath로 붙여줬기 때문에 classpathresource 가 return됩니다.

classpath라는 prefix를 제거하게 되면 context path부터 resource 를 찾게 되는데 spring boot 의 내장 톰캣은 context path가 지정되어 있지 않아 resource를 찾을 수 없습니다.