Humbly

Inner Class에 대한 유효성 검사(javax.validation)

sowhat92 — Sat, 2 Jul 2022 11:53:34 +0900

API를 작성하다 보면 입력 데이터에 대한 유효성 검사가 필요한 상황이 많다.

예를 들어 아래와 같은 코드가 있다고 해보자.

입력 데이터(CreatePersonRequest)를 검증한 후 요건에 맞는 처리 후 응답하는 간단한 코드이다.

이름(name)과 나이(age)를 요청 값으로 받고 이름은 올바른 문자열인지, 나이는 0보다 큰 값인지 판단하는 검증을 진행한다.

{
    "name" : "Steve",
    "age" : 15
}
// 201 Success Return

위와 같이 올바른 값을 전달하여 호출하면 정상 응답 반환된다.

{
    "name" : "",
    "age" : 15
}
// 올바른 이름을 입력해주세요.

그런데 유효하지 않은 요청 값을 전달하면 유효성 검사에 실패하여 에러 메시지가 반환된다.

여기까지는 큰 문제없이 사용할 수 있었다.

그런데 요청 데이터 클래스 내부에 또 다른 클래스(Inner Class)가 존재하고, 그 클래스 필드에도 유효성 검사가 필요하다면 어떨까?

추가로 직업 정보(직업명, 설명)를 받아야 한다고 가정해보자.

대충 봤을 때 잘 돌아갈 것 같은 코드처럼 보인다.

그럼 한번 요청을 해보자.

{
    "name" : "Steve",
    "age" : 15,
    "job" : {
        "name" : "",
        "description" : "middle school"
    }
}
// Internal Server Error

에러가 발생하였다. 그런데 유효성 검사에 따른 에러로 보이지 않는다.

왜냐하면 유효성 검사에 따른 Exception Handler를 별도로 추가해두었기 때문이다.

error log를 봐보면 다음과 같은 내용이 출력되어 있다.

org.springframework.beans.NotReadablePropertyException: Invalid property 'job' of bean class [com.example.demo_databinder.controller.CreatePersonRequest]: Bean property 'job' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?

job 프로퍼티를 읽을 수 없다는 내용으로 보인다.

당황스럽다. Inner Class가 추가되었을 뿐인데 왜 에러가 발생하는 것 일까?

has an invalid getter method

private field라서 접근을 못하는 것인가? 그렇다면 해당 필드의 Getter를 추가하고 다시 호출해보자.

{
    "name" : "Steve",
    "age" : 15,
    "job" : {
        "name" : "",
        "description" : "middle school"
    }
}
// Internal Server Error

그런데 결과는 똑같다. 다시 에러 로그를 봐보자.

Invalid property 'job.name' of bean class [com.example.demo_databinder.controller.CreatePersonRequest]: Bean property 'job.name' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?

이번에는 Job 내부의 name 프로퍼티에 대한 내용이 출력되었다.

CreatePersonRequest.Job에 대한 접근을 위해 job 프로퍼티에 대한 Getter만 추가해주면 될 것이라 생각했지만 Inner Class의 경우 검증이 필요한 내부 필드에도 Getter 추가가 필요하다.

그럼 name 필드에 Getter를 추가 후 다시 테스트해보자.

{
    "name" : "Steve",
    "age" : 15,
    "job" : {
        "name" : "",
        "description" : "middle school"
    }
}
// 올바른 직업명을 입력해주세요.

드디어 의도한대로 유효성 검사에 따른 에러 메시지가 반환되었다.

정리하자면 Inner Class 유효성 검증을 진행하려면 상위 클래스와 해당 클래스(Inner Class)에서 검증을 진행할 필드의 Getter가 필요하다.

그렇다면 만약 요청 객체의 모든 필드를 public으로 지정하여 외부에서 자유롭게 접근할 수 있도록 한다면 어떨까?

