0228 - 0313

0303 - Jackson - 다형성 관련 애노테이션

Jackson에서는 다형성 처리를 위해 세가지 애노테이션을 사용한다.

• @JsonTypeInfo : 직렬화시 포함할 타입 정보의 세부 사항을 나타낸다.
• @JsonSubTypes : 애노테이션이 달린 타입의 하위 타입을 지정한다.
• @JsonTypeName : 애노테이션이 달린 타입의 논리적 이름을 지정한다.

예시

public class Zoo {
    public Animal animal;

    public Zoo(Animal animal) {
        this.animal = animal;
    }

    @JsonTypeInfo(
            use = JsonTypeInfo.Id.NAME,
            include = JsonTypeInfo.As.PROPERTY,
            property = "type")
    @JsonSubTypes({
            @JsonSubTypes.Type(value = Dog.class, name = "dog"),
            @JsonSubTypes.Type(value = Cat.class, name = "cat")
    })
    public static class Animal {
        public String name;
    }

    @JsonTypeName("dog")
    public static class Dog extends Animal {
        public double barkVolume;

        public Dog(String name) {
            super.name = name;
        }
    }

    @JsonTypeName("cat")
    public static class Cat extends Animal {
        public int lives;
        boolean likesCream;
    }
}

public class PolymorphicTests {
    @Test
    public void WhenPolymorphicBeanProvided_ThenSerialize_ExpectCorrect() throws JsonProcessingException {
        // when
        Zoo.Dog dog = new Zoo.Dog("lacy");
        Zoo zoo = new Zoo(dog);

        // then
        String json = new ObjectMapper().writeValueAsString(zoo);

        // expected
        System.out.println(json);
        assertThat(json, containsString("type"));
        assertThat(json, containsString("dog"));
    }
}

0307 - JDK Dynamic Proxy와 CGLIB

Spring AOP가 제공하는 두 가지 AOP Proxy

Spring AOP는 프록시 기반으로 JDK Dynamic Proxy와 CGLIB을 활용하여 AOP를 제공한다

IoC 컨테이너와 AOP Proxy의 관계

먼저 Spring AOP는 Proxy의 메커니즘을 기반으로 AOP Proxy를 제공한다

다음 그림처럼 Spring AOP는 사용자의 특정 호출 시점에 IoC 컨테이너에 의해 AOP를 할 수 있는 Proxy Bean을 생성해준다. 동적으로 생성된 Proxy Bean은 타깃의 메소드가 호출되는 시점에 부가기능을 추가할 메소드를 자체적으로 판단하고 가로채어 부가기능을 주입하는데, 이처럼 호출 시점에 동적으로 위빙을 한다 하여 런타임 위빙(Runtime Weaving)이라 한다.

따라서 Spring AOP는 런타임 위빙의 방식을 기반으로 하고 있으며, Spring에선 런타임 위빙을 할 수 있도록 상황에 따라 JDK Dynamic Proxy와 CGLIB 방식을 통해 Proxy Bean을 생성을 해준다.

두 가지 AOP Proxy는 어떠한 상황에 생성하게 되나

Spring은 AOP Proxy를 생성하는 과정에서 자체 검증 로직을 통해 다깃의 인터페이스 유무를 판단한다.

Target이란 횡단기능(Advice)이 적용될 객체(Object)를 뜻한다.

이때 만약 타깃이 하나 이상의 인터페이스를 구현하고 있는 클래스라면 JDK Dynamic Proxy의 방식으로 생성되고 인터페이스를 구현하지 않은 클래스라면 CGLIB의 방식으로 AOP Proxy를 생성한다

Spring AOP의 근간이 되는 JDK Dynamic Proxy 방식

우선 JDK Dynamic Proxy란 Java의 리플렉션 패키지에 존재하는 Proxy라는 클래스를 통해 생성된 Proxy 객체를 의미한다. 리플랙션의 Proxy 클래스가 동적으로 Proxy를 생성해준다하여 JDK Dynamic Proxy라 부른다. 이 클래스를 사용하여 프록시를 생성하기 위해선 몇가지 조건이 있지만, 그 중 핵심은 타깃의 인터페이스를 기준으로 Proxy를 생성해준다는 점이다

