루루의 우당탕탕 개발 스토리 루루의 우당탕탕 개발 스토리

작업을 하다보면, 개발 서버와 운영 서버를 분리할 필요성이 있었고 운영 서버를 분리하기 위해 jar앱을 배포하는 방법을 찾아보았다. 방법은 간단하다. 1. 오른쪽에 보이는 Gradle 클릭 2. Gradle이 오픈되면 아래의 bootJar 클릭 클릭시, 왼쪽의 build 폴더 아래에 libs라는 폴더가 생긴다. 3. libs 아래에 있는 ㅇㅇㅇ.jar 다른 cmd 열어서 실행해주기 이제 저 녀석만 실행해주면 되는데 나의 경우엔 cmd를 분리하기 위해 따로 cmd를 켜서 해당 경로로 들어가 java.jar ㅇㅇㅇ.jar로 실행해주었다. 운영 서버는 cmd로 따로 실행해주었으니, 이제 개발 서버를 실행해보자 4. 포트 바꿔서 개발 서버 실행하기 나의 경우 포트 설정을 따로 해주지 않아 jar 파일은 8080..

logback-spring.xml 설정 시 아래와 같은 에러가 뜰 수 있다. %PARSER_ERROR[clr] %PARSER_ERROR[clr] %PARSER_ERROR[clr] %PARSER_ERROR[clr] %PARSER_ERROR[clr] %PARSER_ERROR[clr] Application run failed java.lang.IllegalStateException: Logback configuration error detected: ERROR in ch.qos.logback.core.pattern.parser.Compiler@46cdf8bd - There is no conversion class registered for composite conversion word [clr] ERROR i..

1. Logback 이란? - java.util.logging, log4j, log4j2등을 잇는 자바 로깅 프레임워크 - spring boot에서는 기본 로깅 모듈로 채택 1-1. slf4j (Simple Logging Facade For Java) - 자체적인 로킹 프레임워크가 아니고 logger 추상체로써 다른 로깅 프레임워크가 접근할 수 있도록 도와주는 추상화 계층 - 즉, logback이나 log4j2와 같은 로킹 프레임워크의 인터페이스의 역할 - slf4j2를 이용하면 코드를 일정하게 유지하면서 구현체의 전환을 통해 다른 로깅 프레임워크로이 손쉬움 1-2. log4j vs logback vs log4j2 Log4j Logback Log4j2 가장 오래된 로깅 프레임워크 2015년 이후 개발 중..

생성자가 주입되지 않아 생긴 문제 1. 접근자를 final로 선언해야 롬복이 작동하므로 final로 repository를 선언 2. 해당 클래스 위에 lombok의 @RequiredArgsConstructor를 attach해준다. 사용 예시 @Service @RequiredArgsConstructor public class MyInfoService { final UserRepository userRepository; final EssayRepository essayRepository; public MyInfoDto.Response getMyInfo(String user_id) { User myInfo = userRepository.findByUserId(user_id); List essay = essay..

1. 영속성 컨텍스트 정의 일종의 메모리 저장소이며 엔티티 타입과 식별자를 키로 사용하는 객체의 집합을 의미 엔티티 매니저(EM)는 커밋 시점에 영속성 컨텍스트에서 관리하고 있던 영속 객체의 변경 내역을 추적하여 DB에 반영 2. 엔티티 매니저와 영속성 컨텍스트 엔티티 매니저를 생성할 때 하나의 영속성 컨텍스트가 생성 엔티티 매니저는 동일한 식별자를 갖는 엔티티를 2번 조회하게 되면 - 첫 번째는 쿼리가 실행됨 - 두 번째는 쿼리가 실행되지 않고 캐시에 저장되어있는 영속 객체를 영속성 컨텍스트에서 가져옴 3. 엔티티 매니저 DB에 엑세스 하기 위해 사용되는 객체 엔티티 매니저를 통해 DB에 데이터를 CRUD 작업을 수행 3-1. 엔티티 매니저 종류 애플리케이션에서 관리하는 엔티티 매니저 애플리케이션에서 ..

JPA Repository에 있는 데이터를 직접 정의한 class에 바로 담기 위해 고군분투를 해보았다. 실제로 Entity 형식이 아닌 다른 형식으로 데이터를 바로 담고 싶을 때가 있었다. 즉 NativeQuery를 활용해 SQL로 가공 및 처리하여 필요한 정보만을 추출해 서버단에서는 가공된 데이터만을 받아서 클라이언트에게 전달하는 역할만 하는 것이 더 효율적이라고 판단했기 때문이다. NativeQuery로 작성한 쿼리를 직접 정의한 class(POJO or DTO)로 불러오기 다음과 같은 에러가 떴다. ConverterNotFoundException org.springframework.core.convert.ConverterNotFoundException: No converter found capab..