스프링 부트 핵심 원리와 활용

Java-Ecosystem · 2025-03-31

스프링 핵심 원리 - 고급편

Java-Ecosystem · 2024-11-08

스프링 파일 업로드

HTML Form 전송 방식 차이 application/x-www-form-urlencoded HTML 폼 기본 전송 방식 폼 태그에 enctype 옵션을 주지 않을 시 자동 지정 multipart/form-data 여러 데이터 형식을 함께 보내기 위한 Form 데이터 전송 방식 (HTTP 제공) 파일은 문자가 아닌 바이너리 타입으로 전송 필요 각각의 항목을 구분해 한번에 전송 e.g. 폼 데이터 전송 시 문자와 바이너리를 동시 전송 문자: 이름, 나이… 파일: 첨부파일 폼 태그 -> enctype="multipart/form-data" 서블릿 파일 업로드 HttpServletRequest request.getParameter(...) 요청 파라미터 접근 request.getParts() multipart/form-data 전송 방식에서 각각 나누어진 부분을 받아서 확인 개별 Part 메서드 part.getSubmittedFileName() : 클라이언트가 전달한 파일명 part.getInputStream(): Part의 전송 데이터를 읽기 (Body) part.write(fullPath): Part를 통해 전송된 데이터를 지정 경로에 저장 스프링 파일 업로드 업로드하는 HTML Form의 name에 맞추어 @RequestParam 을 적용하면 됨 @RequestParam String itemName @RequestParam MultipartFile file MultipartFile 인터페이스 제공 메서드 file.getOriginalFilename() : 업로드 파일 명 file.transferTo(...) : 파일 저장 서블릿에 비해 HttpServletRequest를 사용 X 파일 부분만 구분하기도 편리 예시 코드 @Slf4j @Controller @RequestMapping("/spring") public class SpringUploadController { @Value("${file.dir}") private String fileDir; @GetMapping("/upload") public String newFile() { return "upload-form"; } @PostMapping("/upload") public String saveFile(@RequestParam String itemName, @RequestParam MultipartFile file, HttpServletRequest request) throws IOException { log.info("request={}", request); log.info("itemName={}", itemName); log.info("multipartFile={}", file); if (!file.isEmpty()) { String fullPath = fileDir + file.getOriginalFilename(); log.info("파일 저장 fullPath={}", fullPath); file.transferTo(new File(fullPath)); } return "upload-form"; } } 멀티파트 관련 사용 옵션 (application.properties) 실제 파일 저장 경로 지정 file.dir=파일 업로드 경로 e.g. /Users/lucian/study/file/ 해당 경로에 반드시 실제 폴더 만들어두기 지정 파일 경로는 컨트롤러의 멤버 변수에 주입해 사용 가능 //application.properties에서 설정한 파일 경로 주입 @Value("${file.dir}") private String fileDir; 업로드 사이즈 제한 //파일 하나의 최대 사이즈 (기본 1MB) spring.servlet.multipart.max-file-size=1MB //멀티 파트 요청 하나의 여러 파일 전체 합 (기본 10MB) spring.servlet.multipart.max-request-size=10MB 큰 파일 무제한 업로드를 예방하고 업로드 사이즈 제한 가능 사이즈를 넘길 시 예외 발생 (SizeLimitExceededException) 서블릿 컨테이너 멀티파트 관련 처리 옵션 spring.servlet.multipart.enabled (기본 true) false: 멀티파트 처리 안하기 결과 request=org.apache.catalina.connector.RequestFacade@xxx itemName=null parts=[] true: 멀티파트 처리하기 결과 request=org.springframework.web.multipart.support.StandardMultipartHttpServletRequest itemName=Spring parts=[ApplicationPart1, ApplicationPart2] true일 시, 스프링 DispatcherServlet의 MultipartResolver를 실행 MultipartResolver는 멀티파트 요청이 온 경우 HttpServletRequest -> MultipartHttpServletRequest 변환 스프링 기본 멀티파트 리졸버는 StandardMultipartHttpServletRequest 반환 MultipartHttpServletRequest HttpServletRequest의 자식 인터페이스 멀티파트 관련 추가 기능 제공 StandardMultipartHttpServletRequest MultipartHttpServletRequest 인터페이스 구현체 실제 파일 업로드 구현 시 주의사항 고객이 업로드한 파일명과 서버 내부 관리 파일명은 다르게 할 것 서로 다른 고객이 같은 파일 이름을 업로드하면 기존 파일과 충돌 발생 예시 구현 업로드 파일 정보 @Data public class UploadFile { private String uploadFileName; private String storeFileName; public UploadFile(String uploadFileName, String storeFileName) { this.uploadFileName = uploadFileName; this.storeFileName = storeFileName; } } 상품 도메인 객체 @Data public class Item { private Long id; private String itemName; private UploadFile attachFile; private List<UploadFile> imageFiles; } 파일 저장 객체 구현하기 멀티파트 파일을 서버에 저장하는 역할 파일은 보통 로컬 스토리지나 S3에 저장하고 DB에는 해당 경로만 저장 (DB에 파일 자체 저장 X) 예시 구현 @Component public class FileStore { @Value("${file.dir}") private String fileDir; public String getFullPath(String filename) { return fileDir + filename; } public List<UploadFile> storeFiles(List<MultipartFile> multipartFiles) throws IOException { List<UploadFile> storeFileResult = new ArrayList<>(); for (MultipartFile multipartFile : multipartFiles) { if (!multipartFile.isEmpty()) { storeFileResult.add(storeFile(multipartFile)); } } return storeFileResult; } public UploadFile storeFile(MultipartFile multipartFile) throws IOException { if (multipartFile.isEmpty()) { return null; } String originalFilename = multipartFile.getOriginalFilename(); String storeFileName = createStoreFileName(originalFilename); multipartFile.transferTo(new File(getFullPath(storeFileName))); return new UploadFile(originalFilename, storeFileName); } //서버 내부 관리 파일명 생성 (UUID 사용해 충돌 방지) private String createStoreFileName(String originalFilename) { String ext = extractExt(originalFilename); String uuid = UUID.randomUUID().toString(); return uuid + "." + ext; } //확장자 추출 함수 private String extractExt(String originalFilename) { int pos = originalFilename.lastIndexOf("."); return originalFilename.substring(pos + 1); } } 파일 저장 폼 전송 객체 예시 @Data public class ItemForm { private Long itemId; private String itemName; private List<MultipartFile> imageFiles; //이미지 다중 업로드 private MultipartFile attachFile; } 파일 저장 뷰 예시 다중 파일 업로드는 <input> 태그에 multiple="multiple" 옵션 지정 ItemForm의 List<MultipartFile> imageFiles을 통해 여러 이미지 파일 받을 수 있음 <!DOCTYPE HTML> <html xmlns:th="http://www.thymeleaf.org"> <head> <meta charset="utf-8"> </head> <body> <div class="container"> <div class="py-5 text-center"> <h2>상품 등록</h2> </div> <form th:action method="post" enctype="multipart/form-data"> <ul> <li>상품명 <input type="text" name="itemName"></li> <li>첨부파일<input type="file" name="attachFile" ></li> <li>이미지 파일들<input type="file" multiple="multiple" name="imageFiles" ></li> </ul> <input type="submit"/> </form> </div>  </body> </html> 파일 조회 및 다운로드 예시 이미지 조회 UrlResource로 이미지 파일을 읽어서 @ResponseBody로 이미지 바이너리 반환 파일 다운로드 Content-Disposition 헤더에 attachment; filename="업로드 파일명" 주기 파일 다운로드 시에는 고객이 업로드한 파일명으로 다운로드하는게 좋음 (UTF_8 인코딩) UrlResource로 파일을 읽어서 헤더와 바디를 ResponseEntity<Resource> 반환 예시 구현 @Slf4j @Controller @RequiredArgsConstructor public class ItemController { private final ItemRepository itemRepository; private final FileStore fileStore; @GetMapping("/items/new") public String newItem(@ModelAttribute ItemForm form) { return "item-form"; } @PostMapping("/items/new") public String saveItem(@ModelAttribute ItemForm form, RedirectAttributes redirectAttributes) throws IOException { UploadFile attachFile = fileStore.storeFile(form.getAttachFile()); List<UploadFile> storeImageFiles = fileStore.storeFiles(form.getImageFiles()); //데이터베이스에 저장 Item item = new Item(); item.setItemName(form.getItemName()); item.setAttachFile(attachFile); item.setImageFiles(storeImageFiles); itemRepository.save(item); redirectAttributes.addAttribute("itemId", item.getId()); return "redirect:/items/{itemId}"; } @GetMapping("/items/{id}") public String items(@PathVariable Long id, Model model) { Item item = itemRepository.findById(id); model.addAttribute("item", item); return "item-view"; } @ResponseBody @GetMapping("/images/{filename}") public Resource downloadImage(@PathVariable String filename) throws MalformedURLException { return new UrlResource("file:" + fileStore.getFullPath(filename)); } @GetMapping("/attach/{itemId}") public ResponseEntity<Resource> downloadAttach(@PathVariable Long itemId) throws MalformedURLException { Item item = itemRepository.findById(itemId); String storeFileName = item.getAttachFile().getStoreFileName(); String uploadFileName = item.getAttachFile().getUploadFileName(); UrlResource resource = new UrlResource("file:" + fileStore.getFullPath(storeFileName)); log.info("uploadFileName={}", uploadFileName); String encodedUploadFileName = UriUtils.encode(uploadFileName, StandardCharsets.UTF_8); String contentDisposition = "attachment; filename=\"" + encodedUploadFileName + "\""; return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, contentDisposition) .body(resource); } } Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-07-28

스프링 타입 컨버터

