kotlin 에서 jackson 사용시 kotlin/reflect/KotlinReflectionInternalErrorjava.lang.NoClassDefFoundError: kotlin/reflect/KotlinReflectionInternalError 이런 에러를 내뿜는 경우가 있다. 나같은경우 코틀린은 1.2.10 을 사용하고있고, 스프링부트를 이용해서 작업하고있었는데 스프링부트에서 포함하고있는 jackson 이 2.8.10 이라서 코틀린 jackson 모듈도 동일 버전으로 추가했었다. compile("com.fasterxml.jackson.module:jackson-module-kotlin:2.8.10") 그리고 저 에러를 만난건데 코틀린 jackson 버전을 2.9 이상으로 올려주면 해결된다.j..
요즘 슬슬 코틀린에 대해 알아보고있다. 이제 막 시작하는단계라 거창하게 적을건없고 간략하게 코틀린 테스트 프레임워크인 spek을 이용해 테스트 코드를 작성하는 법을 알아보자. 일단 IntelliJ에서 개발한다는 전제하에 작성한다. 1. Spek plugin 설치 Spek 플러그인을 설치하자. 2. DependenciesSpek을 사용하기 위해서는 일단 "org.jetbrains.spek:spek-api" 의존성이 당연히 필요하고, "org.jetbrains.spek:spek-junit-platform-engine" 의존성도 필요하다. Spek 의존성만 있어도 아무런 문제없이 컴파일이 되겠지만 junit이 있어야 실행이된다. (junit이 없으면 런타임에 예외가 발생하며 테스트가 진행되지 않는다.) gra..
음..아마 2~3년전에 DI에 관한 포스팅을 하나 했던걸로 기억하는데 그때는 DI가 무엇인지에 대해 적었다면 이번엔 Spring이 어떤방식으로 DI를 해주는지 적어보려한다. 이 글을 적게된 계기는 가장 마지막에 소개할 생성자 주입 방식을 요근래에 알게됐기때문이다. 1. Field Injection가장 간단하고 코드량이 적고, 그때문에 가장 많은 분들이 이용하는 방식이 아닐까싶다. 3개 회사를 다녀봤지만 전부 필드 주입방식을 사용하고있었다. @Service class PersonService{ @Autowired private PersonRepository personRepository; } 이 방식은 가장 간단하고 편리하지만 스프링에 종속적이게된다는 단점이 있다. 뭐 사실 코드의 변경없이 기반 프레임워크..
바로 앞선 포스팅에서 Jackson 2.9 버전에 대해 알아봤다. 이 이슈를 해결하다가 알게된 버그인데 포스팅하고자한다. 1. 이슈 일단 앞선 이슈를 해결하기위해 Jackson 버전을 올렸는데 CI 서버가 테스트를 실행하면서 다른 곳의 테스트가 실패하는 이슈가 발생했다. json 문자열을 자바 객체로 역직렬화(deserialization)하는 테스트였는데 이런 코드였다. public class DeserializeTest { private ObjectMapper objectMapper; @Before public void setUp() { this.objectMapper = new ObjectMapper(); } @Test public void test() throws IOException { Strin..
json 문자열을 자바 객체로 역직렬화(deserialization)하거나 반대로 자바 객체를 json 문자열로 직렬화(serialization)을 할때 자바 라이브러리로는 대표적으로 jackson을 많이 사용한다. 직렬-역직렬시 json key를 결정하는건 @JsonProperty 라는 애노테이션을 이용한다. public class TestClass{ @JsonProperty("name") private String name; } TestClass 객체를 직렬화하거나 혹은 json 문자열을 TestClass 객체로 역직렬화시 name key는 @JsonProperty 애노테이션에 name으로 지정된 곳에 매핑이 되게된다. 참고로 해당 애노테이션이 없을때는 기본적으로 필드명끼리 매핑시키므로 예제와같이 필..
class 파일을 역어셈블리할때 사용하는 명령어 javap -c .class
크롤링 봇들은 항상 웹을 탐색하고다닌다. 전 회사에 재직중인시절 모니터링 시스템에 로그인하지않은 사용자가 자꾸 특정 api를 요청한다는 알림이 와서 봤더니 google bot 이라는 user agent를 담고있는 구글 크롤러를 만난적도 있다. 이런 크롤러들은 웹의 여기저기를 찌르고다니지만 경우에따라서 크롤러에게도 공개하고싶지않은 리소스나 특정 크롤러는 아예 접근하지못하게 하고싶은 경우도 있을 수 있다. 그럴때 사용하는것이 루트 url의 robots.txt 이다. txt라고해서 무조건 정적 텍스트 파일을 반환해야하는것은 아니며 /robots.txt 로 get 요청을 날렸을때 Content-type: text/plan 형태의 문자 데이터만 반환하면 된다. http header 포맷과 비슷하게 반환하면 되는데..
이번 포스팅은 사실 별거 없는데... 몇분 뻘짓을 하고나서 알게돼가지고... 일단 글로 남긴다. 요즘 2017년이 끝나면서 여기저기서 회고록들이 보이고있다. 너무 많은 글들이 올라오고있어서 몇몇개를 보긴했는데 그 중에 github contribution 그래프를 캡쳐한 글들이 많이 있다. 아무래도 일일커밋 등이 유행을 하면서 github contribution 그래프가 1년의 노력들을 간략하게 볼 수 있는 지표적인 역할을 하는것 같다. (github contribution 그래프. 난 열심히 하지 않았나보다...) 그런데 회고록중에 저 컨트리뷰션 그래프를 3d로 올린글들이 많았다. github에 그리 열성적이지않은 내가 보기에도 너무 간지나서 내걸로 함 보려고했는데 나한테는 그런 옵션이 존재하지 않았다...
- Total
- Today
- Yesterday
- EffectiveJava
- generics
- DesignPattern
- programming
- http
- mariadb
- java8
- toby
- Spring
- servlet
- Design Pattern
- spring cloud
- javascript
- Jackson
- Git
- 정규표현식
- frontcode
- Kotlin
- java
- clean code
- JavaScript Core
- MySQL
- db
- TEST
- code
- OOP
- go-core
- JPA
- frontend개발환경
- backend개발환경
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |