스프링부트

swgger는 api문서를 자동으로 만들어주는 라이브러리이다. 단순 문서 뿐 아니라 API를 문서내에서 parameter를 넣어가며 바로바로 실행 해볼 수 있다.rest api 제작 후 따로 테스트 페이지나 postman으로 실행해보는 대신 swagger 문서 만들어서

어노테이션 활용하면 그냥 함수들 알아서 구해줌@Timed("my.order") 타입이나 메서드 중에 적용할 수 있다. 타입에 적용하면 해당 타입의 모든 public 메서드에 타이머가 적용된다. configTimedAspect 를 적용해야 @Timed 에 AOP가 적용

계층적으로 보기편한 yaml파일이다. 프로필도 설정가능하고 한데 중요한점은 스프링은 이 파일을 .properties로 변환해서 읽는다는것만 생각해두자 config 파일설정 프로필 변경이 아니라 결제같이 로컬에서는 가짜로 실제로 배포할때 외부결제기능 붙이려고이런식으로

외부설정 깊이 네이밍따라서 그데로 객체로 만들어줄 수 있다. 설정값 객체my.datasource라고 되어있는 url, username, password를 위 객체 그데로받고설정파일에 my.datasource.etc로 한칸더 깊은건 내부 클래스로 하나더 만들어주면 그게

이전의 Environment가 통합으로 관리해준다는것 다시 확인 정보받고싶은 클레스예시appliation.propertiesbean으로 위 클레스에 값받기Integer.class이런식으로 두번째 매개변수에 변환될 객체형 넣어주면 그 자료형으로 변환해줌 이방법은 En

application.properties이 설정후에 아무 프로필도 안넣어주면 No active profile set, falling back to 1 default profile: "default"나오면서모든 값들 url, username 등 모두 null로 나옴 이

커맨드 라인 옵션 인수, 자바 시스템 속성, OS 환경변수는 모두 외부 설정을 key=value 형식으로 사용할 수 있는 방법추상화해서 하나의 객체로 모두 받을 수 있는 옵션 제공함 스프링은 이 문제를 Environment 와 PropertySource 라는 추상화를

자바 시스템 속성(Java System properties)은 실행한 JVM 안에서 접근 가능한 외부 설정이다. 추가로 자바가 내부에서 미리 설정해두고 사용하는 속성들도 있다. java -Durl=dev -jar app.jar -D VM 옵션을 통해서 key=valu

우리가 개발하다보면 테스트서버의 DB, 운영서버의 DB는 다르게 둬야한다. 이때 이 다른 주소를 어떻게 바꿔낄까?옛날에는 진짜 테스트서버 DB주소 넣고 빌드 -> jar1운영서버 DB주소코드바꾸고 빌드 -> jar2 이런식으로 2개를 따로 사용기도 했는데 이러면 중간

우리는 resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 이런 긴 파일에 설정 클레스를 넣어주니 그것이 등록되었다.어떤 과정을 거치기에 가능 할까? 스프링

라이브러리만들 녀석의(메모리출력) 프로젝트부트를 쓰면 실행가능jar가 만들어지기 때문에 순수 내 코드만 jar로 만들기위해 부트플러그인 안씀 예시 메모리 코드그리고 이 프로젝트를 ./gradlew clean build 빌드하면 순수 jar가 만들어짐project-v1

