스프링

ApplicationContext를 스프링 컨테이너라 한다.기존에는 스프링을 쓰지않고는 개발자가 AppConfig(딱히 의미가 있는 이름은 아니다. 그냥 파일명일뿐..)를 사용해서 객체를 생성하고 DI를 했지만, 스프링을 이용하면 위의 스프링 컨테이너를 통해서 빈을 가

스프링 컨테이너는 싱글톤 패턴을 따로 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.스프링 컨테이너는 싱글톤 컨테이너 역할을 한다.스프링 컨테이너 덕분에 싱글톤 패턴의 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.싱글톤 패턴을 위한 지저분한 코드가 필요없

@ComponentScan 어노테이션이 붙으면 해당 클래스는 컴포넌트 스캔의 대상이 된다. @Configuration도 마찬가지로 내부에 ComponentScan 어노테이션을 포함하였기 때문에 컴포넌트 스캔의 대상이 되었다.이러한 컴포넌트 스캔이 붙은 클래스는 @Com

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 빈 사용 -> 소멸 전 콜백 -> 스프링 종료초기화 콜백 : 빈이 생성되고, 의존관계까지 모두 주입됐을 때 실행소멸 전 콜백 : 빈이 소멸되기 직전에 호출인터페이스(Initializi

서블릿과 JSP의 한계 서블릿으로 개발할 때는 뷰(View) 화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다. 이러한 문제를 JSP를 사용함으로써 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고 동적으로 변경이 필요한 부분에만 자바 코드를

Dynamic Proxy는 Proxy Factory에 의해 Runtime시 만들어지는 오브젝트이다.Proxy Factory에게 Interface 정보만 제공해주면 해당 Interface를 구현한 클래스의 오브젝트를 자동으로 만들어준다.Dynamic Proxy가 Inte