단순 데이터 전달 목적(로직을 포함하지 않은)으로만 사용한다면 위와 같이 작성하여 사용하는 것도 크게 이상하지 않다.

이제 모든 필드에 대한 접근 지정자를 public으로 허용해두었으니 외부에서 자유롭게 접근할 수 있을 것이고 그럼 에러가 발생하지 않을까?

{
    "name" : "Steve",
    "age" : 15,
    "job" : {
        "name" : "",
        "description" : "middle school"
    }
}
// Internal Server Error

org.springframework.beans.NotReadablePropertyException: Invalid property 'job' of bean class [com.example.demo_databinder.controller.CreatePersonRequest]: Bean property 'job' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?

안타깝게도 동일한 에러가 발생한다.

왜 그럴까?

이쯤에서 드는 생각은 유효성 검사를 진행할 때 검사가 필요한 대상이 필드라면 직접 접근하여 값을 얻어오는 것이 아니라 Getter를 통해 값을 얻어온다고 추측할 수 있다.

그럼 반대로 필드에 직접 접근하도록 할 수 없을까 찾아보다가 아래의 글을 발견하였다.

https://stackoverflow.com/questions/39164077/java-spring-rest-validation-configure-property-access

Java Spring Rest validation configure property access

I have a Spring-JSON/RestAPI that use annotation driven input validation. @Valid I get the following error when I try to validate an object inside another object. java.lang.IllegalStateException:...

stackoverflow.com

    @InitBinder
    private void activateDirectFieldAccess(DataBinder dataBinder) {
        dataBinder.initDirectFieldAccess();
    }

위와 같은 코드를 ControllerAdvice에 추가하여 설정한다면 DataBinder가 필드에 직접 접근하여 사용한다고 한다.

그럼 검사를 위한 목적으로만 추가된 불필요한 public getter를 제거하고 저 설정을 켜 두는 게 맞을까?

https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors

Why use getters and setters/accessors?

What's the advantage of using getters and setters - that only get and set - instead of simply using public fields for those variables? If getters and setters are ever doing more than just the simp...

stackoverflow.com

위 글은 필드에 직접 접근하지 않고 getter/setter를 사용하였을 때 장점을 이야기하고 있다.

객체지향적인 관점에서 필드를 숨기는 행위(private)는 여러모로 의미가 있다.

비록 유효성 검증만을 위한 public getter이지만 필드에 직접 접근하는 것을 허용함으로써 여러 설계적 단점이 발생하는 것보다 낫다고 생각한다.

마지막으로 필드에 있는 유효성 검사 어노테이션을 메서드로 옮겨 public getter method의 역할을 분명히 하였다.

Java NIO - SocketChannel non-blocking mode에서 Read Timeout 설정

sowhat92 — Tue, 2 Nov 2021 09:39:13 +0900

SocketChannel Default nonBlocking is false

SocketChannel을 사용할 때 기본적으로 Blocking Mode로 사용된다.

일반적으로 다음과 같이 사용하는 경우 버퍼에 있는 데이터를 읽기 위한 작업 수행 시 Thread Block 발생

이 경우 Read Timeout(soTimeout)을 설정해도 먹히지 않음

Javadoc을 보면 read() 메서드에 대한 timeout은 InputStream을 사용할 때 적용 가능하다고 되어 있음

즉, SocketChannel의 구현체인 SocketChannelImpl의 read() 메서드를 직접 사용하는 경우 InputStream을 사용하지 않고 IOUtil.read()를 호출

SocketChannelImpl.read(ByteBuffer buf) 메서드 내부

InputStream을 사용하여 ReadTimeout 설정

getInputStream()을 통해 실제 ChannelInputStream 반환

이후 SocketInputStream.read(ByteBuffer bb)가 호출됨

이 메서드에서의 특징은

