본문 바로가기

Happyer16

(314)
1.1-IoC 컨테이너 : 빈 팩토리와 애플리케이션 컨텍스트 IoC 컨테이너 : 빈 팩토리와 애플리케이션 컨텍스트스프링의 핵심 개념 중 하나인 IoC 컨테이너와 DI 기술에 대해 살펴보자. 스프링 애플리케이션에서는 객체의 생성, 사용, 제거, 관계설정 등을 애플리케이션 코드 대신 독립된 컨테이너가 담당한다. 코드 대신 객체에 대한 제어권을 갖고 있다고 해서 IoC(제어의 역전)이라 부른다. IoC 컨테이너 = 빈 팩토리 또는 애플리케이션 컨텍스트빈 팩토리 : 객체의 생성과 객체 사이의 런타임 관계를 설정하는 DI 시점에서는 빈팩토리라 함애플리케이션 컨텍스트 : 앤터프라이즈 애플리케이션을 개발하는데 필요한 몇가지 기능이 추가된 것 public interface ApplicationContext extends EnvironmentCapable, ListableBean..
Logback 아키텍처 Logback 아키텍처Logback 아키텍처는 다른 환경에도 적용할 수 있도록 아주 일반적으로 설계되어 있다. logback은logback-core : 다른 두 모듈의 기본이다.logback-classic : logback-core를 extend 하였다. log4j을 개선한 것이다. SLF4J API를 기본적으로 구현하여 JDK 1.4에 소개된 log4j 또는 java.util.logging과 같은 다른 로깅 시스템과 로그백간에 쉽게 전환을 할 수 있다.logback-access : 서블릿 컨테이노와 통합되어 HTTP-access 로그 기능을 제공한다.Logback 아키텍처의 기본 요소들에 좀더 자세히 알아보자. Logback 아키텍처 - Logger, Appenders, Layouts Logback 아..
2.logback Appender란 logback-Appender란Logback은 Logging 쓰기를 Appender에게 위임한다. Appender는 아래의 interface의 구현체이다. package ch.qos.logback.core; import ch.qos.logback.core.spi.ContextAware; import ch.qos.logback.core.spi.FilterAttachable; import ch.qos.logback.core.spi.LifeCycle; public interface Appender extends LifeCycle, ContextAware, FilterAttachable { public String getName(); public void setName(String name); void doAp..
Clean Code 9장 - 단위테스트 Clean Code - 단위테스트실제 코드를 작성하기 전에 단위 테스트를 작성하라첫번째 법칙 : 실패하는 단위 테스트를 작성하기 전에 실제 코드를 작성하지 않는다.두번째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.세번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 코드를 작성한다. 위의 법칙대로 작성을 하면 테스트 코드와 실제 코드가 빠른 주기로 묶인다. 이렇게 되면, 실제 코드와 맞먹는 정도의 방대한 테스트 코드가 나와 심각한 관리 문제가 생긴다. 깨끗한 테스트 코드 유지하기테스트 코드는 메인 코드와 다르게 대충 짜도 된다는 의식을 많이 가지고 있다. 테스트 코드를 대충 짜면 어떠한 문제가 생길까?메인 코드 버전업 -> 테스트 실패테스트 코드를 수정해야 하지만..
Spring IoC(제어의역전),DI(의존성주입)란? Spring IoC(제어의역전),DI(의존성주입)란?Spring으로 코딩하면서 IoC와 DI에 대한 용어를 자주 접하게 된다. @Autowired, @Bean 어노테이션 덕분에 객체 생성과 설정에 대한 걱정없이 우리는 편하게 작업을 해왔다. 하지만, 내부적으로 Spring Framework가 어떻게 돌아가는지 @Autowired,@Bean 어노테이션을 통해 얻는 장점이 무엇인지 제대로 공부하지 않았다. 이번 포스팅을 통해 Spring IoC,DI에 대해 제대로 알아보려 한다. 1. @Bean,@Component,@Service,@Controller,@Repository 도대체 뭐임?@Bean, @Component에 대해 알아보자.두가지 어노테이션은 스프링에 빈을 등록하기 위해 사용되는 어노테이션이다. @..
Gradle 이슈 모음 There is insufficient memory for the Java Runtime Environment to continuegradle test를 동작시키니 해당 에러가 발생하였다. gradle이 동작하는 JVM memory 이슈인 줄 알았으나, OS 단의 문제였다. 예를 들어, JVM은 224MB를 할당하려 하는데, OS단에서는 해당 메모리만큼 사용이 가능하지 않은 경우이다. 즉, JVM에 설정된 -Xmx >> 시스템의 free memory 인 경우이다. 해결 방법s1. EC2 instance memory 늘리기2. OS의 free memory와 JVM의 memory 설정을 확인하여 수정하기 ~# jps -lvm4466 org.gradle.launcher.daemon.bootstrap.Gradl..
POJO(plain old java object)란? POJO(Plain old java object)란 무엇인가?스프링 개발을 하면서 POJO 프로그래밍이라는 용어를 자주 접한다. 이제까지 느낌적으로 특정 규약에 종속되지 않는 자바 객체 정도로 이해해왔다. 이 포스팅에서 POJO의 조건과 POJO 프로그래밍의 장점에 대해 예시를 통해 알아볼 것이다. POJO 개념을 사용하지 않은 예시 ( 특정 환경에 결합도가 높은 코드 ) JMS로부터 메시지를 받는 경우JMS를 사용하기 위해 MessageListener 인터페이스를 상속받아야 한다. 하지만, 다음과 같이 구현하면 JMS라는 특정 환경에 종속되게 되고 다른 메시징 솔루션을 적용하기 어려워 진다. 단순한 예제와 달리 Listener가 많은 경우, AMQP나 다른 솔루션으로 교체할 경우 더더욱 어려울 것이다...
스프링 공부방법 스프링 공부방법스프링을 사용할 때 우리는 원리에 대한 이해보다 단순 예제를 보고 바로 구현에 들어갔을 것이다. 하지만 스프링의 가치를 제대로 느끼며 사용하려면 스프링을 제대로 공부해야 한다. 그렇다면 제대로 공부하는게 무엇일까? 1. 스프링을 왜 사용하고 어떠한 원리인지 이해하기스프링이 주는 3가지 핵심 기술에 대한 이해와 스프링이 강조하는 프로그래밍 모델에 대한 이해가 우선이 되어야 한다. 2. 스프링 기술에 대한 지식과 선택 기준 정립스프링의 기본원리를 확실하게 이해하고 나면 스프링이 이를 어떻게 다양한 방법으로 확장하고 적용했는지 살펴보아야 한다. 스프링은 매우 폭넓은 접근 방법을 제공하기에 개발자가 어떤 것을 선택할지 정해야 한다. 3. 스프링의 적용과 확장스프링은 특정 아키텍처에 제한되는 프레임..
Clean Code 12장 - 우수한 설계를 위한 규칙(창발성) 우수한 설계를 위한 규칙켄트 백이 제시한 다음 규칙을 따르면 설계는 '단순하다'고 우리는 믿고 있다. 모든 테스트를 실행한다.중복을 없앤다.프로그래머의 의도를 표현한다.클래스와 메소드 수를 최소로 줄인다.이 순서는 중요도 순이다! 하나하나씩 살펴보자~우수한 설계를 위한 규칙 1 - 모든 테스트를 실행한다.모든 테스트를 실행한다가 왜 우수한 설계를 위한 규칙일까? 모든 테스트 케이스를 만들려면 결합도가 높아서는 안된다. 한 클래스 함수에서 하나 이상의 책임을 가지고 있으면 테스트 케이스를 만들기 어려워진다. 그러면 자연스럽게 단일 책임 원칙을 지키게 된다. 또한, 다른 클래스와 결합도가 높으면 테스트가 힘들어지기 때문에 자연스럽게 의존성 주입을 사용하게 된다. 결국, 테스트 케이스를 모두 실행 시키다보면 ..
Spring Boot와 Docker를 이용한 개발환경 구축하기 Spring Boot와 Docker를 이용한 개발환경 구축하기내가 겪은 문제점 - Development 환경과 Staging,Prod 환경의 차이로 인한 문제 발생Spring Boot 개발을 하다보면, Development 환경과 Prod 환경이 달라서 문제가 발생하는 경우가 있다. Service Discovery 역할을 하는 Eureka Server를 구축하면서 이 문제를 겪었다. Prod 환경에서의 Eureka 설정은 AWS config이고, Dev 환경에서의 Eureka 설정은 Local이기 때문에 개발 시점에서는 테스트를 해볼 수가 없었다. Twelve-Factor 방법론 중 Development/Production 환경을 최대한 비슷하게 하라는 얘기가 있다. 내가 겪은 문제점 2 - Remote..