무엇보다 Spring AOP는 JDK Dynamic Proxy를 기반으로 AOP 기술을 구현했을 만큼, JDK Dynamic Proxy가 어떻게 Proxy를 생성하는지에 대한 부분은 Spring AOP를 통해 Aspect를 구현한다면 중요한 부분이다.

JDK Dynamic Proxy의 Proxy

먼저 JDK Dynamic Proxy를 사용하여 Proxy 객체를 생성하는 방법은 간단하다

Object proxy = Proxy.newProxyInstance(ClassLoader       // 클래스로더
                                    , Class<?>[]        // 타깃의 인터페이스
                                    , InvocationHandler // 타깃의 정보가 포함된 Handler
              										  );

단순히 리플랙션의 Proxy 클래스의 newProxyInstance 메소드를 사용하면 된다. JDK Dynamic Proxy가 이 파라미터를 가지고 Proxy 객체를 생성해주는 과정은 다음과 같다

1. 타깃의 인터페이스를 자체적인 검증 로직을 통해 ProxyFactory에 의해 타깃의 인터페이스를 상속한 Proxy 객체 생성
2. Proxy 객체에 InvocationHandler를 포함시켜 하나의 객체로 반환

다음과 같이 Proxy를 생성하는 과정에서 핵심적인 부분은, 무엇보다 인터페이스를 기준으로 Proxy 객체를 생성해준다는 점이다. 따라서 구현체는 인터페이스를 상속받아야하고, @Autowired를 통해 생성된 Proxy Bean을 사용하기 위해선 반드시 인터페이스의 타입으로 지정해줘야 한다.

이러한 Proxy의 구조를 이해하지 못한다면 다음과 같은 상황이 벌어질 수 있다.

@Controller
public class UserController{
  @Autowired
  private MemberService memberService; // <- Runtime Error 발생...
  ...
}

@Service
public class MemberService implements UserService{
  @Override
  public Map<String, Object> findUserId(Map<String, Object> params){
    ...isLogic
    return params;
  }
}

MemberService 클래스는 인터페이스를 상속받고 있기 때문에 Spring은 JDK Dynamic Proxy 방식으로 Proxy Bean을 생성해준다. 다음과 같은 코드를 실행하면 런타임 입셉션이 발생한다. 여기서 런타임에러가 발생되는 부부은 @Autowired MemberService memberService 부분이다.

JDK Dynamic Proxy는 인터페이스 타입으로 DI를 받아줘야 하기 때문에, @Autowired private UserService로 형식을 구성해줘야 한다.

인터페이스 기준 그리고 내부적인 검증 코드

다른 관점에서 보자면 JDK Dynamic Proxy는 Proxy 패턴의 관점을 구현한 구현체라 할 수 있다.

이 Proxy 패턴은 접근제어의 목적으로 Proxy를 구성한다는 점ㅇ도 중요하지만, 무엇보다 사용자의 요청이 기존의 타깃을 그대로 바라볼 수 있도록 타깃에 대한 위임코드 Proxy 객체에 작성해줘야 한다. 생성된 Proxy 객체의 타깃에 대한 위임코드는 바로 InvocationHAndler에 작성해줘야 한다.

따라서 사용자의 요청이 최종적으로 생성된 Proxy의 메소드를 통해 호출할 때 내부적으로 invoke에 대한 검증과정이 이뤄진다. 결과적으로 코드는 다음과 같다.

public Object invoke(Object proxy, Method proxyMethod, Object[] args) throws Throwable {
  Method targetMethod = null;
  // 주입된 타깃 객체에 대한 검증 코드
  if (!cachedMethodMap.containsKey(proxyMethod)) {
    targetMethod = target.getClass().getMethod(proxyMethod.getName(), proxyMethod.getParameterTypes());
    cachedMethodMap.put(proxyMethod, targetMethod);
  } else {
    targetMethod = cachedMethodMap.get(proxyMethod);
  }

  // 타깃의 메소드 실행
  Ojbect retVal = targetMethod.invoke(target, args);
  return retVal;
}