소켓 채널의 설정을 Non-Blocking으로 변경
```
sc.configureBlocking(false);
```
최초 읽기 시도 시 반환된 데이터가 없으면 이후 timeout 설정만큼 소켓을 poll 하여 변화를 감지
```
int result = sc.poll(Net.POLLIN, to);
```
만약 0보다 작은 값이 반환되었다면 Running Time을 확인하여 타임아웃이라 판단되면 SocketTimeoutException Throw
```
to -= System.currentTimeMillis() - st;
if (to <= 0)
	throw new SocketTimeoutException();
```

메서드를 Return 하기 전 설정을 원복 하여 Blocking Mode로 바꿈

finally {
	try {
		sc.configureBlocking(true);
	} catch (ClosedChannelException e) { }
}

결론

SocketChannel Blocking Mode에서는 기본적으로 Read Timeout 기능을 제공하지 않음
InputStream을 사용하는 형태로 Blocking Mode에서도 Read Timeout 기능을 사용할 수 있지만 실제 내부 로직에서는 Non-Blokcing Mode로 임시 변경하여 사용하는 트릭과 같음

참고

https://docs.oracle.com/javase/8/docs/api/java/nio/channels/SocketChannel.html#read-java.nio.ByteBuffer-

SocketChannel (Java Platform SE 8 )

Reads a sequence of bytes from this channel into the given buffer. An attempt is made to read up to r bytes from the channel, where r is the number of bytes remaining in the buffer, that is, dst.remaining(), at the moment this method is invoked. Suppose th

docs.oracle.com

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4614802

Bug ID: JDK-4614802 setSoTimeout does not work with nio SocketChannel

bugs.java.com

https://technfun.wordpress.com/2009/01/29/networking-in-java-non-blocking-nio-blocking-nio-and-io/

Networking in Java: non-blocking NIO, blocking NIO and IO

Standard run-time library in Java provides two interfaces for networking. One, which exists in Java since the beginning, is called “basic IO”, because it is based on generic framework o…

technfun.wordpress.com

Spring JPA findById() 사용 시 주의점

sowhat92 — Wed, 28 Jul 2021 21:08:55 +0900

Spring JPA에서 Entity 조회 시 @Id 어노테이션이 적용되어 있는 필드 메서드 인자 값으로 하여 Optional<T> findById(ID id) 메서드 호출 가능하다.

JpaRepository를 상속받은 경우 SimpleJpaRepository가 구현체로 주입되며 조회 시 아래와 같은 처리가 진행된다.

1. 만약 1차 캐시에 조회하고자 하는 Managed Entity가 존재한다면 이를 반환

2. 만약 1차 캐시에 없다면 DB 조회 후 반환

DB에서 조회하기 전 트랜잭션을 생성하게 되는데 이때 트랜잭션 속성의 경우 1) method @Transactional 어노테이션이 있는지 확인하고, 만약 없다면 2) class에 @Transactional 어노테이션 존재 확인

findById() 메서드는 SimpleJpaRepository 클래스의 구현체 메서드로 호출되고, 해당 클래스에는 @Transactional(readOnly = true) 가 적용되어 있음

findById()를 호출 한 상위 메서드에서 별도의 트랜잭션이 생성되어 존재하지 않는다면 SImpleJpaRepository에서 생성된 트랜잭션을 물고 들어가기에 findById()는 readOnly 속성이 적용된다!

RW/RO를 별개의 물리적인 Datasource를 사용하고 있다면 readOnly 속성이 적용된 트랜잭션의 경우 RO에서 데이터를 조회하기 때문에 Replica Lag(복제 지연)이 발생할 수 있다.

그러므로 복제 지연이 발생한다는 가정 하에 아래와 같은 현상이 발생할 수 있다.

1. RW에 레코드 생성

2. 복제 지연 기간 내 RO에서 1번에서 생성된 레코드 조회(findById) → NOT_FOUND

결론

findById()는 호출자 상위에서 별도의 트랜잭션이 존재하지 않는다면 readOnly 트랜잭션을 생성하여 조회
RW/RO를 분리하여 사용하고 있다면 복제 지연으로 인하여 RW에서 생성 한 레코드를 findById()로 조회하였을 때 NOT_FOUND를 응답받을 수 있음

