[오타 제보] 2. IO 기본1.pdf

dev.rudevico님 고급 1편을 잘 마무리 하시고 고급 2편으로 잘 넘어오셨군요 🙂이번에도 도움 주셔서 진심으로 감사합니다!다음 패치에 반영할게요 🙂

[오타 제보] pdf 13장 정리 부분

dev.rudevico님 벌써 여러번 도움을 주셨네요 🙂 진심으로 감사합니다^^!다음 패치에 반영하겠습니다 🙂

다대다 연관관계를

안녕하세요. 오리쉐리님다음 답변을 참고해주세요.https://www.inflearn.com/questions/1533500감사합니다.

다대다 연관관계에서

안녕하세요. 오리쉐리님여기서 말하는 일대다 관계라는 것은 Member, Order 간의 관계에서 Member 입장에서 보면 일대다, Order 입장에서 보면 다대일 관계라는 것을 의미합니다.네 중간 테이블이 다 입장이기 때문에 중간 테이블을 기준으로 다대일 관계를 만드시면 됩니다. 이때 양방향 연관관계가 필요하다면 중간 테이블의 반대쪽에서 일다대 관계를 만드시면 됩니다.감사합니다.

2개의 빈 등록 오류

안녕하세요. yaminma3님스프링 부트 3.2 이상의 경우 빌드 옵션을 IntelliJ 대신에 Gradle을 선택해야 합니다.강의 메뉴얼 2. 스프링 핵심 원리 이해1 - 프로젝트 생성 부분을 참고해주세요.이렇게 설정한 다음에 프로젝트를 다시 시작하고, 기존 테스트는 삭제하시고 새로운 테스트를 시작해주세요.감사합니다. 주의! 스프링 부트 3.2 부터 Gradle 옵션을 선택하자.스프링 부트 3.2 부터 앞서 Build and run using에 앞서 설명한 IntelliJ IDEA를 선택하면 몇가지 오류가 발생한다. 따라서 스프링 부트 3.2를 사용한다면 다음과 같이 IntelliJ IDEA가 아니라 Gradle을 선택해야 한다.(사진)* Windows: File -> Settings(Ctrl+Alt+S)* Mac: IntelliJ IDEA | Preferences(⌘,)* Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle* 빨간색 박스의 Build and run using를 Gradle로 선택합니다.* 빨간색 박스의 Build tests using를 Gradle로 선택합니다. 감사합니다.

이 경우는 왜 그런 것일까요?

안녕하세요. 조태준님스프링의 @Configuration 어노테이션과 CGLIB를 통한 바이트코드 조작의 동작 방식에 관한 질문으로 이해했습니다.질문하신 내용을 정리하자면:beanA1과 beanA2는 같은 인스턴스를 참조하고 있음beanA3는 다른 인스턴스임왜 beanA2()에서는 beanA1()을 호출할 때 새 인스턴스를 생성하지 않고, beanA3()에서는 new BeanA()로 새 인스턴스를 생성하는지에 대한 의문이 현상이 발생하는 이유는 다음과 같습니다:스프링에서 @Configuration 클래스는 CGLIB 프록시로 감싸집니다. 이 프록시는 @Bean 메서드의 호출을 가로채서 싱글톤 레지스트리에서 빈을 찾거나 생성하는 역할을 합니다.중요한 차이점은 메서드 호출과 직접 객체 생성입니다:beanA2() 메서드에서 return beanA1();은 다른 @Bean 메서드를 호출합니다.이 호출은 CGLIB 프록시에 의해 가로채져서 이미 생성된 빈을 반환합니다.따라서 beanA1과 beanA2는 같은 인스턴스를 참조합니다.beanA3() 메서드에서 return new BeanA();는 직접 객체를 생성합니다.이것은 메서드 호출이 아니라 객체 생성 코드이므로 CGLIB 프록시가 가로채지 않습니다.따라서 새 인스턴스가 생성되어 beanA3는 다른 인스턴스를 참조합니다.CGLIB 프록시는 메서드 호출을 인터셉트할 수 있지만, 클래스 내부의 new 키워드를 사용한 객체 생성은 인터셉트하지 않습니다.프록시가 바이트코드를 조작할 때, return beanA1();와 같은 메서드 호출은 프록시의 로직으로 대체되어 싱글톤 관리를 처리하지만, return new BeanA();와 같은 객체 생성 코드는 그대로 실행됩니다.실제로 생성된 프록시 클래스의 내부 동작은 대략 다음과 같을 것입니다:// CGLIB가 생성한 프록시 클래스 (유사 코드) class AppConfig$$EnhancerBySpringCGLIB extends AppConfig { private BeanFactory beanFactory; // 스프링의 빈 팩토리 참조 @Override public BeanA beanA1() { // 이미 빈이 존재하는지 확인 if (beanFactory.containsBean("beanA1")) { return beanFactory.getBean("beanA1", BeanA.class); } // 없으면 부모(원본) 메서드 호출하여 빈 생성 return super.beanA1(); // 여기서 실제로 new BeanA() 실행 } @Override public BeanA beanA2() { // 이미 빈이 존재하는지 확인 if (beanFactory.containsBean("beanA2")) { return beanFactory.getBean("beanA2", BeanA.class); } // 없으면 부모 메서드 호출하여 빈 생성 // 여기서 중요한 점: beanA1()은 프록시 메서드를 호출! return beanA1(); // 프록시의 beanA1() 호출, 이미 생성된 빈 반환 } @Override public BeanA beanA3() { // 이미 빈이 존재하는지 확인 if (beanFactory.containsBean("beanA3")) { return beanFactory.getBean("beanA3", BeanA.class); } // 없으면 부모 메서드 호출하여 빈 생성 return super.beanA3(); // 여기서 실제로 new BeanA() 실행 } } 따라서 바이트코드 조작시 return 문에 들어가는 것이 '메서드 호출'인지 'new 객체 생성'인지에 따라 다르게 처리되며, 이것이 바로 beanA2와 beanA3가 다르게 동작하는 이유입니다.감사합니다.

AI 말고 지식공유자님의 답변 부탁드립니다

안녕하세요. 조태준님링크에 답변 남겨드렸습니다 🙂저희가 하루 이틀 정도 지나서 추가 요청이 없으면 AI 답변으로 만족하신 것으로 판단해서 넘어가는 경우들이 종종 있는데요.이런 경우 지금처럼 추가로 남겨주시면 저희가 끝까지 도와 드리겠습니다 🙂감사합니다.

질문글들을 읽던 중 궁금한 것이 생겼습니다

안녕하세요. 조태준님 🙂 엔트로피님의 답변은 애초에 등록할 빈의 이름을 mainDiscountPoilicy로 사용해야 한다는 것이 전재되어 있습니다.감사합니다.

"@Autowired 필드명"과 "@Primary" 우선순위

안녕하세요. 조태준님네 생각하신 내용이 맞습니다.@Primary 정보는 BeanDefinition 에도 함께 저장되어, 실제 주입 시점에 프라이머리 후보로 확인합니다.감사합니다.

필터가 디폴트로 DispatcherType.REQUEST만 세팅되어 있으면 에러 요청시 필터를 거치치 않는 것 아닌가요?

안녕하세요. 수하님디폴트는 REQUEST가 맞지만, 만약 설정을 처음부터 REQUEST, ERROR 등 여러가지로 한다면 문제가 된다고 이해하시면 됩니다 🙂 감사합니다.