TIL-20210313~14

2021. 03. 14.
  • HttpClientErrorException라는게 있어서 사용해봤다. 그런데 이게 좋은건지 모르겠다. 다른 API의 예외를 가져오면 내가 예상치 못한 상황에서도 예외를 처리하게 될 것 같은데. 한 번 물어보는게 좋을 것 같다.
  • 서비스를 짜다보니 순환참조가 걸리게 됐다. 이게 참 애매한 것 같은데 지금 생각은 계층구조가 확실하다면 하나의 서비스에서 여러개의 레포지토리를 받아와도 되지 않나? 하는 생각이 들었다. 계층구조가 확실하면 종속적이라는 뜻인데, 테이블은 관계를 설정해야되니 그런 표현이 되지 않는 것이 아니었나 싶다.
  • 서비스 인터페이스를 만들지 않아도 트랜잭션이 작동 한다. 분명 인터페이스가 있어야 한다고 알고 있었는데, 이는 프록시가 인터페이스를 이용하여 구현된다고 알고 있었기 때문이다. 이상하여 찾아보니 이제는 다이나믹 프록시가 아닌 cglib을 기본 정책으로 사용한다고 한다. 때문에 서비스 인터페이스가 없어도 된다고 한다. cglib은 동적으로 프록시 적용하는 것이 아닌, code generate 방식이다. 따라서 성능이 훨씬 좋은데, aop공부하면서 다시 봐야하는 부분인 것 같다.
  • 잭슨 메세지 컨버터를 커스텀해서 리퀘스트를 캐싱하는데 성공했다. 크나큰 삽질이 있었는데, 아무리 생각하고 찾아봐도 스트림을 재사용하는 방법이 없었기 때문이다. 물론 맨 마지막 바이트를 읽지 않고 넘기는 꼼수를 사용해볼 수도 있지만, 이는 예외 가능성이 무궁무진해지는 좋지 않은 방법일 것이다.

    해결은 생각보다 허탈했는데, 잘 생각해보니 스트림을 굳이 재사용할 필요가 없었다. 그냥 다시 만들어서 보내면 된다. 스프링의 리퀘스트와 관련된 핸들러들은 HttpMessage라는 것을 사용하여 리퀘스트 정보를 넘기는데, 찾아보니 잭슨에서 사용한 듯한 클래스가 있어서 직접 새로 래핑해 보내줬다. 기존에 사용하는 객체는 바디가 비었는지 확인까지 해주지만, 어차피 리퀘스트를 캐싱화는 과정에서 매핑을 한 번 해주기 때문에 이 점만 봤을때는 문제가 없을 것 같다.

    하면서 많이 배웠는데, PushBackInputStream이나 리셋을 시키는 방법 등을 보게 된 것 같다. 스트림도 이제 감이 좀 잡히는 것 같다.

  • 기하학 알고리즘에 많이 사용되는 ccw라는 알고리즘이 있다고 한다. 알고리즘 문제 자체가 아예 이걸 사용하면 풀리게 돼있었는데 이런 문제를 만날때마다 조금 허탈하긴하다. 그래도 기본 공식을 알게 됐으니, 그리고 대부분의 문제는 ccw로 풀 수 있다고 한다. 막히면 바로 찾아볼 수 있지 않을까 싶다.
  • 응답도 규격화 할 수 있지 않을까 싶어서 인터셉터가 어떻게 돼있는지 구경해봤다. 리스폰스도 마찬가지로 IO를 사용하는데, 이건 어떻게 건들기가 힘들 것 같다.
정대화
DaeHwa_Jeong@outlook.com

Powered with by Gatsby 2.0