해결 방안

findById() 호출자에서 트랜잭션(readOnly = false)을 생성하여 RW에서 조회
Repository에 Custom Method를 정의하여 사용(RW로 접근)

@MockBean Spring Context Recreated

sowhat92 — Mon, 24 May 2021 22:53:08 +0900

1. 현상

@SpringBootTest로 통합 테스트를 관리하는 경우 테스트 시작 시 SQL Script를 통해 H2 in-memory-database에 초기화를 진행할 때 스크립트 중복 실행이 발생하여 DB Exception 발생
기본적으로 Spring boot JDBC Initializer는 fail-fast 전략으로 스크립트 실행 중 에러가 발생하면 중단시킴

2. 원인

통합테스트를 위해 필요한 Configuration을 정의 후 사용, 일부 테스트에서 개별적으로 @MockBean을 사용하여 Spring Context Recreated를 유발

Any existing single bean of the same type defined in the context will be replaced by the mock. If no existing bean is defined a new one will be added.

@MockBean을 사용할 경우 Spring Context에 이미 Bean이 존재하더라도 대체. 각 테스트마다 @MockBean이 사용된다면 개별적인 Spring Context가 생성.

3. 해결 방안

application.properties에 아래의 옵션 추가. 실행 중 스크립트로 인한 에러가 발생해도 중지하지 않음(Fail-Safe)

spring.datasource.continue-on-error=true

@MockBean 어노테이션을 각 테스트 클래스마다 사용하지 말고 필요 한 부분을 추출하여 공통 Configuration으로 관리

- https://github.com/spring-projects/spring-boot/issues/10015

구체적인 Exception Catch를 해야하는 이유

sowhat92 — Thu, 22 Apr 2021 00:25:00 +0900

이전 회사 A에서는 서비스에서 발생할 수 있는 Custom Exception을 최대한 구체적으로 작성하였다.

이후 회사 B에서는 Exception을 최소한으로 분류하여 사용하고 있다.

무조건 '어떤 것이 옳다'는 없다.

다만 각각의 선택지마다 사이드 이펙트는 분명히 존재한다.

Custom Exception을 구체적으로 작성하여 사용하지 않았을 때 발생할 수 있는 문제 중 하나는 "공통" 처리로 인한 사이드 이펙트이다.

예제 코드

기존

public class BlackListChecker {
    public boolean isBlackList(final String ip) {
        try {
            IpLogger.log(new Ip(ip));
            // check blacklist
            if(blackList)
            {
            	return true;
            }
        } catch (final Exception e) {
            return false;
        }
        return false;
    }
}

해당 ip가 블랙리스트인지 체크한다. 만약 블랙리스트라면 true, 아니면 false를 반환한다.
처리 중 에러가 발생한다면 블랙리스트가 아닌 것으로 취급(false 반환)

시간이 지나 Exception이 발생하게 된다면 블랙리스트로 취급하도록 기준이 강화되었다고 생각해보자.

이후 기준 강화

public class BlackListChecker {
    public boolean isBlackList(final String ip) {
        try {
            IpLogger.log(new Ip(ip));
            // check blacklist
            if(blackList)
            {
            	return true;
            }
        } catch (final Exception e) {
            // 기준이 강화되어 에러가 발생한다면 안전하게 블랙리스트로 취급
            return true;
        }
        return false;
    }
}

예를 들기 위한 극단적인 코드이지만 기준이 강화된 이후 변경된 코드로 인해 블랙리스트가 아닌 ip에 대하여 블랙리스트로 취급되는 문제가 발생하였다.

열심히 디버깅하여 문제의 원인을 찾아보았다.

왜 문제가 발생하였을까?

문제는 아래와 같이 호출 된 코드이다.

blackListChecker.isBlackList("");