스프링 Converter HTTP 요청 데이터는 문자로 처리됨 다만, 파라미터를 원하는 타입으로 지정하면 스프링이 자동으로 타입 변환 개발자는 직접 타입 변환할 필요 없이 원하는 타입으로 편리하게 전달 받아 사용 예시 @RequestParam, @ModelAttribute, @PathVariable … (스프링 MVC 요청 파라미터) @Value 등으로 YML 정보 읽기 XML에 넣은 스프링 빈 정보 변환 뷰 렌더링 시 컨버터 인터페이스 package org.springframework.core.convert.converter; public interface Converter<S, T> { T convert(S source); } 스프링은 확장 가능한 컨버터 인터페이스 지원 org.springframework.core.convert.converter.Converter 개발자는 스프링에 추가적인 타입 변환이 필요하면 인터페이스를 구현해 등록 Converter와 PropertyEditor 과거에는 PropertyEditor로 타입 변환했으나 동시성 문제가 있어서 잘 사용하지 않는다. 지금은 기능 확장 시 Converter를 사용한다. 스프링이 제공하는 다양한 컨버터 Converter: 기본 타입 컨버터 ConverterFactory: 전체 클래스 계층 구조가 필요할 때 GenericConverter: 정교한 구현, 대상 필드의 애노테이션 정보 사용 가능 ConditionalGenericConverter: 특정 조건이 참인 경우에만 실행 스프링은 문자, 숫자, 불린, Enum 등 일반적인 타입에 대한 대부분의 인터페이스 구현체들을 제공한다. ConversionService 스프링은 개별 컨버터를 모아서 묶어두고 편리하게 사용할 수 있도록 제공 스프링 내부에서도 ConversionService를 사용해 타입 변환 e.g @RequestParam RequestParamMethodArgumentResolver에서 ConversionService 사용해 타입 변환 뷰 템플릿도 컨버젼 서비스 적용 가능 (타임 리프 문법: ${{...}}) ConversionService 인터페이스 public interface ConversionService { boolean canConvert(@Nullable Class<?> sourceType, Class<?> targetType); boolean canConvert(@Nullable TypeDescriptor sourceType, TypeDescriptor targetType); <T> T convert(@Nullable Object source, Class<T> targetType); Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType); } canConvert: 컨버팅이 가능한지 체크 convert: 실제 컨버팅 수행 ConversionService는 2가지 이점 제공 등록과 사용 분리 컨버터 등록 입장: 타입 컨버터를 명확히 알아야 함 컨버터 사용 입장: 컨버전 서비스 인터페이스만 의존, 구체적인 타입 컨버터 몰라도 됨 인터페이스 분리 원칙 적용 (ISP) DefaultConversionService 구현체는 두 인터페이스를 구현 ConversionService: 컨버터 사용에 초점 ConverterRegistry: 컨버터 등록에 초점 ConversionService 인터페이스를 사용하는 클라이언트는 꼭 필요한 메서드만 알게 됨 메시지 컨버터와 컨버전 서비스 HttpMessageConverter에는 컨버전 서비스가 적용되지 않는다. 메시지 컨버터는 Jackson 라이브러리를 사용해 HTTP 메시지 바디 내용을 객체로 변환하거나 객체를 HTTP 메시지 바디에 입력한다. 따라서, JSON 결과로 만들어지는 숫자나 날짜 포멧을 변경하고 싶으면, Jackson 라이브러리가 제공하는 설정을 통해 지정해야 한다. (Jackson Data Format 같은 키워드로 검색 필요) 참고로, 컨버전 서비스는 @RequestParam , @ModelAttribute , @PathVariable , 뷰 템플릿 등에서 사용할 수 있다. Formatter 일반적인 웹 애플리케이션 환경에서의 타입 변환 (개발자) 문자 -> 객체 (다른 타입) 객체 (다른 타입) -> 문자 Formatter는 문자에 특화한 Converter의 특별한 버전 Formatter: 문자 특화 + 현지화(Locale) Converter: 범용 (객체 -> 객체) Formatter 인터페이스 public interface Printer<T> { String print(T object, Locale locale); } public interface Parser<T> { T parse(String text, Locale locale) throws ParseException; } public interface Formatter<T> extends Printer<T>, Parser<T> { } String print(T object, Locale locale) : 객체를 문자로 변경 T parse(String text, Locale locale) : 문자를 객체로 변경 스프링 Formatter 스프링은 용도에 따라 다양한 방식의 포멧터를 제공한다. Formatter: 포멧터 AnnotationFormatterFactory: 필드 타입 혹은 애노테이션 정보를 활용할 수 있는 포멧터 FormattingConversionService 포멧터를 지원하는 컨버전 서비스 포멧터도 특별한 컨버터일 뿐 내부에서 어댑터 패턴을 사용해 Formatter가 Converter처럼 동작하도록 지원 컨버터 & 포멧터를 모두 등록 가능 FormattingConversionService 는 ConversionService 관련 기능을 상속 받음 DefaultFormattingConversionService 구현체: 기본적인 통화, 숫자 기본 포멧터를 추가해 제공 커스텀Converter 및 Formatter 등록 @Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addFormatters(FormatterRegistry registry) { //컨버터 추가 registry.addConverter(new StringToIpPortConverter()); registry.addConverter(new IpPortToStringConverter()); //포멧터 추가 registry.addFormatter(new MyNumberFormatter()); } } 등록 방법은 다르지만 컨버전 서비스를 통해 컨버터와 포멧터를 일관성 있게 사용 가능 addFormatters() 오버라이딩 -> 스프링 내부 ConversionService에 컨버터 자동 등록 addConverter(): 컨버터 추가 addFormatter(): 포멧터 추가 우선 순위 스프링 기본 컨버터보다 추가한 컨버터가 높은 우선순위 포멧터보다 컨버터가 높은 우선 순위 스프링 기본 포멧터 스프링은 자바 기본 타입들에 대한 수많은 포멧터를 기본 제공 애노테이션 기반 포멧터도 제공 덕분에 객체에 각 필드마다 다른 형식으로 포멧 지정 가능 종류 @NumberFormat 숫자 관련 형식 지정 NumberFormatAnnotationFormatterFactory @DateTimeFormat 날짜 관련 형식 지정 Jsr310DateTimeFormatAnnotationFormatterFactory 예시 코드 @Controller public class FormatterController { @GetMapping("/formatter/edit") public String formatterForm(Model model) { Form form = new Form(); form.setNumber(10000); form.setLocalDateTime(LocalDateTime.now()); model.addAttribute("form", form); return "formatter-form"; } @PostMapping("/formatter/edit") public String formatterEdit(@ModelAttribute Form form) { return "formatter-view"; } @Data static class Form { @NumberFormat(pattern = "###,###") private Integer number; @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime localDateTime; } } Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-07-27

스프링 예외 처리

Java-Ecosystem · 2024-07-20

스프링 쿠키, 세션 로그인 기본

Java-Ecosystem · 2024-07-10

스프링 Validation

Validation HTTP 요청이 정상인지 검증하는 것은 컨트롤러의 중요한 역할 스프링 제공 방법 Bean Validation (Bean Validation 2.0 (JSR-380)) + BindingResult 검증 로직을 공통화 및 표준화해 객체에 애노테이션으로 검증 적용 객체에 검증 애노테이션 적용 (e.g. @NotNull, @Range…) 파라미터에 @Valid, @Validated 적용하면 검증 실행 기술 표준으로서 검증 애노테이션 및 여러 인터페이스의 모음 구현체는 일반적으로 하이버네이트 Validator를 사용 (ORM과 관련 없음) 스프링 MVC가 Bean Validator를 사용하는 과정 spring-boot-starter-validation를 라이브러리로 등록 스프링 부트가 자동으로 Bean Validator를 인지하고 스프링에 통합 스프링 부트는 LocalValidatorFactoryBean을 글로벌 Validator로 등록 애노테이션을 보고 검증을 수행하는 검증기 (e.g. @NotNull) @Valid, @Validated 적용으로 파라미터 검증 실행 검증 오류 발생 시 FieldError, ObjectError 생성해 BindingResult 담음 검증 순서 타입에 맞춰 각각의 필드 바인딩 시도 실패시 typeMismatch로 FieldError 추가 바인딩에 성공한 필드만 Bean Validation 적용 비즈니스 로직 적용 방법 컨트롤러 용도에 따라 검증 전용 객체 분리하기 (도메인 객체는 순수하게 유지) 장점: 검증 중복이 없고 복잡도 낮음 단점: 컨트롤러에서 전송 받은 데이터를 도메인 객체 생성 및 변환 과정 추가 검증 전용 객체 이름은 일관성만 있게자유로이 명명 ItemSave, ItemSaveForm , ItemSaveRequest ,ItemSaveDto… 동일한 도메인 객체 사용 + Bean Validation의 groups 속성으로 분류 - 권장 X 장점: 중간에 도메인 객체 생성 과정 없이 컨트롤러부터 리포지토리까지 전달 가능 단점: 간단한 경우에만 가능 검증할 기능을 등록 및 수정 등 각각의 그룹으로 나누어 적용 가능 저장용 groups 생성 package hello.itemservice.domain.item; public interface SaveCheck { } 수정용 groups 생성 package hello.itemservice.domain.item; public interface UpdateCheck { } groups 적용 @Data public class Item { @NotNull(groups = UpdateCheck.class) //수정시에만 적용 private Long id; @NotBlank(groups = {SaveCheck.class, UpdateCheck.class}) private String itemName; @NotNull(groups = {SaveCheck.class, UpdateCheck.class}) @Range(min = 1000, max = 1000000, groups = {SaveCheck.class, UpdateCheck.class}) private Integer price; @NotNull(groups = {SaveCheck.class, UpdateCheck.class}) @Max(value = 9999, groups = SaveCheck.class) //등록시에만 적용 private Integer quantity; public Item() { } public Item(String itemName, Integer price, Integer quantity) { this.itemName = itemName; this.price = price; this.quantity = quantity; } } @Validated에 groups 적용 (@Valid는 groups 기능이 없음) @Validated(SaveCheck.class) @Validated(UpdateCheck.class) ObjectError 처리 방법 글로벌 오류는 자바 코드로 직접 작성해 처리 권장 (메서드 추출) public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) { //특정 필드 예외가 아닌 전체 예외 if (item.getPrice() != null && item.getQuantity() != null) { int resultPrice = item.getPrice() * item.getQuantity(); if (resultPrice < 10000) { bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null); } } ... } @ScriptAssert() - 권장 X @ScriptAssert(lang = "javascript", script = "_this.price * _this.quantity >= 10000") public class Item { //... } 생성되는 메시지 코드 ScriptAssert.item ScriptAssert 제약이 많고 복잡하여 권장하지 않음 API 적용 시 고려할 점 (HTTP 메시지 컨버터) @Valid, @Validated -> HttpMessageConverter(@RequestBody)에 적용 가능 public Object addItem(@RequestBody @Validated ItemSaveForm form, BindingResult bindingResult) API는 3가지 경우 고려 필요 성공 요청 실패 요청 HttpMessageConverter 에서 요청 JSON을 객체로 생성하는데 실패 컨트롤러 자체가 호출되지 않고 예외가 발생 검증 적용(Validator) X 검증 오류 요청 JSON 객체 생성은 성공했으나 이후 검증 실패 HttpMessageConverter 는 성공하지만 검증(Validator)에서 오류가 발생 필요한 의존관계 패키지 implementation 'org.springframework.boot:spring-boot-starter-validation jakarta.validation-api: Bean Validation 인터페이스 hibernate-validator: 구현체 검증 애노테이션 @NotBlank: null 과 "" 과 " " 모두 허용하지 않음 @NotEmpty: null 과 ""을 허용하지 않음 @NotNull: null을 허용하지 않음 @Range(min = 1000, max = 1000000): 범위 안의 값만 허용 @Max(9999): 최대 지정 값까지만 허용 테스트에서 Bean Validation 사용하기 ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Set<ConstraintViolation<Item>> violations = validator.validate(item); Bean Validation 오류 코드 Bean Validation이 오류 메시지를 찾는 순서 MessageResolver 생성 메시지 코드대로 messageSource 찾기 (errors.properties) 애노테이션의 message 속성 사용 @NotBlank(message = "공백! {0}") 라이브러리가 제공하는 기본 값 사용 기본은 애노테이션 이름으로 오류코드를 등록 e.g. @NotBlank NotBlank.item.itemName NotBlank.itemName NotBlank.java.lang.String NotBlank 생성이 예상되는 적절한 오류 코드로 errors.properties에 원하는 메시지 등록 가능 BindingResult 스프링이 제공하는 검증 오류를 보관하는 객체 (Model에 자동 포함) 실제로는 인터페이스이고 Errors 인터페이스를 상속받고 있음 실제 넘어오는 구현체는 BeanPropertyBindingResult 타입으로 Errors를 사용해도 되지만 BindingResult는 더 추가적인 기능 제공 관례상으로도 Errors보다 BindingResult 많이 사용 반드시 @ModelAttribute 파라미터의 바로 뒤에 위치해야 함 e.g. @ModelAttribute Item item, BindingResult bindingResult 타임리프가 통합 기능도 제공 (#fields, th:errors, th:errorclass) 검증 오류 적용 방법 스프링 자동 적용 @ModelAttribute에 데이터 바인딩 오류가 발생 시 자동 처리 e.g. 주로 타입 오류 BindingResult가 없으면 컨트롤러 호출 X, 400 오류 페이지 이동 BindingResult가 있으면 스프링이 new FieldError() 실행 생성한 필드 에러 객체를 BindingResult에 자동으로 담음 이후 컨트롤러 정상 호출 개발자가 직접 넣기 rejectValue(), reject()를 호출하는 방법 target(검증 대상 모델)을 BindingResult가 이미 앎 (깔끔한 코드) 내부에서 MessageCodesResolver를 사용 FieldError, ObjectError 생성 후 오류 코드들을 보관 즉, MessageCodesResolver가 생성한 오류들을 가지고 처리 필드 에러 처리 (rejectValue()) bindingResult.rejectValue("quantity", "max", new Object[]{9999}, null); rejectValue() 파라미터 field: 오류 필드명 errorCode messageCodesResolver를 위한 오류 코드 필드명, 오브젝트명, 오류코드를 조합한 키로 메시지 가져옴 errorArgs: 메시지에서 사용하는 인자 defaultMessage: 오류 메시지 찾을 수 없을 때 기본 메시지 글로벌 에러 처리 (reject()) bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null); reject() 파라미터 errorCode errorArgs defaultMessage 참고 ValidationUtils: Empty, 공백 등의 조건까지 한 줄로 처리 가능 ValidationUtils.rejectIfEmptyOrWhitespace(bindingResult, "itemName", "required"); FieldError, ObjectError 직접 생성을 통한 방법 (addError()) 필드 에러 처리 (FieldError) FieldError 객체를 생성해 bindingResult에 담음 FieldError는 ObjectError의 자식 bindingResult.addError(new FieldError("item", "itemName", "상품 이름은 필수입니다.")); FieldError 파라미터 (생성자 2개) objectName: @ModelAttribute 이름 field: 오류가 발생한 필드 이름 rejectedValue: 사용자가 입력한 값 (거절된 값) bindingFailure: 바인딩 실패인지, 검증 실패인지 구분 값 codes: 메시지 코드 지정 (errors.properties) 배열로 여러 값을 전달 가능 순서대로 매칭해 처음 매칭되는 메시지 사용 (없으면 예외 발생) e.g. new String[] {"max.item.quantity"} arguments: 메시지에서 사용하는 인자 {0}, {1}… 순서대로 치환 값 전달 e.g. new Object[] {9999} defaultMessage: 오류 기본 메시지 글로벌 에러 처리 (ObjectError - 특정 필드를 넘어서는 오류) ObjectError 객체를 생성해 bindingResult에 담음 bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice)); ObjectError 파라미터 (생성자 2개) objectName: @ModelAttribute 이름 codes: 메시지 코드 arguments: 메시지에서 사용하는 인자 defaultMessage: 오류 기본 메시지 Validator 사용하기 스프링이 제공하는 Validator 인터페이스를 상속해 검증 로직을 담기 가능 컨트롤러에서 검증 로직을 분리하고 재사용할 수 있음 구현할 메서드 supports 해당 검증기 지원 여부 확인 @Override public boolean supports(Class<?> clazz) { return Item.class.isAssignableFrom(clazz); } validate(Object target, Errors errors) 검증 대상 객체와 BindingResult 전달 적용 방법 WebDataBinder 에 검증기 추가 + @Validated 파라미터 적용 @InitBinder public void init(WebDataBinder dataBinder) { log.info("init binder {}", dataBinder); dataBinder.addValidators(itemValidator); } WebDataBinder (컨트롤러에 추가) 스프링 파라미터 바인딩 역할 및 검증 기능 수행 해당 컨트롤러가 호출될 때마다 검증기 적용 즉, 요청이 올 때마다 새로 생성해 검증 글로벌 설정도 가능하지만 사용할 일 거의 없음 (권장 X) @SpringBootApplication public class ItemServiceApplication implements WebMvcConfigurer { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Override public Validator getValidator() { return new ItemValidator(); } } 글로벌 설정 시 BeanValidator가 자동 등록되지 않음 @Validated 검증 실행을 원하는 파라미터에 적용 supports를 통해 등록된 검증기들 중 실행해야 할 것을 구분 검증기 직접 호출도 가능하지만 불편 개발자 직접 처리 중복 처리가 많아짐 타입 오류 처리가 안됨 Integer 타입 파라미터에 문자가 들어오면 오류 스프링 MVC에서 컨트롤러 호출되기 전부터 400 예외 발생 특히, 타입 오류의 경우 검증 전 고객의 입력 데이터를 보존하지 못함 (UX에 중요한 부분) 클라이언트 검증 & 서버 검증 클라이언트 검증만 사용하면 조작이 가능해 보안에 취약하고, 서버 검증만 있다면 즉각적인 고객 사용성이 부족해진다. 따라서, 클라이언트 검증과 서버 검증은 둘 다 적절히 섞어 사용하되, 최종적으로 서버 검증을 필수로 진행한다. @Validated와 @Valid 검증 시 @Validated, @Valid 둘 다 사용 가능하다. @Validated 는 스프링 전용 검증 애노테이션이고, @Valid 는 자바 표준 검증 애노테이션이다. 다만, @Valid는 다음 의존관계 추가가 필요하다. `implementation ‘org.springframework.boot:spring-boot-starter-validation’ javax.validation VS org.hibernate.validator javax.validation으로 시작하면 표준 인터페이스, org.hibernate.validator로 시작하면 하이버네이트 validator 구현체를 사용할 때만 제공되는 검증이다. 다만, 실무에서 대부분 하이버네이트 validator를 사용하므로 자유롭게 사용해도 된다. BeanValidation - @ModelAttribute VS @RequestBody @ModelAttribute 는 필드 단위로 정교하게 바인딩이 적용된다. 특정 필드가 바인딩 되지 않아도(타입이 맞지 않는 오류) 나머지 필드는 정상 바인딩 되고, Validator를 사용한 검증도 적용할 수 있다. @RequestBody 는 객체 단위로 바인딩이 적용된다. HttpMessageConverter 단계에서 JSON 데이터를 객체로 변경하지 못하면 이후 단계 자체가 진행되지 않고 예외가 발생한다. 컨트롤러도 호출되지 않고, Validator도 적용할 수 없다. MessageCodesResolver 검증 오류 코드로 메시지 코드 후보들을 생성 MessageCodesResolver는 인터페이스이고 DefaultMessageCodesResolver가 기본 구현체 보통 이렇게 생성된 메시지 코드를 기반으로 MessageSource에서 메시지를 찾음 기본 메시지 코드 생성 규칙 객체 오류 규칙 code + “.” + object name code e.g. 오류 코드: required, object name: item required.item required 필드 오류 규칙 code + “.” + object name + “.” + field code + “.” + field code + “.” + field type code 예) 오류 코드: typeMismatch, object name: "user", field: "age", field type: int typeMismatch.user.age typeMismatch.age typeMismatch.int typeMismatch 메시지 처리 전략 예시 (errors.properties) #==ObjectError== #Level1 totalPriceMin.item=상품의 가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1} #Level2 totalPriceMin=전체 가격은 {0}원 이상이어야 합니다. 현재 값 = {1} #==FieldError== #Level1 required.item.itemName=상품 이름은 필수입니다. range.item.price=가격은 {0} ~ {1} 까지 허용합니다. max.item.quantity=수량은 최대 {0} 까지 허용합니다. #Level2 - 생략 #Level3 required.java.lang.String = 필수 문자입니다. required.java.lang.Integer = 필수 숫자입니다. min.java.lang.String = {0} 이상의 문자를 입력해주세요. min.java.lang.Integer = {0} 이상의 숫자를 입력해주세요. range.java.lang.String = {0} ~ {1} 까지의 문자를 입력해주세요. range.java.lang.Integer = {0} ~ {1} 까지의 숫자를 입력해주세요. max.java.lang.String = {0} 까지의 문자를 허용합니다. max.java.lang.Integer = {0} 까지의 숫자를 허용합니다. #Level4 required = 필수 값 입니다. min= {0} 이상이어야 합니다. range= {0} ~ {1} 범위를 허용합니다. max= {0} 까지 허용합니다. 메시지 처리 기본 범용 메시지를 두고, 세밀하게 작성해야 하는 경우에 세밀한 메시지를 적용하도록 메시지 단계를 두자 세밀한 메시지가 범용 메시지보다 우선순위 가진다. 예를 들어, required라는 메시지만 있으면 해당 메시지를 기본으로 사용하고, required.item.itemName 같이 세밀한 메시지 코드가 있으면 이 메시지를 높은 우선순위로 사용한다. MessageCodesResolver는 메시지 관련 공통 전략을 편리하게 적용할 수 있게 지원한다. 스프링 타입 오류 스프링은 타입 오류가 발생하면 typeMismatch라는 오류 코드를 자동으로 사용한다. 이 경우 MessageCodesResolver를 통해 4가지 메시지 코드가 발생할텐데, errors.properties에 해당 코드가 없다면 스프링이 생성한 기본 메시지가 출력된다. Failed to convert property value of type java.lang.String to required type java.lang.Integer for property price; nested exception is java.lang.NumberFormatException: For input string: "A" 기본 출력을 임의로 바꾸고 싶다면, errors.properties에 다음과 같은 코드를 적절하게 추가하면 된다. typeMismatch.java.lang.Integer=숫자를 입력해주세요. typeMismatch=타입 오류입니다. Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 @NotNull, @NotEmpty, @NotBlank 의 차이점 및 사용법

Java-Ecosystem · 2024-06-30

스프링 MVC 메시지와 국제화

메시지 다양한 메시지를 한 곳에서 관리하도록 하는 기능 스프링 부트는 messages.properties를 기본 메시지 파일로 인식하고 관리 경로: /resources/messages.properties 국제화 메시지 파일을 각 나라 언어별로 별도 관리해 서비스를 국제화 베이스파일명_언어 형식으로 메시지 파일을 만들어두면 자동으로 인식 e.g. messages_en.properties, messages_ok.properties 기본은 HTTP accept-language 헤더 값을 보고 판단 스프링 부트 기본 LocaleResolver: AcceptHeaderLocaleResolver 혹은 사용자가 직접 언어를 선택하도록 하고, 쿠키나 세션 기반 처리도 가능 LocaleResolver 인터페이스의 구현체 변경 public interface LocaleResolver { Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale); } 찾을 수 있는 국제화 파일이 없는 경우, 언어정보 없는 디폴트 파일 기본 사용 (messages.properties) MessageSource 인터페이스 public interface MessageSource { String getMessage(String code, @Nullable Object[] args, @Nullable String defaultMessage, Locale locale); String getMessage(String code, @Nullable Object[] args, Locale locale) throws NoSuchMessageException; 스프링은 메시지 관리 기능을 MessageSource 인터페이스를 통해 제공 getMessage: 파라미터만 다르고 메시지를 읽어오는 기능 수행 메시지가 없는 경우 NoSuchMessageException 발생 code: 메시지 파일에서 지정한 키 args: 매개변수를 전달하는 배열 메시지 파일의 {0} 부분 치환 hello.name=안녕 {0} Object[] 배열로 넘겨야 함 ms.getMessage("hello.name", new Object[]{"Spring"}, null); defaultMessage: 메시지가 없을 때 기본 메시지 지정 (예외 발생 예방) locale: 국제화 파일 선택 e.g. Locale.KOREA, Locale.ENGLISH 정보가 없을 시 (null) Locale.getDefault() 호출해, 시스템 기본 로케일 사용 시스템 기본 로케일 조회 실패 시 기본 이름 메시지 파일 조회 (message.properties) Locale이 en_US인 경우 messages_en_US / messages_en / messages 순서로 찾음 스프링 부트는 자동으로 ResourceBundleMessageSource 구현체를 스프링 빈으로 등록 메시지 파일 임의 지정 방법 (application.properties) e.g. spring.messages.basename=messages,config.i18n.messages 기본값: spring.messages.basename=messages 직접 등록 방법 @Bean public MessageSource messageSource() { ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource(); messageSource.setBasenames("messages", "errors"); messageSource.setDefaultEncoding("utf-8"); return messageSource; basenames: 설정 파일 이름 지정 여러 파일을 한 번에 지정 가능 (messages, errors) messages.properties, errors.properties 파일을 읽음 defaultEncoding: 인코딩 정보 지정 (utf-8 사용하면 됨) Reference 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

Java-Ecosystem · 2024-06-21

스프링 데이터 접근 활용 기술

Java-Ecosystem · 2024-06-16

스프링 데이터 접근 핵심 원리

Java-Ecosystem · 2024-05-12

스프링 MVC 원리

Web Server & Web Application Server Web Server (HTTP) 정적 리소스 제공 + 기타 부가기능 동적인 처리(애플리케이션 로직 등)가 필요하면 WAS에 요청 위임 예시) NGINX, APACHE Web Application Server (HTTP) 애플리케이션 로직 수행 (프로그램 코드 실행) + 웹 서버 기능 (정적 리소스 제공) 동적 HTML, HTTP API(JSON), 서블릿, JSP, Spring MVC API 서버만 제공할 경우 WAS만으로 서버 구축해도 괜찮음 (회사끼리 데이터 주고 받을 때) 예시) Tomcat, Jetty, Undertow WAS는 애플리케이션 코드 실행에 더 특화되어 있다! 웹서버와 WAS는 서로가 서로의 기능을 가지고 있긴 해서 경계가 모호 서블릿 컨테이너 기능 제공하면 WAS라 보기도 함 (서블릿 사용안하는 프레임워크도 있지만…) 공존 이유 효율적인 리소스 관리 WAS가 너무 많은 역할을 담당하여 서버 과부하 우려 애플리케이션 로직은 값어치가 높으므로 값이 낮은 정적 리소스 때문에 과부하되면 안됨 역할 분리 정적 리소스 사용이 많을 때는 Web Server 증설 애플리케이션 리소스 사용이 많을 때는 WAS 증설 지속적인 오류 화면 제공 WAS는 잘 죽는 반면, Web Server는 잘 안 죽음 WAS 및 DB 장애시 Web Server가 오류화면 제공 가능 Servlet 메시지 수신, 파싱, 응답 메시지 생성 및 송신 등 HTTP 스펙의편리한 사용을 지원하는 자바 클래스 서블릿을 지원하는 WAS를 사용하면, 의미있는 비즈니스 로직에만 집중 가능 사용 방법 메인 함수가 실행되는 클래스에 @ServletComponentScan 추가 HttpServlet을 상속받고 @WebServlet 애노테이션에 name과 urlPatterns를 지정 protected의 service 코드를 오버라이딩해 비즈니스 로직 작성 HttpServletRequest와 HttpServletResponse 타입 파라미터로 요청 및 응답 정보 사용 가능 부가 기능 임시 저장소 기능: HTTP 요청의 시작과 끝까지 유지, View에 데이터 전달하는 Model 역할도 수행 세션 관리 기능: request.getSession(create: true) 흐름 HTTP 요청시 WAS가 Request, Response 객체를 생성해서 서블릿 객체 호출 서비스 로직에서 Request 객체의 HTTP 요청 정보를 이용하고 Response 객체에 응답 정보 입력 WAS는 Response 객체에 담긴 내용으로 HTTP 응답 정보 생성 Servlet Container(서블릿 컨테이너) 서블릿을 지원하는 WAS (톰캣) 서블릿 객체의 생명주기 관리 (생성, 초기화, 호출, 종료) 서블릿 객체를 싱글톤으로 관리 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 공유 변수 사용에는 주의해야 함 동시 요청을 위한 멀티 쓰레드 처리 지원 덕분에 개발자가 멀티 쓰레드를 신경쓰지 않고 마치 싱글 쓰레드 프로그래밍 하듯이 편리하게 개발 (WAS가 개발 생산성을 가장 높여주는 부분) 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용 (공유변수, 멤버변수 조심) 동시요청 (멀티 쓰레드) 쓰레드 애플리케이션 코드를 하나하나 순차적으로 실행하는 것 (한번에 하나의 코드 라인만 수행) 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행 동시 처리가 필요하면 쓰레드를 추가로 생성 서블릿 객체는 쓰레드가 호출 멀티 쓰레드는 동시요청 처리 가능 (단일 쓰레드로는 처리가 어려움) 요청마다 쓰레드 생성 장점 동시 요청 처리 가능 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작 단점 쓰레드 생성 비용은 매우 비쌈 (요청마다 쓰레드 생성하면 응답 속도도 늦어짐) 컨텍스트 스위칭 비용 발생 (하나의 CPU 코어에 2개 이상의 쓰레드를 돌리면 발생) 쓰레드 생성에 제한 없음 (요청이 너무 많으면, CPU와 메모리 임계점을 넘어 서버가 죽음) 쓰레드 풀 설정한 최대치 만큼 쓰레드를 미리 생성해 풀에 보관하고 관리 (톰캣 기본설정: 최대 200개) 요청이 들어오면 쓰레드 풀에서 쓰레드를 할당하고 다 쓰면 반납 (재사용) 풀에 남은 쓰레드가 부족하면 대기 중인 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정 가능 장점 쓰레드를 미리 생성하므로, 쓰레드 생성 비용(CPU)이 절약되고 응답이 빠름 쓰레드 풀 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리 가능 WAS의 주요 튜닝 포인트는 최대 쓰레드 수(max thread) 동시 요청이 많은 상황에서 너무 낮게 설정 시: 서버 리소스는 여유롭지만, 금방 클라이언트 응답 지연이 발생 100개 요청이 왔는데 최대 쓰레드가 10개면 동시에 10개 요청만 처리 그런데 사실 CPU는 5% 밖에 사용안함 너무 높게 설정 시: CPU, 메모리 임계점 초과로 서버 다운 발생 10000개의 요청이 오면 10000개를 모두 받아들이다가 서버가 죽음 장애 발생시 클라우드면 일단 서버부터 늘리고 이후 튜닝 클라우드가 아니면 바로 튜닝 적정 쓰레드 풀 숫자는 성능 테스트를 통해 찾아야 함 애플리케이션 로직 복잡도, CPU & 메모리 & IO 리소스 상황에 따라 모두 다름 최대한 실제 서비스와 유사하게 성능 테스트 시도 아파치 ab, 제이미터, nGrinder 백엔드가 고려할 3가지 HTTP 통신 정적 리소스 어떻게 제공할지 동적 HTML 페이지 어떻게 제공할지 (View Template) API 어떻게 제공할지 (JSON) MVC 패턴 배경 비즈니스 로직과 뷰는 변경의 라이프 사이클이 다르므로, 분리하는 것이 좋은 설계 역할을 나누면 유지보수성이 향상되고 각각의 기능을 특화할 수 있음 컨트롤러 (Controller) HTTP 요청을 받아서 파라미터를 검증하고 비즈니스 로직 및 오케스트레이션 작업 실행 오케스트레이션: 데이터 접근 및 모델 담기 등의 작업 지금은 더 고도화 되어서 다음 두 가지 패턴을 띔 서비스 계층: 비즈니스 로직 + 오케스트레이션 서비스 계층: 오케스트레이션 / 도메인 모델: 비즈니스 로직 모델 (Model) 뷰에 출력할 데이터를 담아둠 뷰 (View) 화면을 렌더링하는 일에 집중 HTML 생성에 더하여 XML, Excel, JSON 생성 등도 포괄 SSR & CSR 서버 사이드 렌더링 (SSR) HTML 최종 결과를 서버에서 만들어서 웹브라우저에 전달 JSP, Thymeleaf (백엔드 기술) 클라이언트 사이드 렌더링 (CSR) HTML 최종 결과를 JS를 이용해 웹 브라우저에서 동적으로 생성해 적용 필요한 부분만 부분부분 변경 React, Vue.js (프론트엔드 기술) CSR + SSR 동시 지원하는 프론트 기술도 존재하므로 칼같이 나눌 필요 X (Next.js) SSR도 JS 이용해 화면 일부를 동적으로 변경 가능 자바 웹기술 역사 Servlet(1997) HTML 생성이 어려움 (동적 HTML을 생성할 수 있으나 자바코드로 일일히 HTML 만들어야 해서 불편) JSP(1999) HTML 생성이 편리해 JSP로 모두 개발 비즈니스 로직과 뷰 로직이 결합되어 코드라인이 너무 많아지고 유지보수 저하 Servlet + JSP MVC 패턴 모델, 뷰, 컨트롤러로 역할을 나눠 비즈니스 로직과 화면 렌더링 부분을 나눔 한계점: 공통 기능 처리가 어려움 dispatcher.forward() 같은 View로 이동하는 코드 중복 /WEB-INF/views 와 .jsp 같은 ViewPath 중복 (JSP 의존성도 증가) HttpServletResponse response는 파라미터로 항상 존재하지만 사용 X 공통 기능을 메서드로 뽑는 방안도 여전히 호출 중복이 존재하며 호출을 강제하지는 못함 프론트 컨트롤러 패턴의 등장 배경 MVC 프레임워크 춘추 전국 시대 (2000년 초 ~ 2010년 초) 반복되는 MVC 패턴을 자동화하기 위해 여러 프레임워크 등장 스트럿츠, 웹워크, 스프링 MVC(과거 버전) 당시에는 스트럿츠 + 스프링 코어(MVC 제외한 service, DAO, repository) 형태를 주로 사용 FrontController 패턴 적용 프론트 컨트롤러 서블릿 하나로 클라이언트 요청을 받음 (나머지 컨트롤러는 서블릿 사용 X) 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아 호출 공통 처리 담당 스프링 MVC 핵심도 프론트 컨트롤러 패턴 애노테이션 기반의 스프링 MVC MVC 프레임워크 혼돈 시대 정리 @RequestMapping 기반의 애노테이션 컨트롤러 등장으로, 스프링은 MVC 부분에서도 완승 스프링 부트 (Spring Boot) 빌드 결과(Jar)에 WAS 서버(Tomcat)를 포함하여 빌드 배포를 단순화 빌드된 Jar 파일을 아무 서버에 넣고 말아서 실행하면 됨 과거에는 서버에 WAS(Tomcat)를 직접 설치하고 Jar 파일을 모아 War 파일을 만들어서 배포를 위한 특정 폴더에 집어 넣어 배포해야 했음 최신 기술 - 스프링 웹 기술의 분화 Web Servlet - Spring MVC 서블릿 위에 Spring MVC를 올려서 동작 Web Reactive - Spring WebFlux 비동기 Non-Blocking 처리 최소 쓰레드로 최대 성능 (컨텍스트 스위칭 비용 효율화) CPU 코어가 4개 있으면 쓰레드 개수를 4 혹은 +1(5개) 정도로 맞춤 고효율로 CPU 개수에 딱 맞췄기 때문에 쓰레드가 계속 돌아가고 컨텍스트 스위칭 비용이 거의 안듦 함수형 스타일로 개발 - 동시처리 코드 효율화 WAS에서 상품 조회, 주문 서버 조회 등 여러 개의 서버에 여러 개 API를 동시에 찔러서 데이터를 가져와 조합해야 할 때 매우 효율적 Java 코드는 깔끔하지 않지만 함수형 스타일 코드는 매우 깔끔 (Netty) 서블릿 사용 X 단점 기술적 난이도 매우 높음 RDB 지원 부족 NoSQL(Redis, Elastic Search, DynamoDB, MongoDB)은 지원 잘 됨 일반 MVC 쓰레드 모델도 충분히 빠름 좋은 장비 띄워서 쓰레드 1000개 넣고 돌려도 잘 돌아감 실무에서 아직 많이 사용 X 자바 뷰 템플릿 역사 JSP 느린 속도, 부족한 기능 Freemarker, Velocity 빠른 속도 (Thymeleaf 보다 빠름) Thymeleaf (권장) 네추럴 템플릿 HTML 태그 속성을 이용하므로 HTML의 모양을 유지하면서 뷰 템플릿 적용 가능 스프링 MVC와 강한 기능 통합 스프링 MVC 핵심 구조와 원리 구조 DispatcherServlet 프론트 컨트롤러 (스프링 MVC의 핵심) 부모 클래스로부터 HttpServlet을 상속 받아, 서블릿으로서 동작 스프링 부트는 DispatcherServlet을 서블릿으로 자동 등록하면서, 모든 경로(urlPatterns="/")에 대해서 매핑 흐름 서블릿이 호출되면 DispatcherServlet의 부모인 FrameworkServlet에서 오버라이드한 HttpServlet에서 제공하는 service() 메서드가 호출됨 이후 여러 메서드가 호출되다가 DispatcherServlet.doDispatch()를 호출 HandlerMapping 요청 URL과 핸들러(컨트롤러)의 매핑 핸들러 (Handler) 컨트롤러를 포괄 꼭 컨트롤러 개념이 아니더라도 어떠한 것이든 어댑터가 지원하면 처리 가능 HandlerAdapter (in 핸들러 어댑터 목록) 다양한 버전의 규격이 다른 핸들러들을 호환 가능하게 도움 프레임워크를 유연하고 확장성 있게 설계 가능 어댑터 패턴 덕분에 프론트 컨트롤러가 다양한 방식의 컨트롤러를 처리 가능 핵심 메서드 boolean supports(Object handler) 어댑터가 해당 컨트롤러를 처리할 수 있는지 판단 ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) 실제 컨트롤러를 호출하고 ModelAndView 반환 컨트롤러가 ModelAndView를 반환하지 못하면, 어댑터가 직접 생성해서라도 반환 ModelAndView 논리 뷰 이름을 가짐 뷰 렌더링에 필요한 모델 객체 포함 ViewResolver (물리 뷰 경로 반환기) 논리 뷰 이름을 실제 물리 뷰 경로로 변경 e.g. return new View("/WEB-INF/views/" + viewName + ".jsp"); View 물리 뷰 경로를 가짐 모델 정보와 함께 render() 메서드를 호출 (해당 물리명 주소로 servlet의 forward 함수 호출) 동작 순서 핸들러 조회: 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회 자동 등록된 HandlerMapping들을 순서대로 실행해 핸들러 탐색 스프링 부트가 자동 등록하는 핸들러 매핑 종류 (우선순위 내림차순) RequestMappingHandlerMapping: 애노테이션 기반 컨트롤러에 사용 (@RequestMapping) BeanNameUrlHandlerMapping: 스프링 빈의 이름으로 핸들러 탐색 (@Component("...")) 핸들러 어댑터 조회: 핸들러를 실행할 수 있는 핸들러 어댑터 조회 자동 등록된 HandlerAdapter들의 supports()를 순서대로 호출 스프링 부트가 자동 등록하는 핸들러 어댑터 종류 (우선순위 내림차순) RequestMappingHandlerAdapter: 애노테이션 기반 컨트롤러에 사용 (@RequestMapping) HttpRequestHandlerAdapter: HttpRequestHandler 인터페이스 처리 (서블릿 유사) SimpleControllerHandlerAdapter: Controller 인터페이스 처리 (과거) 핸들러 어댑터 실행 핸들러 실행: 핸들러 어댑터가 실제 핸들러 실행 ModelAndView 반환: 핸들러 어댑터는 핸들러의 반환 결과를 ModelAndView로 변환해 반환 @ResponseBody, HttpEntity(ResponseEntity) 있는 경우 ViewResolver 호출하지 않고 이대로 종료 ViewResolver 호출: 뷰 리졸버를 찾고 실행 주어진 논리 뷰 이름으로 자동 등록된 viewResolver들을 순서대로 호출 스프링 부트가 자동 등록하는 뷰 리졸버 BeanNameViewResolver: 빈 이름으로 뷰를 찾아서 반환 (엑셀 파일 생성에 사용) InternalResourceViewResolver: JSP를 처리할 수 있는 뷰를 반환 application.properties 파일에 prefix와 suffix 등록 (권장) spring.mvc.view.prefix=/WEB-INF/views/ spring.mvc.view.suffix=.jsp View 반환: 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 뷰 객체 반환 JSP의 경우 InternalResourceView(JstlView)를 반환 (내부에 forward() 로직 존재) 다른 뷰 템플릿들은 forward() 과정 없이 바로 렌더링 뷰 렌더링: 뷰 객체의 render() 메서드 호출 스프링 MVC 기본 기능 Controller 관련 기능 컨트롤러 애노테이션 @Controller 스프링이 자동으로 컨트롤러로 인식해 스프링 빈으로 등록 반환 값이 String이면 뷰 이름으로 인식하여, 뷰를 찾고 렌더링 @RestController 스프링이 자동으로 컨트롤러로 인식해 스프링 빈으로 등록 반환 값으로 HTTP 메시지 바디에 바로 입력 (@Controller + @ResponseBody) @RequestMapping 요청 정보 URL 매핑 대부분의 속성을 배열로 제공하므로 다중 설정 가능 {"/hello-basic", "/hello-go"} HTTP 메서드를 설정하지 않으면 메서드 모두 허용 설정하려면 아래와 같이 적용해야 해서 불편함 @RequestMapping(value = "/", method = RequestMethod.GET) HTTP 메서드 축약 애노테이션 제공 @GetMapping/@PostMapping/@PutMapping/@PatchMapping/@DeleteMapping @RequestMapping 내포 클래스 레벨 + 메서드 레벨 조합 적용 (효율적 URL 매핑 적용) @Controller @RequestMapping("/springmvc/members") public class SpringMemberController { @GetMapping("/new-form") // @RequestMapping도 가능 public ModelAndView newForm() { ... } @PostMapping("/save") // @RequestMapping도 가능 public ModelAndView save() { ... } @GetMapping // @RequestMapping도 가능 public ModelAndView members() { ... } } 경로 변수 조회 기본 사용법 @PathVariable("userId") String userId 경로변수 이름과 변수명이 같으면 생략 가능 @PathVariable String userId HTTP 헤더 조회 모든 헤더 조회 @RequestHeader MultiValueMap<String, String> headerMap 하나의 키에 여러 값을 받는 HTTP header, 쿼리 파라미터를 처리 가능 특정 헤더 조회 @RequestHeader("host") String host 속성: required (필수 값 여부), defaultValue (기본값) 특정 쿠키 조회 @CookieValue(value = "myCookie", required = false) 속성: required (필수 값 여부), defaultValue (기본값) 서블릿 조회 HttpServletRequest request HttpServletResponse response 특수 조회 Locale locale HttpMethod httpMethod … HTTP 요청 파라미터 조회 (GET 쿼리 파라미터, POST HTML Form) @RequestParam("요청 파라미터 이름") request.getParameter("파라미터 이름")와 유사 요청 파라미터와 변수명이 같으면 생략 가능 Primitive 타입이면 @RequestParam도 생략가능 required=false 자동 적용 완전 생략은 과한 측면도 있으니 유의 속성: required (필수 값 여부), defaultValue (기본값) Map으로 조회하기 @RequestParam Map<String, Object> paramMap @RequestParam MultiValueMap<String, Object> paramMap 파라미터의 값이 1개가 확실하다면 Map을 사용하지만, 아니라면 MultiValueMap을 사용 서블릿 조회 HttpServletRequest의 request.getParameter() HTTP 요청 메시지 바디 조회 @RequestBody HttpMessageConverter 사용 (요청이 content-type: application/json일 때) 헤더 정보가 필요할 땐, HttpEntity 혹은 @RequestHeader 사용할 것 생략 불가능 단순 Text (StringHttpMessageConverter) @RequestBody String messageBody JSON (MappingJackson2HttpMessageConverter) @RequestBody HelloData data 직접 만든 객체 지정 HttpEntity 조회 HttpMessageConverter 사용 (요청이 content-type: application/json일 때) 단순 Text (StringHttpMessageConverter) HttpEntity<String> httpEntity String messageBody = httpEntity.getBody(); JSON (MappingJackson2HttpMessageConverter) HttpEntity<HelloData> httpEntity RequestEntity HttpEntity를 상속 받음 HttpMethod, URL 정보 추가 가능 서블릿 조회 단순 Text HttpServletRequest request ServletInputStream inputStream = request.getInputStream(); String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); InputStream inputStream String messageBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8); JSON 단순 Text와 유사하나 다음 코드가 추가됨 private ObjectMapper objectMapper = new ObjectMapper(); Jackson 라이브러리 ObjectMapper를 사용 (JSON to 자바 객체) MappingJackson2HttpMessageConverter가 하는 작업을 수동으로 진행 HelloData data = objectMapper.readValue(messageBody, HelloData.class); 조건 매핑 파라미터 특정 파라미터 조건 매핑 (params) @GetMapping(value = "/mapping-param", params = "mode=debug") 특정 요청 파라미터 포함한 요청만 받음 http://localhost:8080/mapping-param?mode=debug 특정 헤더 조건 매핑 (headers) @GetMapping(value = "/mapping-header", headers = "mode=debug") 미디어 타입 조건 매핑 HTTP 요청 헤더 Content-Type (consume) @PostMapping(value = "/mapping-consume", consumes = "application/json") 만약 맞지 않으면 상태코드 415 Unsupported Media Type 반환 사용 예시 consumes = "text/plain" consumes = {"text/plain", "application/*"} consumes = MediaType.TEXT_PLAIN_VALUE HTTP 요청 헤더 Accept (produce) @PostMapping(value = "/mapping-produce", produces = "text/html") 만약 맞지 않으면 상태코드 406 Not Acceptable 반환 사용예시 produces = "text/plain" produces = {"text/plain", "application/*"} produces = MediaType.TEXT_PLAIN_VALUE produces = "text/plain;charset=UTF-8" required & defaultValue 속성 required 속성 required의 기본값은 true 주의사항 파라미터 이름만 사용하는 요청의 경우 @RequestParam(required = true) String username 요청: /request-param-required?username= -> 빈 문자열로 통과 요청: /request-param-required -> 400 예외 발생 Primitive 타입에 null 입력하는 경우 @RequestParam(required = false) int age 요청: /request-param -> 500 예외 발생 (null을 int에 입력 불가능) 해결 방법 @RequestParam(required = false) Integer age 요청: /request-param -> null 입력 통과 @RequestParam(required = false, defaultValue = "-1") int age 요청: /request-param -> 기본값이 있으므로 required가 무의미 defaultValue 속성 파라미터에 값이 없는 경우 지정한 기본값 적용 기본 값이 있기 때문에 required는 의미 없어짐 빈 문자의 경우도 기본값 적용 (요청: /request-param-default?username=) 클라이언트 to 서버 데이터 전달 방법 3가지 쿼리 파라미터 (GET) HTML Form (POST, 메시지 바디에 쿼리 파라미터 형식으로 전달) HTTP message body (POST, PUT, PATCH) 요청 파라미터 VS HTTP 메시지 바디 요청 파라미터 조회: @RequestParam, @ModelAttribute (생략 가능) HTTP 메시지 바디 조회: @RequestBody (생략 불가능, 생략하면 @ModelAttribute로 기능) 스프링 부트 3.2: 파라미터 이름 생략시 발생하는 예외 (@PathVariable, @RequestParam) java.lang.IllegalArgumentException: Name for argument of type [java.lang.String] not specified, and parameter name information not found in class file either. 해결방법 1. 파라미터 이름을 생략하지 않고 항상 적기 해결방법 2. 컴파일 시점에 -parameters 옵션 추가 (File -> Settings -> Build, Execution, Deployment → Compiler → Java Compiler -> Additional command line parameters) 해결방법 3. Gradle을 사용해서 빌드하고 실행 (권장) View 관련 기능 정적 리소스 (HTML, CSS, JS 제공) 스프링 부트는 기본 정적 리소스 경로 제공 src/main/resources/static 실제 서비스에서도 공개되기 때문에 공개할 필요없는 HTML을 두는 것을 조심할 것! 접근 요청: http://localhost:8080/basic/hello-form.html 제공: src/main/resources/static/basic/hello-form.html 뷰 템플릿 (동적 HTML 제공) 스프링 부트는 기본 뷰 템플릿 경로 제공 src/main/resources/templates 사용 방법 String 반환 ViewName 직접 반환 (뷰의 논리 이름을 리턴) @ResponseBody가 없으면 뷰 리졸버를 실행 String 반환: 리다이렉트 지원 (RedirectView) redirect:/ return "redirect:/basic/items/{itemId}"; RedirectAttributes 함께 사용 권장 URL에 ID 값을 넣을 때 URL 인코딩이 안되어 위험 URL 인코딩 + 경로변수, 쿼리 파라미터 처리 @PostMapping("/add") public String addItem(Item item, RedirectAttributes redirectAttributes) { Item savedItem = itemRepository.save(item); redirectAttributes.addAttribute("itemId", savedItem.getId()); redirectAttributes.addAttribute("status", true); return "redirect:/basic/items/{itemId}"; } ModelAndView 생성 및 반환 (권장 X) ModelAndView mv = new ModelAndView("뷰 논리경로") mv.addObject("객체 이름", 실제 객체): 모델에 데이터 추가 void 반환 (권장 X) 요청 URL을 참고해 논리 뷰 이름으로 사용 /response/hello(요청) -> templates/response/hello.html (실행) 실행 조건 @Controller O HTTP 메시지 바디 처리 파라미터 X (HttpServletResponse, OutputStream) 접근 반환: response/hello 실행: templates/response/hello.html HTTP 응답 메시지 바디 직접 입력 (API 방식, 정적 리소스나 뷰 템플릿 거치치 않음) @ResponseBody HttpMessageConverter 사용 단순 Text (StringHttpMessageConverter) -> String 리턴 JSON (MappingJackson2HttpMessageConverter) -> Java 객체 리턴 상태코드 입력: @ResponseStatus @ResponseStatus(HttpStatus.OK) 클레스 레벨 및 메서드 레벨 모두 적용 가능 HttpEntity HttpMessageConverter 사용 단순 Text (StringHttpMessageConverter) -> String 리턴 JSON (MappingJackson2HttpMessageConverter) -> Java 객체 리턴 return new HttpEntity<>("ok"); ResponseEntity HttpEntity를 상속 받음 HTTP Status Code 추가 가능 단순 Text 반환 타입 선언: ResponseEntity<String> return new ResponseEntity<>("Hello World", responseHeaders, HttpStatus.CREATED) JSON 반환 타입 선언: ResponseEntity<HelloData> return new ResponseEntity<>(helloData, HttpStatus.OK) 서블릿 응답 HttpServletResponse response response.getWriter().write("ok"); Writer responseWriter responseWriter.write("ok"); Model 관련 기능 @Controller @RequestMapping("/springmvc/v3/members") public class SpringMemberControllerV3 { private MemberRepository memberRepository = MemberRepository.getInstance(); @GetMapping("/new-form") public String newForm() { return "new-form"; } @PostMapping("/save") public String save( @RequestParam("username") String username, @RequestParam("age") int age, Model model) { Member member = new Member(username, age); memberRepository.save(member); model.addAttribute("member", member); return "save-result"; } @GetMapping public String members(Model model) { List<Member> members = memberRepository.findAll(); model.addAttribute("members", members); return "members"; } } Model model 파라미터 선언으로 편리하게 모델 사용 가능 model.addAttribute("객체 이름", 실제 객체): 모델에 데이터 추가 @ModelAttribute 요청 파라미터를 받아 객체에 바인딩하는 과정을 자동화 Primitive 이외 타입은 @ModelAttribute 생략가능 (argument resolver 지정타입 외) 이름을 생략하면 클래스 명의 첫글자만 소문자로 바꿔서 모델에 등록 (HelloData -> helloData) @ModelAttribute HelloData helloData 실행 과정 HelloData 객체 생성 요청 파라미터 이름으로 HelloData 객체의 프로퍼티 찾고 setter를 호출해 바인딩 @Data public class HelloData { private String username; private int age; } // 롬복 @Data = @Getter + @Setter + @ToString + // @EqualsAndHashCode + @RequiredArgsConstructor // 위험하기 때문에 사용 주의! DTO는 괜찮지만 핵심 도메인 모델엔 사용 X @ModelAttribute - 컨트롤러 레벨 적용 @ModelAttribute("regions") public Map<String, String> regions() { Map<String, String> regions = new LinkedHashMap<>(); regions.put("SEOUL", "서울"); regions.put("BUSAN", "부산"); regions.put("JEJU", "제주"); return regions; } 컨트롤러 클래스 내에 별도의 메서드로서 @ModelAttribute를 적용 가능 해당 클래스 내 모든 컨트롤러는 호출 시 미리 정의한 모델이 자동으로 담김 (반복 데이터 처리에 유리) HTTP 메시지 컨버터 @ResponseBody 사용시 반환값을 HTTP Body에 직접 입력 viewResolver 대신 HttpMessaveConverter 동작 HTTP Accept 헤더와 컨트롤러의 반환 타입 정보를 조합해 적절한 HttpMessageConverter 선택 HttpMessageConverter 인터페이스로서 HTTP 요청 및 응답에 모두 사용 주요 메서드 canRead(), canWrite(): 메시지 컨버터가 해당 클래스, 미디어타입을 지원하는지 체크 read(), write(): 메시지 컨버터를 통해 메시지를 읽고 쓰는 기능 동작 클래스 타입을 먼저 바라보고 컨버터 종류 채택 후, 미디어 타입 지원 확인 HTTP 요청 데이터 읽기 요청이 오고 컨트롤러는 @RequestBody, HttpEntity(RequestEntity) 사용 canRead() 호출 (메시지 컨버터가 메시지 읽을 수 있는 지 확인) 대상 클래스 타입을 지원하는가 (@RequestBody의 대상 클래스) HTTP 요청의 Content-Type 헤더의 미디어 타입을 지원하는가 조건을 만족하면 read() 호출해, 객체 생성 및 반환 HTTP 응답 데이터 생성 컨트롤러에서 @ResponseBody, HttpEntity(ResponseEntity)로 값을 반환 canWrite() 호출 (메시지 컨버터가 메시지를 쓸 수 있는지 확인) 대상 클래스 타입을 지원하는가 (return의 대상 클래스) 미디어 타입을 지원하는가 @RequestMapping의 produces가 세팅되어 있으면 이 값을 기준으로 처리 아니라면 HTTP 요청의 Accept 헤더의 미디어 타입을 지원하는지 여부 확인 조건을 만족하면 write() 호출해, HTTP 응답 메시지 바디에 데이터 생성 스프링 부트 기본 메시지 컨버터 (우선순위 순서로) ByteArrayHttpMessageConverter 기본이 바이트 배열로 오므로 변환 없이 그대로 받이들이는 것 클래스 타입: byte[], 미디어 타입: */* 요청 예 @RequestBody byte[] data 응답 예 @ResponseBody return byte[] 쓰기 미디어 타입: application/octet-stream StringHttpMessageConverter 바이트로 오는 데이터를 문자열로 처리 클래스 타입: String, 미디어타입: */* 요청 예 @RequestBody String data 응답 예 @ResponseBody return "ok" 쓰기 미디어타입: text/plain MappingJackson2HttpMessageConverter 바이트로 오는 데이터를 객체 또는 HashMap으로 처리 클래스 타입: 객체 또는 HashMap, 미디어 타입: application/json 요청 예 @RequestBody HelloData data 응답 예 @ResponseBody return helloData 쓰기 미디어타입: application/json HTTP 메시지 컨버터의 위치 HTTP 메시지 컨버터는 RequestMappingHandlerAdapter에서 실제로 사용 (애노테이션 기반) RequestMappingHandlerAdapter 동작 방식 ArgumentResolver 호출 정확히는 HandlerMethodArgumentResolver 핸들러의 파라미터, 애노테이션 정보를 기반으로 핸들러가 필요로 하는 요청 데이터 생성 (HttpServletRequest, Model, @RequestParam, @ModelAttribute, @RequestBody, HttpEntity) 과정 ArgumentResolver 구현체들을 탐색하며 (InvocableHandlerMethod) supportsParameter() 호출 (해당 파라미터 지원 여부 체크) 지원 가능하면 resolveArgument() 호출 (실제 객체 생성) HTTP 메시지 컨버터 사용해 데이터 처리 후 리턴 (canRead(), read()) 핸들러 호출 (with 생성된 요청 데이터) ReturnValueHandler 정확히는 HandlerMethodReturnValueHandler 컨트롤러의 반환 값을 변환해 응답 데이터 생성 (ModelAndView, @ResponseBody, HttpEntity) 과정 ReturnValueHandler 구현체들을 탐색하며 (ServletInvocableHandlerMethod) supportsReturnType() 호출 (해당 리턴 타입 지원 여부 체크) 지원 가능하면 handleReturnValue() 호출 HTTP 메시지 컨버터 사용해 데이터 처리 (canWrite(), write()) HTTP 메시지 컨버터 적용 경우 스프링 MVC는 다음 상황에서 HTTP 메시지 컨버터를 적용한다. HTTP 요청: @RequestBody, HttpEntity(RequestEntity) HTTP 응답: @ResponseBody, HttpEntity(ResponseEntity) 스프링 MVC 주요 ArgumentResolver & ReturnValueHandler @RequestBody, @ResponseBody 존재: RequestResponseBodyMethodProcessor() 사용 HttpEntity 존재: HttpEntityMethodProcessor() 사용 기능 확장 기능 확장은 WebMvcConfigurer 상속 및 스프링 빈 등록을 통해 구현한다. 스프링은 다음을 모두 인터페이스로 제공하므로, 언제든 커스터마이징 기능 확장이 가능하다. HandlerMethodArgumentResolver HandlerMethodReturnValueHandler HttpMessageConverter @Bean public WebMvcConfigurer webMvcConfigurer() { return new WebMvcConfigurer() { @Override public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) { //... } @Override public void extendMessageConverters(List<HttpMessageConverter<?>> converters) { //... } }; } Reference 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 View, ViewResolver (SERVLET) @RequestBody는 어떻게 동작할까?

Java-Ecosystem · 2024-04-21

스프링 로깅 기본

로깅 (Logging) 스프링 부트 로깅 라이브러리(spring-boot-starter-logging)에서 다음 로깅 라이브러리 사용 SLF4J 라이브러리: 로그 라이브러리를 통합해서 인터페이스로 제공 (Logback, Log4J, Log4J2…) Logback 라이브러리: 실무에서 구현체 로그 라이브러리로 주로 사용 (스프링 부트 기본 제공) 로그 선언 기본 사용법 private static final Logger log = LoggerFactory.getLogger(getClass()); 롬복 사용 @Slf4j 다음 코드를 자동 생성 private static final Logger log = LoggerFactory.getLogger(Xxx.class); 올바른 로그 사용법 올바른 사용법: log.debug("data={}", data) 잘못된 사용법: log.debug("String concat log=" + name) 로그 출력 레벨을 info로 설정하면 로그 남지 않으나, 더하기 연산은 무조건 수행되어 비효율 로그 출력 포멧 시간 / 로그 레벨 / 프로세스 ID / 쓰레드 명 / 클래스명 / 로그 메시지 로그 레벨 수준 (정보가 많은 순서로) TRACE > DEBUG > INFO > WARN > ERROR DEBUG: 개발 서버 적합 INFO: 운영 서버 적합 로그 레벨별 호출 방법 //@Slf4j @RestController public class LogTestController { private final Logger log = LoggerFactory.getLogger(getClass()); @RequestMapping("/log-test") public String logTest() { String name = "Spring"; log.trace("trace log={}", name); log.debug("debug log={}", name); log.info(" info log={}", name); log.warn(" warn log={}", name); log.error("error log={}", name); return "ok"; } } 로그 레벨 전역 설정 (application.properties) 전체 로그 레벨 설정 (디폴트: info) logging.level.root=info 특정 패키지 및 하위 패키지 로그 레벨 설정 logging.level.hello.springmvc=debug 장점 쓰레드 정보, 클래스 이름 같은 부가 정보 확인 가능 출력 포멧 조절 가능 로그 레벨 설정으로 상황에 맞게 조절 가능 파일, 네트워크 등 콘솔 뿐만 아니라 별도의 위치에 남길 수 있음 (파일의 경우 일별, 용량별 분할 가능) System.out 보다 성능도 좋음 Reference 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

Java-Ecosystem · 2024-04-14

스프링 부트 프로젝트 세팅

스프링 프로젝트 세팅 방법 프로젝트 GENERATE: https://start.spring.io Spring Boot Version은 SNAPSHOT, M2가 들어가지 않은 것이 정식 버전 Package name은 -가 안들어가도록 주의 ADD DEPENDENCIES: Spring WEB, Thymeleaf, Lombok, Validation, JPA, H2… Settings Lombok Plugins - Lombok 설치 Annotation Processing - Enable annotation processing Gradle - Build and run using, Run tests using - IntelliJ IDEA 변경 Main 함수 실행 - White label page 확인 H2 Database 세팅 방법 설치 - H2 Database 데이터베이스 파일 생성 (첫 진입) jdbc:h2:~/jpashop 다음 파일 생성 확인: ~/jpashop.mv.db 이후부터 TCP 연결 jdbc:h2:tcp://localhost/~/jpashop JPA 및 DB 설정 main/resources/application.yml spring: datasource: url: jdbc:h2:tcp://localhost/~/jpashop username: sa password: driver-class-name: org.h2.Driver jpa: hibernate: ddl-auto: create properties: hibernate: # show_sql: true # System.out을 통해 SQL 남김 (지양) format_sql: true logging.level: org.hibernate.SQL: debug org.hibernate.orm.jdbc.bind: trace ddl-auto create: 애플리케이션 실행 시점에 테이블을 drop하고 다시 생성 none: 테이블을 생성하지 않음 format_sql SQL이 포멧팅되어 조금 더 보기 좋게 나오게 함 org.hibernate.SQL (권장, 로그로 남기는게 좋음) logger를 통해 SQL 남김 org.hibernate.orm.jdbc.bind: trace SQL 실행 파라미터(쿼리 파라미터)를 로그로 남김 외부 라이브러리 (가독성 높은 쿼리 파라미터 로그) implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.0' 커넥션 정보, 가독성 높은 쿼리 파라미터 등 상세 정보 제공 시스템 자원을 잡아 먹으므로 운영 시스템에 적용하려면 반드시 성능 테스트 필요 (개발 단계 자유 사용) QueryDSL 설정 방법 (스프링 부트 3.0 이상) JDK 17 이상, 빌드 옵션으로는 Gradle 선택하기 (IntelliJ X) Preferences - Annotation Processors - Enable annotation processing 체크 build.gradle에 아래 설정 추가 //Querydsl 추가 implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta' annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta" annotationProcessor "jakarta.annotation:jakarta.annotation-api" annotationProcessor "jakarta.persistence:jakarta.persistence-api" 예제 엔터티(@Entity) 만들기 (Hello.class) Gradle - Tasks - build: build 작업 진행 생성된 build 폴더를 삭제하고 다시 하고 싶을 때는 clean 작업 진행 build - generated - sources - annotationProcessor - … - Q파일 생성 확인 (디렉토리) Test 설정 파일 spring: logging.level: org.hibernate.SQL: debug 경로: test/resources/application.yml 유용한 명령어 의존관계 확인 (Tree view) 프로젝트 디렉토리 - ./gradlew dependencies -configuration compileClasspath 서버 재시작 없이 View 파일 변경하기 spring-boot-devtools 라이브러리 추가 html 파일만 컴파일 (build - Recompile) 초기 데이터 생성 @Slf4j @RequiredArgsConstructor public class TestDataInit { private final ItemRepository itemRepository; /** * 확인용 초기 데이터 추가 */ @EventListener(ApplicationReadyEvent.class) public void initData() { log.info("test data init"); itemRepository.save(new Item("itemA", 10000, 10)); itemRepository.save(new Item("itemB", 20000, 20)); } } @EventListener(ApplicationReadyEvent.class) 스프링 컨테이너가 완전히 초기화를 끝내고, 실행 준비가 되었을 때 발생하는 이벤트 스프링 컨테이너가 AOP를 포함해 완전히 초기화된 시점 @PostConstruct의 경우, AOP 같은 부분이 다 처리되지 않은 시점에 호출될 수 있음 예를 들어, @Transactional 관련 AOP가 적용되지 않고 호출될 수 있어 문제 스프링은 이 시점에, initData()를 호출 프로필 (Profile) 프로필은 로컬, 운영 환경, 테스트 실행 등 다양한 환경에 따라 다른 설정을 할 때 사용하는 정보 로컬에서는 로컬 DB, 운영 환경에서는 운영 DB에 접근 환경에 따라 다른 스프링 빈 등록 스프링은 로딩 시점에 spring.profiles.active 사용 (spring.profiles.active=local) main 프로필: src/main/resources 하위 application.properties test 프로필: src/test/resources 하위 **`application.properties 프로필을 지정하지 않으면 "default" 프로필로 동작 설정파일(Config) 및 프로필 적용하기 @Import(MemoryConfig.class) @SpringBootApplication(scanBasePackages = "hello.itemservice.web") public class ItemServiceApplication { public static void main(String[] args) { SpringApplication.run(ItemServiceApplication.class, args); } @Bean @Profile("local") public TestDataInit testDataInit(ItemRepository itemRepository) { return new TestDataInit(itemRepository); } } @Import(MemoryConfig.class) 원하는 설정파일 적용 @Profile("local") 특정 프로필의 경우에만 해당 스프링 빈 등록 주요한application.properties 설정 트랜잭션 프록시가 호출하는 트랜잭션의 시작 및 종료 로그 확인 가능 logging.level.org.springframework.transaction.interceptor=TRACE logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG JPA 커밋 롤백 로그 확인 logging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG logging.level.org.hibernate.resource.transaction=DEBUG JPA SQL 로그 확인 logging.level.org.hibernate.SQL=DEBUG logging.level.org.hibernate.orm.jdbc.bind=TRACE HTTP 요청 메시지 확인하기 logging.level.org.apache.coyote.http11=trace

Java-Ecosystem · 2024-03-15

스프링 핵심원리 - 기본편

Java-Ecosystem · 2024-03-11

스프링 시작하기

빌드 및 실행 방법 ./gradlew build cd build/libs java -jar hello-spring-0.0.1-SNAPSHOT.jar 빌드가 잘 안될 때는 ./gradlew clean build 후 다시 빌드 (빌드 폴더 삭제) 주요 라이브러리 의존관계 스프링 부트 라이브러리 spring-boot-starter-web spring-boot-starter-tomcat: 톰캣 (웹서버) spring-webmvc: 스프링 웹 MVC spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View) spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅 spring-boot spring-core spring-boot-starter-logging logback, slf4j 테스트 라이브러리 spring-boot-starter-test junit: 테스트 프레임워크 mockito: 목 라이브러리 assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리 spring-test: 스프링 통합 테스트 지원 웹 개발 유형 변화 정적 컨텐츠 서버가 HTML 파일을 브라우저에게 그대로 넘겨주는 방식 과거에는 뷰와 컨트롤러 분리 없이 뷰로 모든 것을 다 하는 모델 원 방식을 사용 static/index.html 해당 경로로 index.html을 생성해두면 Welcome page가 된다. 예시 요청: localhost:8080/hello-static.html 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러가 없다면, resources/static/hello-static.html을 찾아 브라우저에 반환 MVC와 템플릿 엔진 컨트롤러에서 리턴 값으로 문자를 반환하면 뷰 리졸버(viewResolver)가 화면을 찾아 처리한다. 템플릿 엔진 viewName 매핑 resources/templates 하위에 있는 {viewName}.html 파일을 찾아 템플릿 엔진 처리 후 브라우저에 반환 예시 요청: localhost:8080/hello-mvc 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러를 찾음 컨트롤러는 hello-template이라는 문자열을 반환 viewResolver는 viewName 매핑으로 resources/templates/hello-template.html을 찾음 viewResolver가 Thymeleaf 템플릿 엔진에게 처리를 넘김 템플릿 엔진이 렌더링해서 변환한 HTML을 브라우저에게 반환 API @ResponseBody를 붙인 컨트롤러는 viewResolver를 사용하지 않는다. 결과 값을 JSON 형태로 HTTP Body에 담아 반환한다. viewResolver 대신 HttpMessageConverter가 동작 HTTP Accept 헤더와 컨트롤러 반환 타입 정보를 조합해 HttpMessageConverter가 선택됨 StringHttpMessageConverter (기본 문자처리) MappingJackson2HttpMessageConverter (기본 객체처리) xmlHttpMessageConverter (accept header에 xml로 요청) 예시 요청: localhost:8080/hello-api 톰켓 서버가 스프링 컨테이너에 요청 전달 요청에 대한 컨트롤러를 찾음 @ResponseBody가 붙은 컨트롤러이므로 반환값이 HttpMessageConverter에 전달됨 HttpMessageConverter가 데이터를 직렬화 후 HTTP Body에 담아 반환 Spring Bean 스프링 빈은 각 객체들 간의 의존관계를 저장하여 사용하기 편리하게 지원한다. 의존관계 등록방법 자동 의존관계 설정 (Component Scan) 정형화된 컨트롤러, 서비스, 레포지토리 같은 코드에 컴포넌트 스캔을 사용한다. 컴포넌트 등록 @Component 애노테이션이 있으면 스프링 빈으로 자동 등록된다. 다음 어노테이션들은 @Component를 포함하고 있어 역시 자동 등록된다. @Controller @Service @Repository @Autowired 해당 어노테이션이 붙은 메소드에게 스프링이 자동으로 연관 객체를 DI(의존성 주입)한다. 생성자에 사용시 객체 생성시점에 의존성 주입한다. 생성자가 하나라면 @Autowired 생략 가능 수동 의존관계 설정 (SpringConfig.java) 정형화되지 않거나 상황에 따라 구현 클래스를 변경해야 한다면 직접 설정으로 등록한다. 레포지토리를 다양하게 변경해야 하는 상황이라면 관리 포인트가 하나가 되어 편리 등록 방법 @Service, @Repository, @Autowired 등 현 상황에 불필요한 어노테이션은 제거 현재 앱 디렉토리에 SpringConfig.java 클래스 생성 클래스에 @Configuration, 메서드에 @Bean 어노테이션을 설정 메서드마다 필요한 인스턴스를 반환 @Configuration public class SpringConfig { @Bean public MemberService memberService() { return new MemberService(memberRepository()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } } 특징 스프링은 스프링 빈에 등록할 때, 객체를 싱글톤으로 등록한다. 즉, 같은 스프링 빈이면 모두 같은 인스턴스여서 메모리가 절약된다. (설정으로 변경은 가능) 예시 주문 컨트롤러에서 멤버 서비스, 멤버 레포지토리를 요청하면 똑같은 인스턴스를 넣어 줌 스프링 통합 테스트 테스트 클래스에 다음 어노테이션을 추가한다. @SpringBootTest 스프링 컨테이너와 테스트를 함께 실행한다. @Transactional 테스트 케이스에 해당 어노테이션을 추가하면, 테스트 시작 전에 트랜잭션을 시작하고 테스트 완료 후 항상 롤백한다. 덕분에 DB에 데이터가 남지 않아 각각의 테스트가 서로 영향을 주지 않는다. 스프링 DB 접근 기술 순수 JDBC 관련 코드들이 매우 장황하고 반복이 많다. JdbcTemplate SQL은 여전히 직접 작성하지만, JDBC의 반복 코드를 대부분 제거해준다. JPA ORM의 개념으로 넘어왔다. 데이터 중심 설계에서 객체 중심 설계 패러다임으로 전환할 수 있고 생산성을 크게 높인다. jdbc 관련 라이브러리가 포함되어 있다. 항상 @Transactional을 사용해서 데이터 변경을 트랜잭션 안에서 실행 시켜야 한다. 스프링 데이터 JPA 인터페이스만으로 개발 가능 메서드 이름만으로 조회 기능 제공 페이징 기능 자동 제공 단순 반복 코드가 크게 줄어드는 덕분에 개발자는 비즈니스 로직에 집중할 수 있다. Querydsl 복잡한 동적 쿼리 작업 AOP Aspect of Programming 관점 지향 프로그래밍 어떤 로직을 핵심 관심 사항, 공통 관심 사항으로 나누고 그 관점을 바탕으로 각각 모듈화 핵심 관심 사항 (core concern) 비즈니스 로직 공통 관심 사항 (cross-cutting concern) DB 연결, 로깅, 파일 입출력, API 계층별 응답 시간 측정 etc… @Aspect, @Around AOP in Spring 스프링은 프록시 방식의 AOP를 사용 스프링은 AOP가 있으면 서버가 올라올 때 컨테이너에서 스프링 빈에 등록하면서 가짜 스프링 빈을 앞에 세우고 그것이 끝나면 진짜 스프링 빈을 호출하도록 동작한다. (가짜 서비스 후 진짜 서비스 호출) 컨트롤러에서 서비스를 호출하면 서비스 코드는 스프링 빈을 통해 가짜 프록시 서비스를 의존성 주입 받고 해당 프록시 서비스가 끝나면 다시 실제 서비스 코드가 의존성 주입을 받아 실행된다. 이 방식은 스프링이 DI가 가능하기 떄문에 할 수 있는 기술 Reference 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술

Java-Ecosystem · 2024-02-08

Lucian Log

Contact

Spring