이 과정에서 검증과정이 이뤄지는 까닭은 다름아닌 Proxy가 기본적으로 인터페이스에 대한 Proxy만을 생성해주기 때문이다. 따라서 개발자가 타깃에 대한 정보를 잘 못 주입할 경우 대비하여 JDK Dynamic Proxy는 내부적으로 주입된 타깃에 대한 검증코드를 형성하고 있다.

CGLib(Code Generator Library)

CGLib은 Code Generator Library의 약자로, 클래스의 바이트코드를 조작하여 Proxy 객체를 생성해주는 라이브러리이다.

Spring은 CGLib을 사용하여 인터페이스가 아닌 타깃의 클래스에 대해서도 Proxy를 생성해준다. CGLib은 Enhancer라는 클래스를 통해 Proxy를 생성할 수 있다.

Enhancer enhancer = new Enhancer();
         enhancer.setSuperclass(MemberService.class); // 타깃 클래스
         enhancer.setCallback(MethodInterceptor);     // Handler
Object proxy = enhancer.create(); // Proxy 생성

다음과 같이 CGLib은 타깃의 클래스를 상속받아 Proxy를 생성한다. 이 과정에서 CGLib은 타깃 클래스에 포함된 모든 메소드를 재정의하여 Proxy를 생성해준다.
이 때문에 CGLib은 Final 메소드 또는 클래스에 대해 재정의를 할 수 없으므로 Proxy를 생성할 수 없다는 단점이 있지만, CGLib은 바이트 코드로 조작하여 Proxy를 생성해주기 때문에 성능에 대한 부분이 JDK Dynamic Proxy보다 좋다.

invoke의 차이, 성능의 차이

성능의 차이의 근본적인 이유는 CGLib은 타깃에 대한 정보를 제공 받기 때문이다.

따라서 CGLib은 제공받은 타깃 클래스에 대한 바이트 코드를 조작하여 Proxy를 생성하기 때문에, Handler안에서 타깃의 메소드를 호출할 때 다음과 같은 코드가 형성된다.

public Object invoke(Object proxy, Method proxyMethod, Object[] args) throws Throwable {
  Method targetMethod = target.getClass().getMethod(proxyMethod.getName(), proxyMethod.getParameterTypes());
  Ojbect retVal = targetMethod.invoke(target, args);
  return retVal;
}

1. 메소드가 처음 호출되었을 때 동적으로 타깃의 클래스의 바이트 코드를 조작
2. 이후 호출시엔 조작된 바이트 코드를 재사용

CGLib은 성능이 좋긴하지만, Spring은 JDK Dynamic Proxy를 기반으로 Proxy를 생성해주고 있다. 하지만 어느 어느 시점 부터 Spring Boot에선 문제가 되었던 부분들이 개선되어 안정화가 되었기 때문에 CGLib을 방식으로 Proxy를 생성해주고 있다.

0308 - 리플렉션 API (Reflection API)

리플렉션 API란?

• 구체적인 클래스 타입을 알지 못해도 그 클래스의 정보(메서드. 타입, 변수 등등)에 접근할 수 있게 해주는 자바 API이다.
• 리플렉션 API는 자바 코드를 통해 로드된 클래스의 필드/메서드/생성자를 찾을 수 있게 지원한다.
• 또한 클래스의 접근 제한자와 상관없이 클래스의 필드/메서드/생성자를 사용할 수 있게 지원한다.

힙 영역에 로드된 Class 타입의 객체를 통해, 원하는 클래스의 인스턴스를 생성할 수 있게 지원하고, 인스턴스의 필드와 메서드를 접근 제어자와 상관없이 사용할 수 있도록 지원하는 API.