어떠한 이유가 됬든 IP로 전달되어야 할 인자 값에 blank string이 전달되었다.

이렇게 전달된 데이터로 인해 Ip 객체 생성 new Ip(ip) 에서 InvalidStringException이 발생하였다.

이 경우 블랙리스트로 판단하는 것이 맞을까?

물론 요구 사항에 따라 달라지겠지만 극단적으로 이 서비스에서는 ip가 blank string이면 블랙리스트가 아니어야 한다.

문제점

블랙리스트인지 확인하는 코드에서 발생하는 Exception catch를 구체적으로 분류하지 않았다.
그로 인해 예상치 못한 Exception raise(정상 처리로 반환했어야 할)가 발생하였을 때 의도하지 않은 결과가 반환되었다.

해결 방안

이 글은 Exception Catch를 구체적으로 나열하지 않고 공통된 하나의 Exception으로 다뤘을 때의 문제점을 전달하기 위해 작성하였다.

결론은 Exception Case를 구체적으로 분류하여 각각의 에러 상황에 개발자가 의도한 로직이 처리되도록 하는 것 이다.

public class BlackListChecker {
    public boolean isBlackList(final String ip) {
        try {
            IpLogger.log(new Ip(ip));
            // check blacklist
            if (blackList) {
                return true;
            }
        } catch (final InvalidStringException e) {
            // 인자로 전달 된 ip가 문제가된 경우 블랙리스트가 아님으로 취급
            return false;
        } catch (final Exception e) {
            // 기준이 강화되어 에러가 발생한다면 안전하게 블랙리스트로 취급
            return true;
        }
        return false;
    }
}

하지만 사실 아래와 같은 편법으로 작성할 때가 많기도 하다.

public class BlackListChecker {
    public boolean isBlackList(final String ip) {
        if(isInvalidString(ip)) {
            return false;
        }
        try {
            IpLogger.log(new Ip(ip));
            // check blacklist
            if(blackList)
            {
            	return true;
            }
        } catch (final Exception e) {
            // 기준이 강화되어 에러가 발생한다면 안전하게 블랙리스트로 취급
            return true;
        }
        return false;
    }
}

인자로 전달된 ip(String)가 적절한 문자인지 확인

Open Session In View와 트랜잭션, 그리고 영속성 컨텍스트

sowhat92 — Wed, 24 Mar 2021 22:12:02 +0900

Open Session In View?

Open session in view는 view에서 session을 열겠다는 속성이다.

그럼 언제 view에서 session을 열고자 할까?

Controller에서 객체를 응답으로 보내고, view에서 사용자의 입력에 따라 객체의 값을 수정하고자 할 때 사용할 수 있다.

이렇게 수정된 객체는 Open Session in view 설정에 따라 영속성 컨텍스트에 반영이 되고, Datasource(DB)에 기록될 것이다.

1. Open Session In View = False

이 옵션이 꺼져 있을 때에는 일반적으로 트랜잭션이 종료될 때 영속성 컨텍스트도 같이 비워진다.

2. Open Session In View = True

옵션이 켜져 있다면 트랜잭션이 종료되어도 영속성 컨텍스트는 비워지지 않는다.

주의 사항

Open Session In View 옵션이 켜져 있는 상태에서는 더티 체킹에 주의해야 한다.

트랜잭션이 종료되어 객체가 비영속 상태가 되었을 것이라 생각하기 쉽기 때문에 이후 객체의 상태가 변경된다면 더티 체킹이 발생하여 의도치 않은 값 변경이 적용될 수 있다.

Java Ratelimiter - 초 당 처리량 조절하기

sowhat92 — Mon, 1 Mar 2021 22:54:36 +0900

Why?

현재 담당하고 있는 서비스에서 API, DB 호출에 대한 초 당 처리량 조절 필요

Ratelimiter

Guava에서 제공하는 모듈로 초 당 처리량을 설정을 통하여 관리될 수 있도록 한다.

