HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
♥️
2기 최종 프로젝트 팀별 공간
/
💸
10원모아10조❗️
/07월 19일 /
🔏
Luce 궁금증 및 제안
🔏

Luce 궁금증 및 제안

 
  1. 패키지
  • domain 안에서 exception을 넣고 각각의 domain 별로 핸들러를 만든 것을 확인했습니다.
    • 책임을 나누고, 유지보수 관점에서 handler를 쪼갠 것은 이해하였으나, exception을 domain 안에 패키지로 물고 있는 것이 다소 성격이 어울리지 않는다고 생각했는데 의도가 있으신 건지요..?
  • dto 안에 request response 클래스가 섞여있는데 dto안에서 패키지를 request와 response 나눠서 사용하는 것은 어떤지
 
  1. converter를 사용하는 것은 좋은데 메서드 네이밍을 바꿔보는 것은 어떤지 → 읽어야 될 정보가 너무 많다고 생각이 들었습니다
    1. to{domain}
      toResponse 와같이.
 
  1. Message(저의 경우 Errorcode) status도 여기서 같이 관리하는 것은 어떤지 - 한 눈에 보기 편해서 좋았다.
 
public enum Errorcode{ METHOD_NOT_ALLOWED(405, "적절하지 않은 HTTP 메소드입니다."), INVALID_TYPE_VALUE(400, "요청 값의 타입이 잘못되었습니다."), POST_NOT_FOUND(404, "해당 게시글이 존재하지 않습니다."), USER_NOT_FOUND(404, "해당 유저가 존재하지 않습니다."); private int status; private String message; ErrorCode(int status, String message) { this.status = status; this.message = message; } // message Map을 만들어 놓습니다. private static final Map<String, ErrorCode> messageMap = Collections.unmodifiableMap(Stream.of(values()) .collect(Collectors.toMap(ErrorCode::getMessage, Function.identity()))); // message에 해당하는 ErrorCode를 반환합니다. public static ErrorCode fromMessage(String message) { return messageMap.get(message); } }
 
@Getter public class NotFoundException extends RuntimeException { private final ErrorCode errorCode; public NotFoundException(ErrorCode errorCode) { super(errorCode.getMessage()); this.errorCode = errorCode; } }
 
// 실제 사용 예! private User getCurrentUser(Long userId) { return userRepository.findById(userId) .orElseThrow(() -> new NotFoundException(ErrorCode.USER_NOT_FOUND)); }
 
@ExceptionHandler(NotFoundException.class) public ResponseEntity<ErrorResponse> handleNotFoundException(NotFoundException e) { log.warn(e.getMessage(), e); ErrorResponse errorResponse = ErrorResponse.of(e.getErrorCode()); return ResponseEntity.status(errorResponse.getStatus()).body(errorResponse); }
 
  1. 상태 코드(프론트와 얘기해봐야하지만)
 
200 ok : (nocontent로 빈 데이터로 내보냄)
201 created : 생성후 location까지
204 no content
 
400 : 닉네임 중복, 이미 존재할 경우, 해당 요청이 올바르지 않을때(게시글에 좋아요를 눌러야되는데 이미 눌러져있거나, 지울때 좋아요가 눌리지 않는 경우)
404 : 없는 리소스를 요청할때
405 : 적절하지 않은 Http 메서드일 경우
 
기존에 저는 에러메시지의 경우 보안상 문제로 너무 자세한 메시지를 내려보내주진 않았습니다. 어디까지 자세히 내보내줘야할 지는 프론트 분들과 회의를 해봐야할 것같아요!
 
Spring Boot performance benchmarks with Tomcat, Undertow and Webflux
JHipster is used by thousands of people to generate production-ready Spring Boot applications. We've been using Undertow for years, with great success, but as we are planning for JHipster 7 we started discussing migrating away from Undertow.
Spring Boot performance benchmarks with Tomcat, Undertow and Webflux
https://dev.to/azure/spring-boot-performance-benchmarks-with-tomcat-undertow-and-webflux-4d8k
Spring Boot performance benchmarks with Tomcat, Undertow and Webflux
OKKY | Spring Boot 공식 지원 내장 WAS 인 Undertow 을 씁시다.
Java 가 Web 개발에서 두각을 나타내면서 WAS(Web Application Server) 라는 용어를 널리 사용하게 만들었습니다. 처음의 의도와 달리 WAS 을 지칭하는 의미는 점차 확대되었고, Java 에서는 Apache Tomcat(이하 Tomcat) 이라는 WAS 가 널리 보급되면서 온라인 상에 유통되는 대부분의 WAS 에 관한 것은 Tomc
OKKY | Spring Boot 공식 지원 내장 WAS 인 Undertow 을 씁시다.
https://okky.kr/article/543099
OKKY | Spring Boot 공식 지원 내장 WAS 인 Undertow 을 씁시다.
JBoss EAP7 의 변경된 Connector와 Thread 처리
JBoss EAP 7 (이하 EAP7)이 나온지도 몇개월이 되었고 (2016년 Q3) 아직 시장에 많이 풀리지는 않았고 패치도 열심히 올라오는 중임 이번에 바뀐 부분중에서 핵심(?)적이라고 할만한 부분을 말해보자면 서블릿 컨테이너를 전면 교체 하면서 요청을 받아들이는 Connector 부분과 WAS의 실질적인 요청처리 작업을 하는 Thread의 구조 및 Pooling 방법이 변경되었다 먼저 톰켓(tomcat)과 같이 설명을 하자면 EAP6까지는 Listener(Connector), Thread Pool, servlet 처리 부분을 Tomcat으로 처리해왔다 실제 tomcat 소스를 임포트 해서 개발했다고 보면 무방하다 그러다보니 tomcat tuning 포인트와 같이 생각하면 됬다.
JBoss EAP7 의 변경된 Connector와 Thread 처리
https://yckwon2nd.blogspot.com/2017/01/jboss-eap7-connector-thread.html
 
//spring implementation('org.springframework.boot:spring-boot-starter-web') { exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat' } // WAS: undertow implementation 'org.springframework.boot:spring-boot-starter-undertow'