Carry On Progamming Carry On Progamming

아래 사진처럼 프로젝트는 있는데 톰캣 서버 목록에 아무것도 안 뜨는 문제가 생겼다. STS3 -> STS4로 바꾸는 과정에서 생겼는데 기존 STS3와 비교하고, 구글링을 하면서 힌트를 얻어서 해결했다.(캡처 사진은 해결하고 난 뒤라서 프로젝트 목록을 가렸다.) 글쓴이 개발도구Spring suite tool 4(이클립스 기반) 해결한 방법Eclipse JST Server Adapters, Eclipse Java EE Developer Tools가 설치되었는지 확인해본다.(이클립스 마켓에서 다운 받을 수 있다. Help > Eclipse Marketplace)

cat (톰캣 로그) | grep (찾고자 하는 문자열) ex) 톰캣 로그 파일 이름: catalina.out.2019-01-11찾고자하는 문자열: 09:28 cat catalina.out.2019-01-11 | grep 09:28 라고 치면 09:28이 포함된 로그들만 결과가 쭉 나온다!

일일이 import static을 타자칠 필요가 없었다. 그래... import를 일일이 칠리가 없을텐데 하고 찾아봤다. alt + enter를 하면 된다고 했는데, 알고보니 내 인텔리J에서는 command + 1로 설정 되어있었다. 이게 필요했던 이유는 assertThat과 Matchers.is를 사용하기 위해서 찾아보게 됐다. import static 하는 방법 1. 일반적인 import 단축키(나의 경우 ctrl + spacebar)를 사용하면 ctrl을 누르고 스페이스바를 두 번 누른다. 혹은 한 번. 그럼 오른쪽에 형광등 표시가 뜨는데 마우스로 클릭하면 Import statically가 뜨는데, 이것을 클릭하면 된다. 2. 단축키 설정을 통해 사용한다. 이 방법이 훨씬 좋을 것이다. 인텔리J의 ..

개발하면서 비즈니스 로직은 Service에 두어야한다고 들어서 비즈니스 로직은 모두 Service에서 개발했다. 그렇지만 Service Layer가 너무 비대해진다고 생각했었는데, 이미 많은 분들이 그런 문제를 생각하고 도메인에도 로직을 두자는 의견을 보았다.(그래서 선임님이 그렇게 개발을 하셨구나. 사스가 선임님) 그럼 서로간의 의존성을 줄일 수 있지 않을까 싶다. 나중에 사람들의 의견을 취합해서 정리해봐야겠다.

Field Injection is not recommended.md Field Injection을 추천하지 않는 이유(+Constructor Injection을 추천하는 이유) 의존성 주입을 할 때 Field Injection은 좋지 않다는 글을 읽고 왜 그런지 찾아봤다. 스택오버플로 뿐만 아니라 스프링팀에서도 Field Injection을 추천하지 않았다. 왜 그런지 몇가지 글을 보고 종합해서 정리해본다. 일단, 의존성 주입의 종류로는 Constructor, Setter, Field 타입이 있다. Constructor(생성자) public class ExampleCase{ private final ChocolateService chocolateService; private final DrinkServi..

Warning:(8, 57) java: org.springframework.web.servlet.config.annotation.WebMvcConfigurerAdapter in org.springframework.web.servlet.config.annotation has been deprecated 스프링부트(version 2.0.4)로 개발중인데 갑자기 위의 에러가 나왔다. 스프링부트 2는 스프링 프레임워크 5를 사용한다. 스프링 5에서는 WebMvcConfigurerAdapter 대신 WebMvcConfigurer를 사용한다. 자바 8에서(스프링부트2는 jdk8부터 사용가능하다) WebMvcConfigurer 인터페이스를 소개하고 있다. WebMvcConfigurer 인터페이스가 WebMvcConf..

temp2 [JUnit] Argument(s) are different! Wanted: JUnit Controller 테스트에서 validation 중에 발생한 에러!! 에러가 설명하듯이 인자가 다르단다. 어? 근데 콘솔 찍히는거보면 똑같은데 왜 다르다고 뜨지?라는 의문이 생겼다. 테스트 코드는 아래와 같이 작성했었다. coffeeDTO에 데이터를 심고 getCustomerList에 coffeeDTO를 담아서 컨트롤러와 서비스가 잘 동작하고 있는지 체크하는 테스트코드다. CoffeeDTO coffeeDTO = new CoffeeDTO; coffeeDTO.setCoffeeName("블루마운틴"); coffeeDTO.setCountry("Jamaica"); coffeeDTO.setPrice("4000"); ..

temp1 e.printStackTrace() vs logger.error e.printStackTrace()를 사용하지 말고 logger.error를 사용하라는 글을 읽었던 기억이 있다. 부가적인 설명이 있었는데, 뭔가 구체적으로 알고 싶어 스택오버플로를 뒤져봤다. 왜 써야하는지 많은 개발자분들이 댓글을 달아놨는데, 그 댓글들을 해석해 정리해두려한다.(별이 많은 댓글 중심으로 정리!) answers logback이나 log4j같은 logging framework를 사용하지 않으면 아래와 같은 코드를 작성할 것이다. e.printStackTrace(); logging framework를 사용한다면, 아래와 같이 작성할 수 있다. logger.error("Error Occurs!!", e); logging..