implementation("com.google.guava:guava")

gradle 의존성 추가

1. 인스턴스 생성

private final RateLimiter apiRateLimiter = RateLimiter.create(4);

public static RateLimiter create(double permitsPerSecond) {
    /*
     * The default RateLimiter configuration can save the unused permits of up to one second. This
     * is to avoid unnecessary stalls in situations like this: A RateLimiter of 1qps, and 4 threads,
     * all calling acquire() at these moments:
     *
     * T0 at 0 seconds
     * T1 at 1.05 seconds
     * T2 at 2 seconds
     * T3 at 3 seconds
     *
     * Due to the slight delay of T1, T2 would have to sleep till 2.05 seconds, and T3 would also
     * have to sleep till 3.05 seconds.
     */
    return create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer());
  }

초 당 허용할 Task의 개수를 인자로 넘겨준다

public static RateLimiter create(double permitsPerSecond, Duration warmupPeriod) {
    return create(permitsPerSecond, toNanosSaturated(warmupPeriod), TimeUnit.NANOSECONDS);
  }

원격 서버를 바로 호출하지 않고 웜업이 필요한 경우 이러한 생성자를 사용할 수도 있음

2. 획득

허용 acquire() 을 획득하여야만 Task를 처리할 수 있음

public double acquire() {
    return acquire(1);
}

@CanIgnoreReturnValue
public double acquire(int permits) {
    long microsToWait = reserve(permits);
    stopwatch.sleepMicrosUninterruptibly(microsToWait);
    return 1.0 * microsToWait / SECONDS.toMicros(1L);
}

예약 reserve()

final long reserve(int permits) {
    checkPermits(permits);
    synchronized (mutex()) {
      return reserveAndGetWaitLength(permits, stopwatch.readMicros());
    }
}

예약은 허가 횟수(permits)를 예약하고, 대기 시간을 반환함
획득 acquire() 은 있지만 반납은 없다

주의 사항

내부적으로는 synchronized로 동작하여 권한 획득 시 대기 시간을 반환받고 대기 시간 이후 작업을 수행한다.

즉, 작업 권한을 부여받은 작업(Task)이 완료하여 종료되지 않더라도 다른 작업이 대기 시간 이후 작업을 수행할 수 있다.

Threadpool size를 고정적으로 사용하는 경우에는 큰 문제가 발생하지 않지만 동적으로 poolsize를 조절하는 newCachedThreadPool() 같은 경우 병목 현상이 발생한다면 최대 Integer.MAX_VALUE 만큼 thread가 생성될 수 있기에 유의하여 사용해야 한다.

자바 원시(Primitive) 타입과 참조(Reference) 타입, 그리고 Reflection

sowhat92 — Fri, 1 Jan 2021 21:38:12 +0900

발단

Request 클래스의 Primitive type으로 선언된 변수에 대하여 Jackson Deserialize가 정상적으로 처리되지 않음

How to Deserializing?

Spring에서 @ReuqestBody를 사용하는 경우
body에 있는 data를 HttpMessageConverter 이용,
특히 Json Data의 경우 MappingJackson2HttpMessageConverter 통하여 Jackson ObjectMapper readValue() 호출하고,
그 결과 개발자가 지정한 Request Object를 만들어 반환한다.

요약하자면 결국 JSON 요청 데이터를 Java Reflection을 사용하여 개발자가 지정한 Request Object에 매핑해준다.

obj는 개발자가 지정한 Request Object
value는 deserialize 된 request data 중 일부

예제 코드

@RestController
public class PrimitiveTestController {
    @PostMapping(value = "test/primitive")
    public ResponseEntity<String> finalTest(@RequestBody final Request request){
        final long number = request.number;
        final Long number2 = request.number2;
        return ResponseEntity.ok().body(request.toString());
    }
}

class Request {
    public static final long DEFAULT = 100L;
    public final long number = DEFAULT;
    public final Long number2 = DEFAULT;
}

