분류 전체보기 1341

Ch04. 자동 구성(Auto Configuration) - 순수 라이브러리 만들기

@AutoConfiguration을 이해하기 위해서는 그전에 먼저 라이브러리가 어떻게 사용되는지 이해하는 것이 필요하다. 여러분이 만든 실시간 자바 Memory 조회 기능이 좋다고 소문이 나서, 여러 프로젝트에서 사용하고 싶어한다. 이 기능을 여러 곳에서 사용할 수 있도록 라이브러리로 만들어보자.(참고로 라이브러리를 만들 때는 스프링 부트 플러그인 기능을 사용하지 않고 진행한다.) build.gradle plugins { id 'java' } group = 'memory' sourceCompatibility = '17' repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-star..

Ch04. 자동 구성(Auto Configuration) - @Conditional

@Conditional 앞서 만든 메모리 조회 기능을 항상 사용하는 것이 아니라 특정 조건일 때만 해당 기능이 활성화 되도록 해보자. 예를 들어서 개발 서버에서 확인 용도로만 해당 기능을 사용하고, 운영 서버에서는 해당 기능을 사용하지 않는 것이다. 여기서 핵심은 소스코드를 고치지 않고 이런 것이 가능해야 한다는 점이다. 프로젝트를 빌드해서 나온 빌드 파일을 개발 서버에도 배포하고, 같은 파일을 운영서버에도 배포해야 한다. 같은 소스 코드인데 특정 상황일 때만 특정 빈들을 등록해서 사용하도록 도와주는 기능이 바로 @Conditional 이다. 참고로 이 기능은 스프링 부트 자동 구성에서 자주 사용한다. 지금부터 @Conditional에 대해서 자세히 알아보자. 이름 그대로 특정 조건을 만족하는가 하지 않..

Ch04. 자동 구성(Auto Configuration) - 자동 구성 직접 만들기(기반 예제)

외부 라이브러리 Memory라는 외부 라이브러리라고 생각하고 만들어 보자(패키지도 분리했다) Memory public class Memory { private long used; private long max; public Memory(long used, long max) { this.used = used; this.max = max; } public long getMax() { return max; } public long getUsed() { return used; } @Override public String toString() { return "Memory{" + "used=" + used + ", max=" + max + '}'; } } used : 사용중인 메모리 max : 최대 메모리 쉽게 ..

Ch04. 자동 구성(Auto Configuration) - 스프링 부트의 자동 구성

스프링 부트는 자동 구성(Auto Configuration)이라는 기능을 제공하는데, 일반적으로 자주 사용하는 수많은 빈들을 자동으로 등록해 주는 기능이다. 앞서 우리가 살펴보았던 JdbcTemplate , DataSource , TransactionManager 모두 스프링 부트가 자동 구성을 제공해서 자동으로 스프링 빈으로 등록된다. 이러한 자동 구성 덕분에 개발자는 반복적이고 복잡한 빈 등록과 설정을 최소화하고 애플리케이션 개발을 빠르게 시작할 수 있다. autoconfigure 하위에 많은 자동설정 패키지들이 존재하는 것을 알 수 있다. JdbcTemplateAutoConfiguration @AutoConfiguration(after = DataSourceAutoConfiguration.class..

Ch04. 자동 구성(Auto Configuration) - 자동 구성 확인

DbConfigTest @Slf4j @SpringBootTest class DbConfigTest { @Autowired DataSource dataSource; @Autowired TransactionManager transactionManager; @Autowired JdbcTemplate jdbcTemplate; @Test void checkBean(){ log.info("dataSource= {}", dataSource); log.info("transactionManager= {}", transactionManager); log.info("jdbcTemplate= {}", jdbcTemplate); assertThat(dataSource).isNotNull(); assertThat(transact..

Ch04. 자동 구성(Auto Configuration) - 예제 만들기

build.gradle plugins { id 'org.springframework.boot' version '3.0.2' id 'io.spring.dependency-management' version '1.1.0' id 'java' } group = 'hello' version = '0.0.1-SNAPSHOT' sourceCompatibility = '17' configurations { compileOnly { extendsFrom annotationProcessor } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter-jdbc' implementatio..

Ch03. 스프링 부트 스타터와 라이브러리 관리 - 스프링 부트 스타터

앞서 보았듯이 웹 프로젝트를 하나 실행하려면 생각보다 수 많은 라이브러리가 필요하다. 스프링 웹 MVC, 내장 톰캣, JSON 처리, 스프링 부트 관련, LOG, YML 등등 다양한 라이브러리가 사용된다. 개발자 입장에서는 그냥 웹 프로젝트를 하나 시작하고 싶은 것이고, 일반적으로 많이 사용하는 대중적인 라이브러리들을 포함해서 간단하게 시작하고 싶을 것이다. 스프링 부트는 이런 문제를 해결하기 위해 프로젝트를 시작하는데 필요한 관련 라이브러리를 모아둔 스프링 부트 스타터를 제공한다. 스프링 부트 스타터 덕분에 누구나 쉽고 편리하게 프로젝트를 시작할 수 있다. build.gradle - dependencies 수정 dependencies { //3. 스프링 부트 스타터 implementation 'org...

Ch03. 스프링 부트 스타터와 라이브러리 관리 - 스프링 부트 라이브러리 버전 관리

스프링 부트는 개발자 대신에 수많은 라이브러리의 버전을 직접 관리해 준다. 이제 개발자는 원하는 라이브러리만 고르고 라이브러리의 버전은 생략해도 된다. 그러면 스프링 부트가 부트 버전에 맞춘 최적화된 라이브러리 버전을 선택해 준다.. 버전 관리 기능을 사용하려면 io.spring.dependency-management 플러그인을 사용해야 한다. build.gradle - plugins 수정 plugins { id 'org.springframework.boot' version '3.0.2' id 'io.spring.dependency-management' version '1.1.0' id 'java' } build.gradle - dependencies 수정 dependencies { //스프링 웹, MV..

Ch03. 스프링 부트 스타터와 라이브러리 관리 - 라이브러리 직접 관리

스프링 부트가 제공하는 편리한 라이브러리 관리 기능을 사용해 보기 전에, 잠깐 과거로 돌아가서 직접 라이브러리를 하나하나 고르고 설정하는 방법을 알아보자. build.gradle plugins { id 'org.springframework.boot' version '3.0.2' //id 'io.spring.dependency-management' version '1.1.0' id 'java' } group = 'hello' version = '0.0.1-SNAPSHOT' sourceCompatibility = '17' //스프링 부트 외부 라이브러리 버전 변경 //ext['tomcat.version']='10.1.4' configurations { compileOnly { extendsFrom annot..

Ch02. 스프링 부트와 내장 톰캣 - 스프링 부트 실행 가능 Jar

Fat Jar는 하나의 Jar 파일에 라이브러리의 클래스와 리소스를 모두 포함했다. 그래서 실행에 필요한 모든 내용을 하나의 JAR로 만들어서 배포하는 것이 가능했다. Fat Jar는 명확한 문제를 가지고 있다. Fat Jar의 단점 어떤 라이브러리가 포함되어 있는지 확인하기 어렵다. 모두 class 로 풀려있으니 어떤 라이브러리가 사용되고 있는지 추적하기 어렵다. 파일명 중복을 해결할 수 없다. 클래스나 리소스 명이 같은 경우 하나를 포기해야 한다. 이것은 심각한 문제를 발생한다. 예를 들어서 서블릿 컨테이너 초기화에서 학습한 부분을 떠올려 보자. META-INF/services/jakarta.servlet.ServletContainerInitializer 이 파일이 여러 라이브러리( jar )에 있을..