Controller, Interceptor, logger

Controller의 리턴타입

1. void
2. @responsebody

Interceptor

• 모든 페이지마다 동일한 기능을 제어할 수 있다.

• 예를 들어, 사용자가 클릭을 하고 그 후에 서버가 처리하는 시간을 구할 수도 있다.

• 이 페이지에서 어떤 url이 인기가 제일 많은지 체크하고 싶을 때, url혹은 uri를 체크해서 db에 쌓을 수도 있다.

• 즉, 인터셉터는 필터가 할 수 있는 일을 다 할 수 있다.

  Q. 그렇다면 필터와 다른 것이 무엇인가?

  바로 처리시점이다.

  • filter의 경우 : 브라우저는 필터로 요청을 한 뒤에 서블릿으로 간다.

  • Spring의 경우 : 브라우저는 필터로 요청을 한 뒤에(여기까지는 필터와 동일하다) spring의 dispatcher servlet이 받는다. 그 후에 interceptor 가 잡아서 filter가 하던 일을 똑같이 따라한다. 그 후에 컨트롤러에게 요청한다.

• Interceptor는 선언된 순서대로 실행한다.

#컨트롤러 관리 방법

1. 컨트롤러(핸들러) 실행 전

   prehandle : 컨트롤러/핸들러 객체를 실행하기 전에 필요한 기능을 구현할 때 사용

2. 컨트롤러(핸들러) 실행 직후

   postHandle : 컨트롤러/핸들러가 정상적으로 실행된 이후에 추가 기능을 구현할 때 사용

3. 브라우저에 보여지기 직전

   afterCompletion : 클라이언트에 뷰를 전송한 뒤에 실행

로그 남기기

• 실무에서는 log4j를 제일 많이 사용한다.

• logback으로 추세가 바뀌고 있긴하다. log4j가 너무 느려서... 그런데 logback의 문제는 시스템의 메모리를 일부 떼어가서 쓰다보니까 메모리가 모자라기 시작한다.. 메모리가 모자라면 동적으로 쓸 수 있어야 하는데, 누군가가 메모리를 비워줄때까지 기다렸다가 그 다음 로그를 사용한다. 그렇기 때문에 점점 시간이 안맞게 된다.

• 로그를 남기는 것은 지금까지 system.out.println() 을 써왔지만, 앞으로는 이것을 사용하지 않는다. system 이라는 static 클래스가 가지고 있는 모든 메모리를 사용하기 때문에 시스템이 현저하게 느려진다.

• 이전에는 commons-logging을 많이 사용했고, spring도 이것을 사용하고 있기도 하다.

• 이러한 로깅 툴들이 혼재되어 사용되고 있지만, 이럴 경우 충돌이 되는 경우가 빈번하므로, 로깅툴을 통일시켜주어야 한다.

실습

1. Controller 실습

1) pom.xml 수정

• pom.xml 에 dependencies 추가

• <type>bundle</type> 는 삭제해준다.

2) BadgeController.java 생성

• 리턴타입이 string이나 ModelAndView 가 아닐 때, 반드시 @ResponseBody를 넣어주어야 한다.

3) applicationContext.xml 추가

4) 실행

• json 타입으로 확인할 수 있다.

2. Interceptor 실습

1) interceptor 라는 이름의 패키지 추가 --> TestInterceptor 클래스 생성

2) HandlerInterceptorAdapter를 상속받음, preHandle, postHandle, afterCompletion 구현

3) applicationContext.xml 추가

• 모든 url에 전부 다 TestInterceptor를 거쳐가도록 하는 것

4) 실행 후 콘솔창 확인

3. log 실습

1) pom.xml 수정

• pom.xml에 dependencies 추가

2) LogBack 설정

• src/main/resources 밑에 logback.xml 파일 만들기

3) ArticleController 수정

• logger를 호출하는 클래스를 적어준다.

4) 실행