호출 결과

Request{number=10, number2=10} 을 기대하였지만 결과는 위와 같다

Why?

결과로 기대하였던 것은 number, number2 모두 Request Body로 Deserealize 된 Request{number=10, number2=10} 이다.

하지만 왜 예상한 결과대로 처리되지 않았을까?

final로 초기화된 원시 타입

Chapter 4. Types, Values, and Variables

A variable of primitive type or type String, that is final and initialized with a compile-time constant expression, is called a constant variable.

Chapter 13. Binary Compatibility

References to fields that are constant variables are resolved at compile time to the constant value that is denoted. No reference to such a field should be present in the code in a binary file (except in the class or interface containing the field, which will have code to initialize it). Such a field must always appear to have been initialized the default initial value for the type of such a field must never be observed.

final로 초기화 된 원시 타입은 complie-time에 inline code화 된다?

무슨 말인지 모르겠으니 다시 예시 코드를 봐보자

PrimitiveTestController.java

@RestController
public class PrimitiveTestController {
    @PostMapping(value = "test/primitive")
    public ResponseEntity<String> finalTest(@RequestBody final Request request){
        final long number = request.number;
        final Long number2 = request.number2;
        return ResponseEntity.ok().body(request.toString());
    }
}

제일 처음 보았던 Controller의 Java 코드이다.

이 코드를 컴파일 한 .class 파일을 확인해보자!

PrimitiveTestController.class

@RestController
public class PrimitiveTestController {
    public PrimitiveTestController() {
    }

    @PostMapping({"test/primitive"})
    public ResponseEntity<String> finalTest(@RequestBody final Request request){
        request.getClass();
        long number = 100L;
        Long number2 = request.number2;
        return ResponseEntity.ok().body(request.toString());
    }
}

long number = 100L;

원래 코드의 의도는 Json Deserialize 된 Request Object의 number를 반환하는 것이었다.

final long number = request.number;

하지만 컴파일된 코드에서는 위와 같이 초기화에 사용된 constant value가 코드에 들어가 버렸다.

또한 Wrapper Class로 사용된 number2의 경우 primitive type과 별개로 의도하고자 했던 대로 컴파일되었다.

정리

Primitive type, String의 경우 final & initialized 된다면 compile-time에 상수 표현식이 inline code화 된다.
그러므로 primitive type & String에 대하여 final 키워드를 사용한다면 해당 변수가 초기화되는 시점을 잘 고려해야 할 것이다.

참고

https://stackoverflow.com/questions/23273936/changing-static-variable-works-primitive-wrapper-but-not-with-primitive-type

Spring @Transactional 어노테이션은 왜 Bean이 아닌 객체에서 적용되지 않는가?

sowhat92 — Thu, 31 Dec 2020 01:58:35 +0900

먼저 이 질문은 두 가지로 나눠야 한다.

Spring AOP는 왜 Bean으로 등록된 객체에 적용되는가?
Spring AOP 동작 방식에는 어떤 것이 있는가?

1. 왜 Bean으로 동록되어야 하는가?

https://stackoverflow.com/questions/23394407/is-it-possible-to-use-spring-aop-without-creating-beans

Is it possible to use Spring AOP without creating beans?

Spring AOP depends on proxy mechanism - J2SE dynamic proxies or using CGLIB(according to the spring documentation). Is it possible to use the AOP mechanism defined by Spring without creating/decla...

stackoverflow.com

요약하자면 Spring AOP는 기본적으로 Spring IoC와 협업한다.
Spring AOP가 정상적으로 동작하기 위해서는 Spring Context 즉, Spring 관리 아래에 있어야 하지만 Bean으로 등록되지 않은 객체는 보통 new SomeClass() 와 같이 동적 할당하여 사용하기 때문에 Spring 관리 아래에 놓이지 못한다.

2. AOP 동작 방식