실시간으로 자바 메모리 사용량을 웹으로 확인하는 예제이다. JVM에서 메모리 정보를 실시간으로 조회하는 기능이다.max 는 JVM이 사용할 수 있는 최대 메모리, 이 수치를 넘어가면 OOM이 발생한다.total 은 JVM이 확보한 전체 메모리(JVM은 처음부터 max

JDBC를 사용하는 프로젝트를 한다고 가정해보자옛날같으면 무조건 설정파일에서 내가 사용할 모든 빈들 이런식으로 수동등록해야한다. -> 아무튼 이러면 JdbcTemplate사용시 정상동작 그런데 저 설정파일을 제거해보자 @Configuration이거 주석처리 이렇게

그냥 모든 라이브러리, 버전 다 넣고 호환성 확인도 내가 id 'io.spring.dependency-management' version '1.1.0' //추가 이거 넣으면 버전 미리 스프링에서 확인한거 알아서 넣어줌별다른게 아니라 깃헙 스프링공식쪽에 그레들로 대중적인

이전의 그냥 main함수안에서 톰캣실행 서블릿등등 만들고 연결하고실행하는코드 한번 모아서 함수하나로 정리 부트에 필요한 커스텀 어노테이션 제작(예시로는 컴포넌트스캔용으로하나만 추가기능 등록된것)그럼 실제 사용 main함수 ,클래스에서는우리가 보던 스프링부트와 같은 모

기존의 war파일은 무조건 서버위에서만 실행되던 파일이였다 그런데 톰캣도 자바인데 라이브러리로 내장으로 가질수는없을까? 해서 나온것이 내장톰캣 이정도 디펜던시를 사용하면 쓸 수 있다. jar생성 task도 추가 이전의hello.servlet.HelloServleth

스프링 라이브러리를 그레이들에 넣어주고 익숙한 컨트롤러를 만들어준다. 위의 컨트롤러를 수동 빈등록으로 넣어준다. 컴포넌트스캔은 그냥 안써봄 AppInit의 구현체는 모두 자동으로 서블릿컨테이너에서 실행되니깐 하나더 만들어주면서 스프링 컨테이너(빈관리)생성 -> 스

WAS를 실행하는 시점에 필요한 초기화 작업들이 있다. 서비스에 필요한 필터와 서블릿을 등록하고, 여기에 스프링을 사용한다면 스프링 컨테이너를 만들고, 서블릿과 스프링을 연결하는 디스페처 서블릿도 등록해야 한다.WAS가 제공하는 초기화 기능을 사용하면, WAS 실행 시

톰캣 실행법 다운받아서 -> 권한주고 -> 실행명령어기본적으로 8080포트 사용 날것의 자바 gradle설정 war로 빌드하겠다는 설정과 최소한의 서블릿 라이브러리 예시로 /src/main에 webapp이라는 폴더생성후 index.html파일 생성간단 예시서블릿도

스프링에는 JDBC -> 하이버네이트 -> JPA,QueryDSL 등의 DB 연결과 쿼리사용의 기술들이 있습니다. 자바의 객체지향적은 부분과 RDB를 매칭하기위해 많은 노력과 기술들이 나왔는데요.이런 많은 기술들을 어떻게 사용하는것이 올바른것인지 고민하게 되었습니다.

이 트랜잭션의 전파의 쉬운 예시는 service - repository 관계이다. 기본적으로 데이터를 하나씩 조회하는 repository에 @Transactional이 적혀있고 이것들을 사용하는 service단에도 메소드마다 @Transactional을 달아주면서 자

기본적으로 자세한것 우선 내부 호출에는 적용 안됨 이런상황에서 two();는 this.two()가 생략된것 즉 this = 자신의 인스턴스 본체 = 프록시 객체가 아닌 진짜너셕을 호출한다는 뜻해결법은 클래스 나누기 의존관계주입, 생성자 직후 @Postconstru

이전에 작성한 서블릿이다. 자바안에서 html을 냅다 작성한다고 생각하면 된다.특별할게없지만 그렇기에 진짜 이게 맞나 생각이 들정도다. 위의 상황을 개선하고자 html안에서 필요한것들을 자바 코드로 조작하는 방법인거같다. 편하게 html을 작성하면서 필요한곳에 자바 코

서블릿은 톰캣 같은 웹 애플리케이션 서버를 직접 설치하고,그 위에 서블릿 코드를 클래스 파일로 빌드해서 올린 다음, 톰캣 서버를 실행하면 된다. 하지만 이 과정은 매우 번거롭다.스프링 부트는 톰캣 서버를 내장하고 있으므로, 톰캣 서버 설치 없이 편리하게 서블릿 코드를

우리가 자동으로 등록된다고 생각한 이 빈도 언제 시작되고 어떻게 사라지는지 알아야한다.스프링 빈의 이벤트 라이프사이클스프링 컨테이너 생성 스프링 빈 생성 의존관계 주입 초기화 콜백 사용 소멸전 콜백 스프링종료초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후

생성자 주입수정자 주입(setter 주입)필드 주입일반 메서드 주입일반적으로 사용하는 생성자주입롬복라이브러리를 사용하고 final을 이용해서 단 하나만 생기는 생성자를만들면 이런식으로 만 써도 의존관계 자동주입이 된다. 보통 이렇게 많이 쓴다.가끔 커스텀이 필요할때 이

스프링빈에 등록할때 지금까지는 자바코드로 등록을 했다. 이렇게 등록해야할 빈이 많이지면 설정정보도 커지고 누락하는 문제도 생긴다.그래서 클레스를 만들면서 파일이 있으면 그냥 빈으로 등록해주는 방법이 있다 그것이 컴포넌트 스캔이다.@Component 클레스에 붙여주면된다

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.기존의 일반적인 클레스는 요청을 할 때 마다 객체를 새로생성한다. 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다! 메모리 낭비가 심하다.기본적으로 싱글톤을 유지하려면 위와

ApplicationContext 를 스프링 컨테이너라 한다.ApplicationContext 는 인터페이스이다.이렇게 등록을 하면 스프링 컨테이너에 AppConfig.class에 들어있는 모든 클레스들을 스프링 빈에 등록한다.여기에는 빈이름과 실제 객체가 키벨류처럼

이 클레스를 이용해서 사용되는 모든 클레스의 연결관계를 설정해준다.어떤 클레스들이 생성되어야하고 생성될때 어떤 다른 클레스를 가져가 써야하고 지금 무엇을 사용할지 이 설정클레스에서 전부 해주는것이다. 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체

• 스프링은 자바 언어 기반의 프레임워크• 자바 언어의 가장 큰 특징 - 객체 지향 언어• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크• 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크• 추상화 - 인터페이스• 캡슐화 -

빈 스코프란?지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지된다고 학습했다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.스프링은 다

스프링 빈은 간단하게 다음과 같은 라이프사이클을 가진다.객체 생성 > 의존관계 주입 (생성자주입은 처음 객체생성때 무조건 파라미터가 있어야해서 들어가긴하지만 일단 나중에 생기는게 맞음)스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용

결론부터 이야기하면, 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세다. 스프링은@Component 뿐만 아니라 @Controller , @Service , @Repository 처럼 계층에 맞추어 일반적인애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한

이전 포스트로 객체지향적으로 외부 앱설정이라는 클레스에서 한 클레스가 부모인터페이서의 어떤 구현체를 사용할것인가를 조립해주는 클레스를 따로 만드었다.스프링은 이와같은 구조를 내부적으로 잘 정리되게 지원한다 그것이 스프링 컨테이너와 빈이다.@Configuration어노테

Member라는 엔티티가 있다고 하자 나는 Member의 이름정도만 알면되는데 이를 조회할때 Member와 연결되어있는 Team 엔티티가 있다면 얘까지 전부 조인으로 가져와야할까?그럼 언제 Team을 가져와야할까?이때 이를 효율적으로 만들어주는것이 프록시 이다.이러한

스프링을 연습하며 예외를 처리할때가 종종있는데 연습 코드에 어떤것은 IllegalStateException 같은 표준 예외처리를 어떤 코드는 IllegalStateException("이미 배송완료된 상품은 취소가 불가능합니다.");이런식의 custom exception

스프링 컨테이너는 스프링에서 자바 객체들을 관리하는 공간을 말합니다. 자바 객체를 스프링에선 빈(Bean)이라고 하는데, 스프링 컨테이너에서는 이 빈의 생성부터 소멸까지를 개발자 대신 관리해주는 곳이라고 할 수 있습니다.쉽게 이해하기위해 DI(Dependency Inj

스프링은 controller에 요청이오면 그에 해당하는 리턴을 통해 응답을준다localhost:8080/hello로 응답이 들어오면 @GetMapping("hello")에서 잡아서 리턴값인 hello를 resources:templates/ + hello + .html