spring

서블릿은 웹 서버의 성능을 향상하기 위해 사용되는 자바 클래스의 일종이다. 기존에 서버는 정적인 자료(HTML, 사진, 글 등)만을 주고받았다. 하지만 웹에 다양한 기능이 요구되면서 정적인 자료뿐만 아니라 사용자 요구에 맞춘 동적인 페이지들을 만들 필요가 생겼다. 이를

spring-boot-starter-webspring-webmvc: 스프링 웹 MVCspring-boot-starter-tomcat: 톰캣(웹서버)spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View)spring-boot-starter(

핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타웹 기술 : 스프링 MVC, 스프링 WebFlux데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원기술 통합: 캐시, 이메일, 원격접근, 스케줄링테스트: 스프링 기반 테스트 지원언어: 코틀린, 그

IoC, DI, Container 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고 연결하고, 실행했다. 한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실

웹 애플리케이션과 싱글톤 직접 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 처리할 때 마다 객체를 새로 생성한다. 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다. -> 메모리 낭비가 심하다. 해결방안은 해당 객체

이 전까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다.등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다.그래서 스프링은

의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법 특징 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다. 불변

빈 생명주기 콜백 시작 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 지점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 간단하게 외부 네트워크에 미리 연결하는

로그인을 해야 실행할 수 있는 기능이 존재각 기능별로 로그인 유무 검증을 할 수 있지만 이것은 매우 귀찮고 유지보수 측면에서 좋지 않다.이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 것을 공통 관심사라고 한다.이러한 공통 관심사는 스프링의 AOP로도 해결할 수

서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다. 둘 다 웹과 관련된 공통 관심 사항을 처리하지만, 적용되는 순서와 범위, 그리고 사용방법이 다르다.스프링 인터셉터 흐름HTTP 요청 -> WAS -> 필터 -> 서블릿 -

로그인 검증 예시controller어노테이션 생성@Target(ElementType.PARAMETER): 파라미터에만 사용@Retention(RetentionPolicy.RUNTIME): 리플렉션 등을 활용할 수 있도록 런타임까지 애노테이션 정 보가 남아있음Argume

API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다.WebServerCustomizerController결과에러 발생 -> WebServerCustomizer -> 컨트롤러가 해당 url 매핑 -> returnBasicErro

스프링 부트가 기본으로 제공하는 ExceptionResolver는 다음과 같다.1\. ExceptionHandlerExceptionResolver2\. ResponseStatusExceptionResolver3\. DefaultHadlerExceptionResolver

일반적으로 사용하는 HTML Form을 통한 파일 업로드를 이해하려면 먼저 폼을 전송하는 다음 두 가지 방식의 차이를 이해해야 한다.application/x-www-form-urlencodedmultipart/form-dataapplication/x-www-form-u

애플리케이션 서버와 DB - 일반적인 사용법1\. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결한다.2\. SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다.3\. 결과 응답: DB는 전달된 SQL을 수행

데이터를 저장할 때 단순히 파일에 저장해도 되는데, 데이터베이스에 저장하는 이유는 무엇일까?여러가지 이유가 있지만, 가장 대표적인 이유는 바로 데이터베이스에는 트랜잭션이라는 개념을 지원하기 때문이다.트랜잭션을 이름 그대로 번역하면 거래라는 뜻이다. 이것을 쉽게 풀어서

애플리케이션 구조여러가지 애플리케이션 구조가 있지만, 가장 단순하면서 많이 사용하는 방법은 역할에 따라 3가지 계층으로 나누는 것이다.프레젠테이션 계층UI와 관련된 처리 담당웹 요청과 응답사용자 요청을 검증주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC

트랜잭션 템플릿 덕분에 트랜잭션을 처리하는 반복 코드는 해결할 수 있었다. 하지만 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다.이럴때 스프링 AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다.프록시를 도입하기 전에는 기존처

Object: 예외도 객체이다. 모든 객체의 최상위 부모는 Object이므로 예외의 최상위 부모도 Object이다. Throwable: 최상위 예외이다. 하위에 Exception과 Error가 있다. Error: 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이

스프링에서 test의 application.properties에 datasource에 관한 정보를 입력하지 않으면 자동으로 임베디드 db를 사용한다.@Transactional의 경우 테스트 코드에선 정상 작동하더라도 rollback을 호출한다.

@Transactional 애노테이션이 특정 클래스나 메서드에 하나라도 있으면 트랜잭션 AOP는 프록시를 만들어서 스프링 컨테이너에 등록한다. 그리고 실제 basicService 객체 대신에 프록시인 basicService$$CGLIB를 스프링 빈에 등록한다. 그리고