묻고 답해요
131만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 핵심 원리 - 기본편
싱글톤컨테이너의 싱글톤 방식에 대해 질문있습니다!
싱글톤 컨테이너의 방식에 궁금한점이 있어 질문드립니다 스프링 컨테이너를 통해 수많은 회원들의 요청이 들어와도 같은 빈객체를 주게된다고 들었습니다. 그렇다면 똑같은 객체를 사용하게되면 모든 회원들이 처음 등록된 빈의 같은 회원정보를 사용하게되어 내 회원정보가 이상하다거나 계산내역이 기존사람의것이 되는등등 문제가 발생되는것이 아닌가요?
-
미해결스프링 핵심 원리 - 기본편
@RequiredArgsConstructor , @Primary 질문있습니다
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]안녕하세요 영한님 항상 좋은강의 감사합니다 다름이아니라 질문이있는데 @Component를 FixDisCountPolicy와 RateDisCountPolicy 둘다 주어졌을때 오류가 발생하는데 이때 OrderServiceImpl에는 @RequiredArgsConstructor를 붙이고 DiscountPolicy중 우선순위를 가질것에 @Primary를 붙이는 즉@RequiredArgsConstructor,@Primary 두가지만 사용하면 코드의 수정없이 가장 효율적이라고 생각되는데 제 생각이 맞는지 궁금합니다
-
미해결스프링 핵심 원리 - 기본편
컴포넌트 스캔 관련 질문
@Component 를 붙인 것들은 모두 @ComponentScan의 자동 빈 등록의 대상이 됩니다. 그런데 basePackageClasses 의 범위가 있다면 해당 패키지 내부에서만 빈 등록 대상을 찾게됩니다. 1. @SpringBootApplication 에는 이미 @ComponentScan이 있습니다. 해당 부트의 basePackageClass 를 변경하지 않는 한 임의의 Configration 내부에 Bin 을 쓰든 Component 안에 Bin을 주입하든 사실상 이미 부트가 모든 Component 를 관리하고 있어서 위 시점에서는 수동 주입한다는 개념이 없는것이 맞는건가요. 2. 위 질문과 비슷한 질문인데요.. 제가 임의의 스프링부트에 Aconfig 와 Bconfig 를 만들었다고합시다. 그리고 동일하게 컴포넌트 스캔을 이용하여 각각 다른 패키지를 basePackageClass 를 지정했다고 한다면 이게 어떤 의미가 있는걸까요? @SpringBootApplication 에는 디펄트로 하위 모든 컴포넌트를 찾아서 자동등록을 하는데..
-
미해결스프링 핵심 원리 - 기본편
컴포넌트 스캔관련 질문드립니다 ㅎㅎ
안녕하세요~~ 강의 잘 보고있습니다. 최고의 강사!! 궁금증이 생겨서 질문 드립니다 ㅎㅎ @SpringBootApplication이 붙은 CoreApplication을 통해 동작하면 ComponentScan을 하는데 AppConfig와 AutoAppConfig의 @Configuration이 붙어있잖아요,, @Configuration을 따라 들어가니까 @Component가 있어서 아 그럼 얘도 컴포넌트 스캔 대상이구나 라고 생각했어요. 그래서 여기서 더 나아가서 생각해보니까 복잡해졌는데요,,, AppConfig와 AutoAppConfig 둘 중 컨테이너에 등록하는 순서가 있나요??? 왜이런 질문이 나왔냐면,,, 강의내용 코딩따라했을 때 코드 기준으로 AppConfig는 excludeFilters가 없고 AutoAppConfig에는 excludeFilters로 @Configuration 애노테이션 등록된것을 제외하였는데 먼저 등록하는 순서라는게 존재한다면 순서에 따라 먼가 다를것 같습니다... AppConfig먼저 1. AppConfig의 빈등록절차 진행 2. AutoAppConfig의 빈등록절차를 진행하려고 보니까 @Configuration이 붙은애들을 제외 시켰네? 이미 @Configuration이 붙은 AppConfig빈등록 다 해놨는데 어쩌지 가 될 것 같아서요,,,, AutoAppConfig먼저 1. AutoAppConfig의 exclude로 Configuration했으니 "@Configuration붙은애들 진행시키지마" 가 되겠고 2. 컴포넌트 스캔으로 @Component붙은것들(@Repository, @Controller, @Component 등) 빈등록진행, AutoAppConfig에 @Bean이 붙은 애들 빈등록 3. AppConfig 빈등록 제외 이렇게되면 깔끔하게 너 하지마 이것만 한다 라는 먼가 질서가 생기는데 제가 너무 깊이 생각했나 싶어요,, 죄송합니다 헷갈림으로 인해 헷갈리고 헷갈려서 헷갈려요,,,
-
미해결스프링 핵심 원리 - 기본편
리텐션, requiredArgsConstructor 질문 있습니다.
=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용] 안녕하세요 강사님~! 롬복 어노테이션인 requiredArgsConstructor 가 있으면 컴파일 시점에서 생성자를 자동 생성해 주잖아요. 근데 해당 어노테이션 선언을 들어가 보면 Retention policy가 Source 로 돼 있어요. 제 생각으론 Compile 로 돼 있어야 컴파일 시점에 해당 어노테이션이 메모리에 남아있어 해당 어노테이션을 보고 생성자를 생성할 것 같은데 말이죠. requiredArgsConstructor 의 Retention policy가 Source 로 돼 있어도 컴파일 시점에 생성자를 생성할 수 있나요? 감사합니다 ^0^
-
미해결스프링 핵심 원리 - 기본편
AppConfig만 사용해도 DI 잘 됐던 거 같은데
AppConfig만 사용해도 DI는 잘 됐던 거 같은데, MemberApp(스프링 컨테이너)까지 만들어서 사용하는 이유는 'DI 외에 다른 스프링 기능을 활용하기 위해서'가 맞는 거죠?
-
미해결스프링 핵심 원리 - 기본편
스프링 빈의 라이프사이클 내에서
안녕하세요, 다른 분들의 질문을 참고해봐도 혼자서 이해하는게 너무 버거워서 질문을 남깁니다. 여기저기 출력문을 찍어보니 ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class); 에서 "스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존 관계 주입 -> 초기화 콜백" 까지 한번에 된다는 사실을 알았습니다. public class BeanLifeCycleTest { @Test public void lifeCycleTest() { System.out.println("rmfjadjswptodtjdeh;a??1"); ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class); System.out.println("rmfjadjswptodtjdeh;a??2"); NetworkClient client = ac.getBean(NetworkClient.class); ac.close(); } @Configuration static class LifeCycleConfig { @Bean public NetworkClient networkClient() { NetworkClient networkClient = new NetworkClient(); //networkClient.setUrl("http://hello-spring.dev"); System.out.println("stestesatestasetasetaset"); return networkClient; } } } 1. setUrl은 생성자 주입처럼 동시에 의존관계가 주입되는게 맞을까요?? 2. 여기서 setUrl은 다른 분들의 질문을 보니 값 주입이라고 하던데 의존관계 주입이나 값 주입이나 비슷하다고 이해하고 넘어가면 될까요?? 3. afterPropertiesSet() 은 따로 호출을 하지 않았는데, 어떻게 호출을 하는건가요?? 4. 초기화 콜백은 '무조건' 호출이 되는 걸까요? 실제로 setUrl을 주석 처리해도 콜백함수가 호출이 됩니다. 질문이 조금 많지만 답변 부탁드립니다 ㅠㅠ 감사합니다.
-
미해결자바스크립트 비기너: 튼튼한 기본 만들기
Object type의 toString에 대해서
안녕하세요 강의를 듣다가 궁금증이 생겨서 질문 드리게 되었습니다. Built-in Object타입의 toString의 경우 어떤식으로 사용 할 수 있나요? 제가 테스트 해본 코드는 var object = {1: 123}; console.writeline(object.toString()); 이었습니다만 그 결과가 [object object]로 나왔습니다. 예상으로는 property의 이름이나 값을 출력해줄 것이라 생각했는데 단지 []괄호와 object만 출력이 되어 내부가 어떻게 돌아가는지 잘 이해가 가지 않아 질문드리게 되었습니다. 감사합니다.
-
미해결스프링 핵심 원리 - 기본편
회원 도메인 개발 05:52
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://docs.google.com/document/d/1j0jcJ9EoXMGzwAA2H0b9TOvRtpwlxI5Dtn3sRtuXQas/edit#heading=h.w2tomwsznga7)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://docs.google.com/document/d/1xCQKit-1V6l6ObeCe49St33RHPzLF_P_c3o7aSDTKs0/edit#heading=h.7dhnp46ven0v)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용] 안녕하세요. 질문 있습니다. store.put(member.getId(), member)에서 value로 member.getName()이 와야하지 않나요? 왜 member인지 모르겠습니다..ㅠ
-
미해결스프링 핵심 원리 - 기본편
@Configuration 없이 @Bean만 사용할 때에 대한 질문
안녕하세요! 진짜 영한님 강의는 최고네요. 감사합니다. 듣다가 질문이 생겼는데요. `@Configuration`을 주석처리하고 `@Bean`만 남겼을 때 빈으로 등록되긴 하는데 여러개가 등록(싱글톤 X)된다고 하셨잖아요. 여기서 헷갈리는 이유는, "Bean은 스프링컨테이너에서 관리되는 싱글톤 객체이다."라는 이론적 내용과, "같은 이름의 Bean이 여러개 생성되기도 한다"라는 이 강의의 실험 결과과 충돌해서인데요. 엄밀한 정리를 하고 싶어서 질문드려요. 일단은 "같은 이름의 Bean이 여러개 생성되기도 한다"가 먼저 가능성 측면에서 맞는 얘기고, "Bean은 스프링컨테이너에서 관리되는 싱글톤 객체이다."는 정상적(일반적)인 방식으로 Bean을 등록한다면이라는 전제가 깔렸을 때 맞는 얘기일 거로 생각 됩니다. 그럼, 아래 내용중에는 무엇이 맞는 걸까요? 영한님이 보여주신 실험처럼, `@Configuration`을 누락하면 동일한 Bean이 여러번 생성되는 경우가 있는데 이 때, 1. `memberRepository`라는 메서드가 3번이나 호출되었는데, 새로 생성될 때마다 기존에 먼저 생성되었던 빈을 덮어쓰기(override)한다. 고로 생성만 N번 될 뿐이지, 결과적으로는 스프링 내에서는 싱글톤으로 존재한다.(* 만일 이게 맞다면 컴파일타임/런타임 모두 에러가 안나고, 동작 자체에는 문제가 없겠네요. 리소스는 많이 잡아먹겠지만요.) 2. `memberRepository`라는 메서드가 3번이나 호출되어 총 3개의 인스턴스가 빈으로 각각 등록되었다. 고로 이름을 같지만 3개의 빈이 실제로 모두 존재한다. (* 만일 이게 맞다면, 이 경우 빈을 사용하기 위해 주입할 때 컴포넌트 스캔 결과, ConflictingBeanDefinitionException이 뜨게 되겠네요.) --- 앗. 질문이 잘못된 부분이 있어서 수정했습니다.
-
미해결스프링 핵심 원리 - 기본편
isInstanceOf
안녕하세요!구글 검색을 해봐도 명확한 답을 찾기가 어려워 질문을 남깁니다.assertThat(bean).isInstanceOf(RateDiscountPolicy.class); 처럼 검증을 할 때isInstanceOf가 어떻게 동작을 하는건지 잘 모르겠습니다.assertThat(bean).isInstanceOf(DiscountPolicy.class); 해도 테스트 통과를 하더라구요 답변 부탁드립니다. 감사합니다.
-
미해결스프링 핵심 원리 - 기본편
빈 라이프 싸이클과 PostConstruct, PreConstruct 질문입니다.
1. 스프링빈은 객체를 생성한다.2. 의존관계 주입을 한다.3. 이후 필요한 데이터를 사용 할 수 있는 준비가 된다. 강의 듣다가 명확하게 이해하고 싶어서 질문드립니다. 의존관계 주입후 필요한 데이터를 사용 할 수 있는 준비가 된다고 하는데 그렇다면 생성자로 모든 데이터와 DB 커넥션을 해주는 작업을 한다면 의존관계주입이 발생될때 해당 초기화 했던 작업들은 다 무시가 되나요?
-
미해결스프링 핵심 원리 - 기본편
getBeanDefinition
ApplicationContext말고 구체화된 클래스(예: AnnotationConfigApplicationContext)를 쓰는 이유가 getBeanDefinition을 쓸 수 없어서라고 하셨는데, 그 이유가 무엇인가요? AnnotationConfigApplicationContext가 구현한 여러가지 인터페이스중, ApplicationContext가 아닌 다른 인터페이스가 getBeanDefinition이라는 메서드를 제공하기 때문이라는 말씀이신가요?
-
미해결스프링 핵심 원리 - 기본편
의존관계 주입 시점
IoC, DI, 그리고 커네이너 강의 질문입니다. DI 설명 중 주입은 런타임 시라고 되어있는데 컴파일 시점 아닌가요?? 컴파일 시점에 이미 다 주입이 되고, 런타임에는 주입된 것을 사용한다고 생각하는데 이해가 좀 안되어서요 ㅜ.ㅜ 컴파일 시점에는 주입은 일어나지 않고, 스프링을 빌드(런타임)할 때, 주입이 일어난다는 의미 일까요??
-
미해결스프링 핵심 원리 - 기본편
혹시 지금까지 제가 이해한 내용이 올바른건지 궁금합니다
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://docs.google.com/document/d/1j0jcJ9EoXMGzwAA2H0b9TOvRtpwlxI5Dtn3sRtuXQas/edit#heading=h.w2tomwsznga7)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://docs.google.com/document/d/1xCQKit-1V6l6ObeCe49St33RHPzLF_P_c3o7aSDTKs0/edit#heading=h.7dhnp46ven0v)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용] 💡 DI (Dependency Injection) - 의존관계 주입 의존하는 객체를 직접 생성하는 것이 아니라, 외부에서 생성한 후 주입하는 것. 3가지 조건이 필요 클래스 모델이나 코드에는 런타임(실행) 시점의 의존관계가 드러나지 않는다. (= 정적인 클래스 의존관계가 아니다)(= 동적인 객체 인스턴스 의존관계이다) => 인터페이스에만 의존하고 있어야 한다 런타임 시점의 의존관계는 외부에서 결정한다 외부에서 실제 구현 객체(사용할 오브젝트에 대한 레퍼런스)를 생성하고 클라이언트(사용할 오브젝트)에 전달(주입)함으로써 의존관계가 연결되는 것이다 예를 들어 private Car myCar = new 벤츠(); => Car가 인터페이스고 벤츠가 구현 객체라면, 런타임 이전에, 즉 코드상으로 벤츠 클래스를 의존하는 것을 알 수 있다 private Car myCar; => 이러면 Car에 대해 무슨 차가 들어올지 알 수 없다.(런타임 시점의 의존관계가 드러나지 않으므로) => 즉 이렇게 인터페이스에만 의존하고 의존관계 주입이 발생할 수 있다. 💡 IoC (Inversion of Control) - 제어의 역전 프로그램의 제어 흐름(ex:메소드나 객체의 호출작업)을 개발자가 결정하는 것이 아니라, 외부에서 결정(관리)하는 것. 즉 객체를 개발자가 Member member = new Member(); 이런식으로 만드는 것이 아니라, 스프링이 스스로 객체를 생성해서, 필요한 곳에 사용할 수 있게 해줌! 1 AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class); cs 위 코드 단 하나만 실행했을 뿐인데, 우리는 ac.getBean을 통해, 원하는 객체를 사용할 수 있음!!!!! 참고로 DI도 제어의 역전에 포함되는 기술이며, IoC는 좀더 광범위하게 쓰인다! 🧾 부분 정리 스프링은 IoC, DI와 같은 기술을 사용함으로써 자바만으로는 DIP(의존관계 역전 원칙)와 OCP(계방-폐쇠 원칙)을 지켜가며 객체지향적으로 설계하는데 어려움이 있었는데, 이를 해결. 즉 스프링을 사용하면 좋은 객체 지향 애플리케이션을 개발하기 편해지며, 스프링은 이를 도와주는 프레임워크. 스프링이 좋은 객체 지향 애플리케이션을 개발하는데 도움을 주는 프레임워크인 것 처럼, 스프링 부트는 스프링의 기술들을 좀 더 편리하게 사용하는데 도움을 주는 프레임워크. 제가 정리한 내용들인데, 혹시 맞게 이해한건지요.. 너무 어려워서 여러차례 강의 반복하여 들으며 정리했습니다
-
미해결스프링 핵심 원리 - 기본편
@Component는 구현체에만 붙인다?
인터페이스에는 안붙이고 구현체에만 @Component를 붙이는 이유는뭔가요?
-
미해결스프링 핵심 원리 - 기본편
rateDiscountPolicy를 DiscountPolicy타입으로하는게 좋다
TestConfig에서 rateDiscountPolicy이 DiscountPolicy타입인데 다른데서 의존할때도 DiscountPolicy에 의존하고 있으니까 DiscountPolicy타입으로 하는게 좋다라고 하셨는데 그게 무슨말인지 잘 모르겠어요.. 예를들어서 설명해주실 수 있나요....?
-
미해결스프링 핵심 원리 - 기본편
질문입니다.
1. InitializingBean와 DisposableBean "개발자가 코드를 고칠 수 없는 외부 라이브러리에는 적용할 수 없다."라고 설명하셨습니다. 외부 라이브러리의 코드를 제가 직접 고칠 수 없는 건 알겠는데, 그렇기 때문에 해당 메소드를 적용할 수 없는 이유를 좀 더 상세하게 알려주시면 감사하겠습니다. 2. initMethod와 destroyMethod "코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 해당 메소드를 사용할 수 있다."라고 설명하셨습니다. 여기서 해당 기능이 설정 정보를 사용한다는 말의 뜻과 그렇기 때문에 외부 라이브러리에서 사용할 수 있는 이유를 좀 더 상세하게 알려주시면 감사하겠습니다.
-
해결됨스프링 핵심 원리 - 기본편
자동 빈 등록과 수동 빈 등록
안녕하세요. 간단한 질문인데요. 자동 빈 등록과 수동 빈 등록의 범위가 궁금합니다. 컴포넌트 스캔을 통해 컴포넌트 어노테이션이 붙은 객체들을 자동으로 등록하는 것을 자동 빈 등록이라고 한다면, 그 외 모든 빈 등록은 수동 빈 등록이라고 볼 수 있을까요? 그렇다면, 기술 지원 객체의 경우는 수동 빈 등록을 추천해주셨는데, 따로 강의 초반에 만드신 @Configuration과 @Bean으로만 구성된 AppConfig와 같은 Class를 만들어 구현하는 것으로 이해하는게 맞을까요?
-
미해결스프링 핵심 원리 - 기본편
생성자 주입 방법과 setter 주입 방법에 대한 질문
생성자 주입 방법은 필수, 변경 가능성이 없는 경우에 사용된다고 하셨고, setter 주입 방법은 선택, 변경 가능성이 있는 경우에 사용된다고 하셨습니다. 여기에서 '필수/선택'과 '변경 가능성'이 무슨 뜻인지 잘 모르겠습니다. 좀 더 상세한 설명 부탁드립니다.