클래스의 정보 조회

1. 직접 선언

Class<Book> bookClass = Book.class;

2. 인스턴스를 이용한 getClass() 메소드

Book book = new Book();
Class<? extends Book> bookClassFromInstance = book.getClass();

3. Class.forName() 메소드

try {
	//주로 JDBC 예제에서 많이 봄
	Class<?> bookClassFromPackageString = Class.forName("org.example.Book");
} catch (ClassNotFoundException e) {
	e.printStackTrace();
}

Class<?> 타입을 이용한 클래스 정보 조회

필드 정보 조회

• (Field[]) getFields() : 클래스에 선언된 필드들 반환(public 접근지시자만)
• (Field) getField(String name) : name에 해당하는 필드를 반환(없다면 NoSuchFieldException)
• (Field[]) getDeclaredFields() : 클래스에 선언된 모든 필드들 반환(private 까지도 포함)
• (Field) getDeclaredField(String name) : name에 해당하는 필드를 반환(없으면 NoSuchFieldEception, priavte 포함)

메소드 접근

Method[] methods = bookClass.getMethods();
Arrays.stream(methods).forEach(System.out::println); //Object 상속 메소드 포함.

생성자 접근

Constructor[] constructors = bookClass.getConstructors();
Arrays.stream(constructors).forEach(System.out::println);

부모클래스 접근

Class<? super MyBook> superClass = MyBook.class.getSuperclass();
System.out.println(superClass);

인터페이스 접근

Class<?>[] implementsInterface = MyBook.class.getInterfaces();
Arrays.stream(implementsInterface).forEach(System.out::println);

리플렉션 API 사용이유

캡슐화와 은닉성을 무시하면서도 사용하는 이유는, 런타임에 비로소 객체가 생성되어야 할 필요성이 있기 때문인다.

0309 - QueryDSL 기본 사용법

• QueryDSL은 HQL(Hibernate Query Language) 쿼리를 타입에 안전하게 생성 및 관리할 수 있게 해주는 프레임워크다.
• 자바 코드 기반으로 쿼리를 작성하게 도와준다.

QueryDSL 예제

gradle 설정

plugins {
    // ...
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" // 추가
    // ...
}

// ...

dependencies {
    // ...
    implementation 'com.querydsl:querydsl-jpa' // 추가
    // ...
}

// ...

// queryDSL이 생성하는 QClass 경로 설정
def querydslDir = "$buildDir/generated/querydsl"

querydsl {
    jpa = true
    querydslSourcesDir = querydslDir
}

sourceSets {
    main.java.srcDir querydslDir
}

configurations {
    querydsl.extendsFrom compileClasspath
}

compileQuerydsl {
    options.annotationProcessorPath = configurations.querydsl
}

Q클래스 만들기

Tasks -> other -> compileJava 실행시 지정해둔 build/지정경로에 Q클래스가 생성

Config 설정

@Configuration
public class QueryDSLConfig {

    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

기본 사용법

1. Post 엔티티

@Entity
public class Post {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String title;

    @Column(nullable = false)
    private String content;

    // ...
}

2. PostRepository

public interface PostRepository extends JpaRepository<Post, Long> {
}

3. PostRepositorySupport

@Repository
public class PostRepositorySupport extends QuerydslRepositorySupport {

    private final JPAQueryFactory jpaQueryFactory;

    public PostRepositorySupport(final JPAQueryFactory jpaQueryFactory) {
        super(Post.class);
        this.jpaQueryFactory = jpaQueryFactory;
    }

    public List<Post> findByTitle(final String title) {
        return jpaQueryFactory.selectFrom(post)
                .where(post.title.eq(title))
                .fetch();
    }
}

• 이떄 selectFrom(post)의 post는 아까 만든 Q클래스에서 사용한다

Spring Data Jpa Custom Repository 적용 사용법

위와 같이 사용하면 항상 2개의 Repository(QueryDSL의 Custom Repository, JpaRepository를 상속한 Repository)를 의존성으로 받아야한다.

1. CustomizedPostRepository

public interface CustomizedPostRepository {
    List<Post> findByTitle(final String title);
}

2. CustomizedPostRepositoryImpl

public class CustomizedPostRepositoryImpl implements CustomizedPostRepository {

