Hello, Freakin world!

특히 DTO들의 중복이 아주 심하다. 지금 서버 간에 JSON 포맷의 데이터로 통신을 하고 있다. 그래서 그 데이터를 사용하기 위해 다시 DTO 객체에 바인딩한다. 그래서 서버, 클라이언트 모두 같은 DTO 클래스를 가지고 있어야 하는데, 프로젝트가 어느 정도 복잡해지니, 유지보수하기가 여간 귀찮은게 아니다. 그리고 유틸용으로 작성해놓은 메서드도 다른 모듈에서 사용하려면 코드를 복사해서 사용해야한다. 상황을 몸소 느껴보니, 자바9에서 모듈 시스템을 왜 도입했는지 알겠다. 대충 찾아보니 gradle에서 plugin을 이용하면 모듈 프로그래밍이 가능한 것처럼 보인다. 일단 킵해두고 반드시 학습해보자. 여기저기 수정하기 귀찮아죽겠다 ㄹㅇ로

ChatRoomServer의 단위테스트 및 통합테스트 추가(v1.1) 이제 채팅룸 서버는 에러가 없는 이상 완성됐다고 간주하고, 다음 작업으로 넘어가자. https://github.com/johnna-endure/chatroom-serverjohnna-endure/chatroom-serverContribute to johnna-endure/chatroom-server development by creating an account on GitHub.github.com 진행 상황 이제 다시 Selector를 이용한 논블로킹 방식의 서버부분과 이 두 가지 서버에게 요청을 보내는 콘솔 앱 부분 작성에 들어가면 된다. 참고로 이벤트 방식의 논블로킹과 동기 방식의 논블로킹은 서로 완전히 통신하는 방식이 다르다.이에..

간단하게 시작해서 여기까지 오게 되다니 ... 코드를 조금씩 생성하면서 그에 관한 글도 꾸준히 올리려했지만 워낙에 코드를 뒤집어 엎고대규모 수정하는 경우가 빈번해 글 사이 시간 간격이 상당히 길어졌다. 결국 CompletableFuture 를 이용한 논블로킹 동기 방식의 서버를 1차 완성했다.아직 단위테스트와 통합 테스트 몇 부분을 더 추가해야 되긴하지만. 내 기준에 정말 의미있는 성과다. 아직 다듬을 코드가 많긴 하지만, 그래도 나름 코드 품질을 어느 정도는 유지하려 애썼다. 아래는 전체코드다.(혹시 실행시켜보시려는 분은 .gradle, .idea, build, out 폴더는 삭제하고, 프로젝트는 gradle로 빌드하시면 됩니다. ) 이 프로젝트에 대해서도 할말이 많긴 한데,자세한 설명은 따로 프로젝트..

단위 테스트 ... import static org.assertj.core.api.Assertions.assertThat; public class TestChatRoomController { ChatRoomController controller; DummyRequestHandler requestHandler; @Before public void init() { controller = new ChatRoomController(); requestHandler = new DummyRequestHandler(); } @Test public void testInvoke_bracedUrlMethod() throws NoSuchMethodException, InvocationTargetException, Illega..

글의 제목만으로는 추가하려는 기능의 정의가 와닿지 않는다. 간단하게 코드를 이용해 추가하려는 기능을 정의하자. 기능 정의 @RequestMapping(method = Method.GET, url = "/room/{id}") public Response canJoinRoom(Request request, int id) { ... } @RequestMapping의 url 속성의 값을 살펴보자. 특이한 점은 "{ id }" 라는 중괄호가 포함된 url을 가지고 있다. 이는 스프링 프레임워크를 써본 사람이라면 한번 쯤은 써본 기능이다. 중괄호는 일종의 유연한 url 매핑이 가능하도록 해준다. 예를 들어, "/room/12", "/room/idstring" 은 모두 위의 url을 만족한다. 다만, 아래 인수의 i..

public Response dispatch(Request request) { Method[] methods = RequestHandler.class.getMethods(); Optional handlerOpt = findHandler(methods, request.getUrl(), request.getMethod()); try { Method handler = handlerOpt.orElseThrow(() -> new NotFoundException("url 에 해당하는 핸들러를 찾지 못했습니다.")); return invoke(requestHandler ,handler, request);; } catch (NotFoundException e) { e.printStackTrace(); return ne..

이 프로젝트는 본래 채팅앱 프로젝트의 일부분이었으나, 현재 채팅 프로젝트의 덩치가 워낙 커지는 바람에... 따로 분리했습니다. 그리고 이 부분은 애너테이션, 정규표현식, 리플렉션 등을 이용한 프레임워크에 필요한 편리한 기능을 구현하는 바탕이 될 수 있다고 판단해 따로 정리해두려고 합니다. 시나리오 서버는 클라이언트의 요청을 받고 controller 에 해당하는 객체에 request 정보를 넘겨 준다. 컨트롤러는 request에 포함된 url에 따라 핸들러를 매핑할 책임을 가진다. 우리는 이 핸들러들을 식별하기 위해 handlers 클래스를 작성할 때, 미리 식별정보를 같이 적어둔다. @RequestMapping 이라는 애너테이션을 이용해 이를 수행한다. @RequestMapping에 url format을..

POST /room | 채팅방 생성 요청 응답 : 성공 또는 실패여부 GET /room/{ id } | 채팅방 조회 요청 응답 포맷 상태코드 설명 ChatRoom Json객체 GET /rooms | 채팅방 리스트 요청 응답 : List POST /room/{roomId} | 채팅방 참가 요청 응답 : 참가 가능시 id에 해당하는 ChatRoom 객체를 body에 Json 형태로 보낸다. 참가 불가능시 body는 null이다. DELETE /room/{roomId} | 채팅방 삭제 요청 응답 : 성공 또는 실패 여부 Request 메세지 형식 | method url | | [data] 응답 메세지 형식 | 상태코드 [상태 설명] | | [data]

아마 내가 자바 nio에서 제공하는 selector를 이용한 논블로킹 방식에 꽂혀있었는지도 모르겠다. 이 방식으로 모든 네트워크 통신을 처리하려고 했으나 한계가 있다는걸 깨달았다. 이전에 ConnectionLoop를 구현할 때 깨달았던 부분과도 관련이 있다. 지금이 selector를 이용한 논블로킹 방식(이벤트 방식)은 데이터를 보내고 그에 대한 응답을 받아야하는 식의 대화형 애플리케이션은 만들 수가 없다. 그 이유는 이벤트를 보내고나서 그 특정 응답을 선별할 수 없기 때문이다. 이를 구현하려면 동기방식을 쓸 수 밖에 없다. (기존의 웹처럼) 동기방식을 쓰더라도 그 작업을 다른 스레드에 위임하면 논블로킹을 구현할 수 있는데, 아마도 Future와 CompletableFuture를 사용하면 될 듯하다. 자..