Spring AOP는 기본적으로 RTW(Runtime weaving)으로 두 가지 방식이 존재한다.

ProxyFactoryBean은 interface의 유무에 따라 두 가지 방식 중 한 가지를 선택한다.

1. JDK Proxy

인터페이스가 존재하는 경우 사용된다.
자바 리플렉션을 사용하여 실제 실행되는 메서드를 invoke() 하기 때문에 CGLIB 방식보다 성능 상 불리하다.

2. CGLIB

바이트 코드를 조작하기때문에 인터페이스가 없어도 실행 가능하다.
다만 final 클래스나 메서드인 경우에는 사용할 수 없다.

https://www.baeldung.com/spring-aop-vs-aspectj

Bean이 아닌 POJO 객체, 그리고 final 클래스나 메서드에 사용하고 싶다면?

AspectJ를 참고

추가) @Transactional은 기본적으로 CGLib Proxy 방식을 사용

참고

https://do-study.tistory.com/83

Spring AOP 동작 방식, 원리

스프링은 기본적으로 프록시 기반 AOP 를 제공한다. 스프링에서는 Java Dynamic Proxy를 사용하거나 Cglib을 사용하여 프록시 기반 AOP를 구현했다. 이 글에서는 어떻게 Spring 에서 AOP를 사용할 수 있는

do-study.tistory.com

https://stackoverflow.com/questions/38043089/spring-aop-for-non-spring-component

Spring AOP for non spring component

I am writing Spring 4 application with java config. I can use AOP in this project for all spring component. But i can't use it for a normal POJO class. what is the library I need to add and what ...

stackoverflow.com

Junit5 @BeforeEach private method가 동작하는 이유

sowhat92 — Wed, 30 Dec 2020 13:59:09 +0900

발단

어느 날과 다름없이 비즈니스 로직을 먼저 작성하고 테스트 코드를 작성하는 코드 몽키 ing 중
테스트 코드 실행 전 초기 설정이 필요하여 Junit5의 @BeforeEach 사용
호기심이 발동하여 접근 지정자 private 지정

실행

어? 성공하네?
사용해도 되는건가? 공식 문서ㄱㄱ

@BeforeEach methods must have a void return type, must not be private, and must not be static.
private을 절대 사용하지 말라고 must로 명시되어져 있는데 왜 동작하는 거지?
구글링을 하였지만 명확한 답변을 찾을 수 없음
그래서 직접 삽질 시작

동작하는 이유

결국 역시나 답은 Reflection

결론을 이미 부제에 달았지만 혹시나가 역시나 답은 리플렉션

디버깅을 걸어보자!

@BeforeEach 메서드 내부에 breakpoint 지정

Call Stack 중 눈에띄는 relfect!

하나 씩 거슬러 올라가다 의심 부근 발견!

RelectionUtils.invokeMethod()

RelectionUtils.makeAccessible()

여기서 object는 Method 객체, 더 정확히 말하자면 @BeforeEach가 달린 setUp() 메서드

Java Reflection에서는 전지전능 한 기능을 제공하고, 그중 private method를 접근할 수 있게 만들어버리는 매직(magic)을 제공 한다

자세한 내용은 문서 참고

심증은 찾았으니 물증 확인

해당 부분에 Breakpoint를 걸고 다시 디버깅

AccessibleObject.setAccessible() 에 의하여 변경되는 값은 결국 override

RelectionUtils.makeAccessible() 호출 전 override의 상태는 false!

이 상태에서는 private 지정자의 역할이 발휘된다

호출 이후 값을 확인해보면 true로 변경될 것을 확인할 수 있다

결론

Junit5에서 제공하는 @BeforeEach 어노테이션은 접근 지정자가 private이 되지 않기를 권고한다. 하지만 private을 지정해도 잘 돌아간다. 그 이유는 리플렉션을 사용하여 다 접근 가능하게끔 변경하기 때문이다. 고로 리플렉션은 깡패...