    private final JPAQueryFactory jpaQueryFactory;

    private CustomizedPostRepositoryImpl(final JPAQueryFactory jpaQueryFactory) {
        this.jpaQueryFactory = jpaQueryFactory;
    }

    @Override
    public List<Post> findByTitle(final String title) {
        return jpaQueryFactory.selectFrom(post)
                .where(post.title.eq(title))
                .fetch();
    }
}

3. PostRepository

public interface PostRepository extends JpaRepository<Post, Long>, CustomizedPostRepository {
}

이렇게 구성하면 CustomizedPostRepositoryImpl의 코드를 사용할 수 있다. PostRepository는 어떻게 CustomizedPostRepository를 상속받아서 CustomizedPostRepositoryImpl의 코드를 사용할 수 있을까?

Spring 공식문서를 보면 커스텀한 Repostory는 별도의 설정을 하지 않았다면 ~Impl접미사를 붙여야만 스프링이 찾을 수 있다. 관련해서는 spring-data에 포함된 RepositoryConfigurationSourceSupport클래스와 AnnotationRepositoryConfigurationSource클래스의 내부 코드를 보면 알 수 있다.

The most important part of the class name that corresponds to the fragment interface is the Impl postfix.

0310 - OpenAPI와 Swagger/redoc란

OpenAPI Spec

OpenAPI Specification(OAS)은 RESTful API를 기술하는 표준으로 서비스에서 제공하는 API의 기능과 End Point를 개발자나 시스템이 자동으로 발견하고 처리하는데 필요한 정보를 제공한다.

OAS는 json이나 yml형식으로 기술해야 하며 OAS파일을 읽어서 디플로이 해주는 도구(ex. swagger-ui)를 사용하면 브라우저에서 편리하게 API 문서를 볼 수 있다.

OAS는 예전에는 Swagger spec으로 불렸으며 3.0 부터 OpenAPI 3.0 Specification (opens new window)라는 이름으로 표준화 되었다

Swagger

Swagger는 OpenAPI Spec에 맞게 디자인하고 문서화하고 빌드하기 위한 도구들의 모음으로 다음과 같은 구성요소로 이루어져 있다.

• Swagger Editor - 브라우저 기반의 편집기로 OpenAPI spec을 쉽게 작성할 수 있도록 도와준다.
• Swagger UI - OpenAPI spec문서를 디플로이하고 브라우저에서 예쁘게 표시할 수 있도록 해준다. swagger-ui와 비슷한 라이브러리로 redoc이 있다.
• Swagger Codegen - OpenAPI spec에 맞게 서버나 클라이언트의 stub code를 생성해준다. 개발자는 생성된 코드에 비즈니스 로직에 집중해서 구현하면 된다.

Redoc

redoc (opens new window)은 OpenAPI spec 파일을 읽어서 디플로이해주는 도구로 Swagger-UI와 비슷한 역할을 수행한다.

설치와 사용이 아주 간편한 장점이 있지만 swagger-ui랑 달리 브라우저에서 API 테스트 기능을 해볼수는 없다는 단점이 있다.

0311 - 자바 로그 프레임워크

로그 시스템

로그 시스템은 소프트웨어의 이벤트를 기록 함으로써, 소프트 웨어 동작 상태를 파악하고 문제가 발생했을때 이 동작 파악을 위해서 소프트웨어의 문제를 찾아내고 해결하기 위해서 디자인 되었다.
주로 로그 파일이라는 형태로 하나의 파일에 이벤트들을 기록하였다.

그러나 소프트웨어 스택이 OS, 미들웨어, 사용자 어플리케이션(자바나 파이썬등으로 구현된 애플리케이션)으로 점점 다중화되고 시스템이 대형화 되면서 한대가 아니라 여러대의 서버에 로그를 기록하고 또한 마이크로 서비스 아키텍처로 인하여 서버 컴포넌트가 분산됨에 따라서 로그를 수집해야할 포인트가 많아지게 되었따. 이로 인해서 로그 시스템이 분산 환경을 지원해야 할 필요가 되었고, 단순히 파일로 로그를 기록하는 것만으로는 이러한 여러시스템과 다중 계층에 대한 모니터링이 불가능하게 되었다.

또한 데이터 분석의 중요성이 대두됨에 따라서, 에러등의 동작 파아성의 로그 뿐만 아니라 사용자의 앤티비티를 수집하여 데이터 분석에 사용하기 위해서 데이터 수집 역시 로그 시스템을 통하기 시작했다.

좋은 로그 시스템

• 로그 메시지는 애플리케이션의 동작을 잘 이해할 수 있도록 충분히 구체적이어야 한다.
• 로그 메시지를 기록하는데 성능 저하가 없어야 한다.
• 어떠한 배포 환경이라도 로그를 수집하고 저장할 수 있도록 충분히 유연해야 한다. (분산 환경 지원, 대용량 데이타 지원등..)

자바 로깅 프레임워크

자바는 역사가 오래된 만큼 많은 로깅 프레임웍을 가지고 있다. log4j, logback, log4j2, apache common logging, SLF4J 등 다양한 프레임워크들이 있다.

SLF4J

SLF4J는 (Simple Logging Facade for Java)의 약자로 이름이 뜻하는 것과 같이 로깅에 대한 Facade 패턴이다. SLF4J는 자체가 로깅 프레임워크가 아니라, 다양한 로깅 프레임워크를 같은 API를 사용해서 접근할 수 있도록 해주는 추상화 계층이다. 그래서 다른 로그 프레임워크와 같이 사용해야 하는데, 보통 Log4J, Logback, Log4J2등이 많이 사용된다. 즉 애플리케이션은 SLF4J API 인터페이스를 통해서 호출하지만, 실제로 호출되는 로깅 프레임워크는 다른 프레임워크가 호출된다는 이야기다. 이렇게 추상화를 통해서 용도와 목적에 맞게 다른 로깅프레임워크로 쉽게 전환이 가능함은 물론이고, 로깅에 필요한 코드들을 추상화해주기 때문에, 훨씬 쉽고 간단하게 로깅이 가능하다. apache common logging 역시, SLF4J와 같이 다른 로깅 프레임워크 들을 추상화 해주는 기능을 제공한다.

Log4J

Log4J는 이중에서 가장 오래된 로그프레임워크로 로그 프레임워크에 대한 초반 개념을 설정했다고 볼 수 있다. 현재는 개발이 중지되고, Log4J2로 새로운 버전으로 변경되었다.

Logback

아마 현재 국내에서 가장 널리 많이 사용되고 있는 로그 프레임워크일것이다. Log4J 개발자가 개발한 로그 프레임워크로 주로 Log4J 성능 부분에 대한 개선 작업이 많이 이루어 졌다. SLF4J와 네이티브로 연동이 가능하다.

Log4J2

가장 근래에 나온 프레임워크로 Logback 보다 후에 나오고, 가장 빠른 성능을 제공한다. Logback과 SLF4J사이의 연동 문제를 해결하였으면 비동기 로깅을 제공하여, 특히 멀티 쓰레드 환경에서 높은 성능을 제공한다.

또한 근래의 로깅 시스템들은 로그를 파일로 기록하기 보다는 ELK(Elastic Search)나 Kafka등 외부 시스템으로 로그를 전송하여 모으는 형태를 많이 취하기 떄문에 이에 대한 연동을 Appender를 통해서 제공한다.

제공되는 Appender는 다음과 같다.

• Console
• File, RollingFile, MemoryMappedFile
• Flume, Kafka, JDBC, JMS, Socket, ZeroMQ
• SMTP(emails on errors, woo!)
• ...much more