SingletonService가 JVM이 뜰 때 생성되는게 맞나요?

안녕하세요. 파부님결론부터 말씀드리면, SingletonService 객체는 “JVM이 실행되는 순간” 생성되는 것이 아니라, SingletonService 클래스가 처음 실제로 사용되어 초기화될 때 생성됩니다.예를 들어public class Main { public static void main(String[] args) { System.out.println("main 시작"); }}이 경우 JVM은 Main 클래스는 사용하지만, SingletonService 클래스는 아직 사용할 필요가 없습니다. 그래서 SingletonService 클래스가 로딩/초기화되지 않고, 당연히 생성자도 호출되지 않습니다.감사합니다.

아주 작은 정오표 전달드립니다.

터프남님 감사합니다 :) 다음 패치에 반영할게요!

order_product 까마귀발

안녕하세요. 김진규님생각하신 내용이 맞습니다 :)감사합니다.

SpringBoot 4.0.6 버전에서 PackageLogTracePostProcessor exception

안녕하세요. 마성호님Configuration도 프록시 대상에 추가되는 문제가 있는 듯 합니다.다음 코드를 참고해서 Configuration을 제외하는 코드를 적용해주세요 🙂감사합니다. package hello.proxy.app.config.v4_postprocessor.postprocessor; import lombok.extern.slf4j.Slf4j; import org.jspecify.annotations.Nullable; import org.springframework.aop.Advisor; import org.springframework.aop.framework.ProxyFactory; import org.springframework.beans.BeansException; import org.springframework.beans.factory.config.BeanPostProcessor; import org.springframework.context.annotation.Configuration; import org.springframework.core.annotation.AnnotationUtils; import org.springframework.util.ClassUtils; @Slf4j public class PackageLogTracePostProcessor implements BeanPostProcessor { private final String basePackage; private final Advisor advisor; public PackageLogTracePostProcessor(String basePackage, Advisor advisor) { this.basePackage = basePackage; this.advisor = advisor; } @Override public @Nullable Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { log.info("param beanName={} bean={}", beanName, bean.getClass()); // 프록시 대상 여부 체크 // 프록시 적용 대상이 아니면 원본 그대로 진행 String packageName = bean.getClass().getPackageName(); if (!packageName.startsWith(basePackage)) { return bean; } // 설정 클래스(@Configuration)는 프록시 대상에서 제외 // 설정 클래스를 프록시로 감싸면 @Bean 팩토리 메서드 호출이 깨진다 // (CGLIB로 강화된 설정 클래스라 getUserClass로 원본 클래스를 얻어 어노테이션을 검사) Class userClass = ClassUtils.getUserClass(bean.getClass()); if (AnnotationUtils.findAnnotation(userClass, Configuration.class) != null) { return bean; } // 프록시 대상이면 프록시를 만들어서 반환 ProxyFactory proxyFactory = new ProxyFactory(bean); proxyFactory.addAdvisor(advisor); Object proxy = proxyFactory.getProxy(); log.info("create proxy: target={} proxy={}", bean.getClass(), proxy.getClass()); return proxy; } }

[DB설계] 탈퇴 유저의 구독 정보 유지 및 이메일 마스킹 관련 질문입니다.

안녕하세요. obi님우선 제 생각에 비즈니스 정책을 단순하게 변경하는게 가장 좋을 것 같아요.하지만 그게 어려운 상황이라면, 중간 테이블을 하나 만들어서 해결하는 것이 필요합니다.예를 들어서 users -> subscribers -> subscriptions 구조를 만드는 것이지요. users: 로그인 계정subscribers: 구독 권리를 가진 주체subscriptions: 현재 구독 정보 users는 탈퇴 후 재가입하면 새로 생길 수 있으니, 구독이 직접 바라보면 안 됩니다.대신 구독은 오래 유지되는 subscriber_id를 바라보게 합니다.그래서 재가입 시에는 새 users 로우를 만들고, 기존 subscriber_id에 다시 연결합니다.즉, 핵심은 구독의 FK를 user_id가 아니라 subscriber_id로 바꾸는 것입니다.감사합니다.

김영한로드맵으로 백엔드개발자가 될 수 있나요?

안녕하세요. 호준님이 로드맵은 이미 실무에 있는 주니어 개발자 분들도 많이 듣고 있는 로드맵이어서, 모든 과정을 충분히 소화한다면 실무에 필요한 개발자가 될 수 있다 생각합니다.취업을 기준으로 생각하면다면 생각하신 대로 진행하시되 다음 내용을 참고해서 전체 로드맵을 진행하시는 것을 추천드립니다.전체 로드맵은 다음을 참고해주세요.https://youtu.be/8hsFZg-i6wo?si=pIfnDiSRvja5LkvS 감사합니다 🙂

문제2번

안녕하세요. Choi님이런 부분을 한번에 다 완벽하게 답을 구하는 것은 쉽지 않습니다.많은 분들이 권장하는 방법은 우선 처음부터 끝까지 강의를 다 듣고, 그 다음에 한번 정도 복습하면서 정리하는 것입니다. (사실 어느정도 익숙해짐이 필요합니다.)도움이 되시길 바래요 🙂

SpringBoot 4.0.6 버전에서 PackageLogTracePostProcessor exception

안녕하세요. 마성호님도움을 드리고 싶지만 질문 내용만으로는 답변을 드리기 어렵습니다.실제 동작하는 전체 프로젝트를ZIP파일로 압축해서 구글 드라이브로 공유해서 링크를 남겨주세요.구글 드라이브 업로드 방법은 다음을 참고해주세요.https://bit.ly/3fX6ygx 주의: 업로드시 링크에 있는 권한 문제 꼭 확인해주세요추가로 다음 내용도 코멘트 부탁드립니다.1. 문제 영역을 실행할 수 있는 방법2. 문제가 어떻게 나타나는지에 대한 상세한 설명 (오류 화면, 오류 로그 포함)링크: 공식 서포터즈링크: 자주하는 질문감사합니다.

1:N 관계에서 중간테이블 (연관엔티티)

안녕하세요. shim9597님비즈니스 상황에 따라서 다른데요.질문하신 내용은 잘 생각해보면 이것은 1:N이 아니라 M:N이 맞습니다.왜나하면 하나의 예매는 여러 좌석을 예매할 수 있고, 하나의 좌석은 시간이 흐름에 따라 여러 예매에 의해서 예약되기 때문입니다. 따라서 이 경우 예매 - 예매좌석 - 좌석의 형태가 되어야 합니다.특히 예매와 좌석 만으로 1:N으로 구성하게 되면 문제가 있는데요.예를 들어 예매를 하신 이후에 예매를 취소하고, 다른 사람이 그 자리를 재예매 하는 경우 처음 예매한 좌석의 정보가 사라지는 문제가 있습니다.감사합니다.

공통코드 관련한 질문 드립니다.

안녕하세요. 쿵쿵뛰는꼬부기님애플리케이션에서 메타시스템DB에 직접 접근하기 보다는, 성능 저하 및 장애 확산(SPOF) 방지를 위해 '메타시스템(설계) → 서비스 DB(동기화) → 캐시(조회)' 파이프라인 구조를 권장합니다. 이때 실시간 변경이 필요하지 않다면 물론 ENUM을 사용하셔도 됩니다.슈퍼셋(Superset) 마스터 코드 전략을 권장합니다. 동일한 도메인(개념)을 공유한다면, 메타시스템 레벨에서 모든 상태를 포괄하는 표준 코드 하나만 정의하는 것입니다. 그렇지 않으면 향후 통합이 큰 어려움이 있을 거에요. 그런데 이름만 같을 뿐 개념과 관리 규칙이 완전히 독립된 서비스라면 당연히 둘을 분리해야 합니다.감사합니다.