사실상 기존에 사용만 해봤지 실제 구조가 어떻게 굴러가는지에 대해서는 정확하게 공부하지 않았습니다.(반성중..사실 좀 바빳다는게 핑계... ㅎㅎ)
좋은 기회여서 일단 원서를 보면서 구조를 파악 해보려 합니다 ㅎㅎ
최대한 자세히 설명하거여서 쉬운 용어들 조차 설명을 할거라 내용이 조금 길어질수도 있습니다. 고수님들께서는 다른거 참조하셔도 됩니다. (저같은 초보를 위한 초보자들을 위해서... ㅎㅎ)
필터(filter)에 대해서
스프링 시큐리티의 서블릿 제공은 서블릿 필터에서 합니다!
여기서 서블릿이란? (모르는 분들을 위해서)
서블릿(Servlet)이란 동적 웹 페이지를 만들 때 사용되는 자바 기반의 웹 애플리케이션 프로그래밍 기술이다. 서블릿은 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해준다.(일단 spring mvc servlet에서는 DispatcherServlet 이어서 그건 아래에 설명하겠습니다.)
스프링 컨테이너는 스프링 프레임워크의 핵심 컴포넌트이다.
스프링 컨테이너는 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공한다.
스프링에서는 자바 객체를 빈(Bean)이라 한다.
즉, 스프링 컨테이너는 내부에 존재하는 빈의 생명주기를 관리(빈의 생성, 관리, 제거 등)하며, 생성된 빈에게 추가적인 기능을 제공하는 것이다.
스프링 컨테이너는 XML, 어노테이션 기반의 자바 설정 클래스로 만들 수 있다.
스프링 부트(Spring Boot)를 사용하기 이전에는 xml을 통해 직접적으로 설정해 주어야 했지만, 스프링 부트가 등장하면서 대부분 사용하지 않게 되었다.
출처: https://ittrue.tistory.com/220 [IT is True:티스토리]
블로그 글을 빌리자면 스프링 자바 객체를 자동적으로 생명주기를 관리해주는곳이 컨테이너입니다.
디스패처 서블릿의 dispatch는 "보내다"라는 뜻을 가지고 있습니다. 그리고 이러한 단어를 포함하는 디스패처 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)라고 정의할 수 있습니다.
이것을 보다 자세히 설명하자면, 클라이언트로부터 어떠한 요청이 오면 Tomcat(톰캣)과 같은 서블릿 컨테이너가 요청을 받게 됩니다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게 됩니다. 그러면 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임합니다.
여기서 Front Controller(프론트 컨트롤러)라는 용어가 사용되는데, Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러로써, MVC 구조에서 함께 사용되는 디자인 패턴입니다.
출처: https://mangkyu.tistory.com/18 [MangKyu's Diary:티스토리]
말그대로 http 요청이 오면 가장 먼저 받는 위치에 존재하는 컨트롤러라고 생각하시면 편합니다.
당연히 아시겟지만 하나의 서블릿은 HttpServletRequest 및 HttpServletResponse를 처리할 수 있습니다.
하지만!! 하나 이상의 filter는 아래 다음과 같은 목적으로 이용할수 있습니다.
DownStream Filter 인스턴스 또는 서블릿이 호출되는 것을 방지합니다. 이 경우 필터는 일반적으로 HttpServletResponse를 작성합니다.
DownStream Filter 와 서블릿이 사용하는 HttpServletRequest나 HttpServletResponse를 수정합니다
DownStream Filter란?(저도 몰랐네요 ..)
말그대로 특정 필터 이후에 위치하는 필터들을DownStream Filter라고 합니다.
결국 여기서 말하자고 하는것은요.
원문을보면
The power of the Filter comes from the FilterChain that is passed into it.
저도 이해한느낌이 filter의 강력한 힘은 filterchain을 통함으로라는건데 filter의 강력한점이 filterchain덕분이다 라는뜻 같네요. (혹시나 저도 이부분좀 이해가 안가서 이런느낌인가 합니다.)
간단히 filter chain의 코드를 보겟습니다.
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
// do something before the rest of the application
chain.doFilter(request, response); // invoke the rest of the application
// do something after the rest of the application
}
오늘은 여기까지하고 내일은 DelegatingFilterProxy에 대해서 알아보겠습니다.
10월 중순부터 11월 아마 중순까지는 주말마다 바쁘기도 했고 주말마다 좀 바쁠 예정입니다. 아마 12월 넘어가야 여유가 생길듯합니다. 일단 그래도 틈틈히 시간나면 개발하겠습니다. 요즘 알고리즘이 여러가지 복습을 하다보니 좀 늦어지네요.
일단 게시판불러오면서 댓글들도 불러오는게 문제여서 몇가지를 수정했습니다.
Resolved [org.springframework.http.converter.HttpMessageNotWritableException:
Could not write JSON: failed to lazily initialize a collection of role:
kr.co.kshproject.webDemo.Domain.Notice.Notice.comments,
could not initialize proxy - no Session; nested exception is com.fasterxml.
jackson.databind.JsonMappingException: failed to lazily initialize a collection of role:
kr.co.kshproject.webDemo.Domain.Notice.Notice.comments,
could not initialize proxy
- no Session (through reference chain: java.util.ArrayList[0]-
>kr.co.kshproject.webDemo.Domain.Notice.Notice["comments"])]
데이터베이스와 물리적으로 연결하는 데 사용됩니다. Session 개체는 가볍고 데이터베이스와의 상호 작용이 필요할 때마다 인스턴스화되도록 설계되었습니다. 영구 객체는 Session 객체를 통해 저장되고 검색이라고 하는데. 제가 이해한건 그냥 로그인이나 원격 같은데 접속할떄 그 세션과 동일하게 db 세션객체에 접근해서 crud를 해줄수 있는게 아닐까 생각합니다. 제가 생각한게 맞은게아니라면 잘못된거면 지적 부탁드리겠습니다.
링크글을 빌리면 저도 비슷하게 db connection deadlock을 걸려본적이있는데 당시에는 제가 enitiyManger.close를 하지않아 발생한거였습니다. 반대로 이글을 빌리자면 opiv 을 true로 변경시 문제가 발생할수 있다고합니다. 와 무섭네요... 아무튼 lazy-loading을 해결하기위해 여러가지 방법이 있긴하지만 그중에서 가장 좋은 방향으로 선택하는게 좋겠네요 서비스
일단 이건 작성하려고 했는데 어쩌다보니 계속 뒤로 밀리게되어 이제 작성하게 되었습니다. 제가 초창기 신입일때 회사 홈페이지를 프론트쪽을 수정 후 재시작할일 있어서 재시작하였는데 사수도 없고 인수인계도 잘 되어 있지 않는 상태에서 자신감 넘치게재시작을 눌렀습니다. ㅎㅎ ㅠ
그때 당시에 문제가 발생한게 갑작스레 메일들이 나갔는데... ㅠ 당시 엄청 호되게 혼났엇습니다. 잘모르면 일단 확인을 철저히 하고 했어야했는데 뭐 핑계라면 인수인계 부족.... ㅎ 아무튼 확인 안한 제잘못이 큽니다.. 사실 post -fix 메일에 대한 존재 조차 몰랐기 때문에 무지로 인한 문제라고 생각했습니다. 만약에 제가 전체적으로 웹서비스에 대한 이해도가 높고 서버에 대한 이해도가 높았다면 다양한 시각으로 체크 후 재시작을 했을거라고 생각합니다.
링크의 말을 빌리면 sendmail 같은 SMTP(Simple Mail Transfer Protocl) 를 구현한 소프트웨어를 MTA(Mail Transfer Agent) 라고 부르며 MS의 아웃룩이나 모질라의 썬더버드, 콘솔에서 구동되는 mutt 등의 사용자 프로그램은 MUA(Mail User Agent) 라고 분류한다. sendmail 은 전통적으로 많이 사용되던 MTA 였고 RHEL 5 까지는 기본 메일 서버 데몬이었으나 RHEL 6 부터는 postfix 로 교체되었다. 물론 원하는 사용자는 sendmail 을 MTA 로 사용하는 것도 가능하다.
간이 전자 우편 전송 프로토콜(Simple Mail Transfer Protocol, SMTP)은 인터넷에서 이메일을 보내기 위해 이용되는 프로토콜이다. 사용하는 TCP 포트번호는 25번이다. 상대 서버를 지시하기 위해서 DNS의 MX레코드가 사용된다. RFC2821에 따라 규정되어 있다. 메일 서버간의 송수신뿐만 아니라, 메일 클라이언트에서 메일 서버로 메일을 보낼 때에도 사용되는 경우가 많다.
말그대로 메일끼리 서로 주고 받는거라고 생각하면 편합니다. smtp 사용법은 인터넷에 많으니 참고하시면 되고요. 사용할때 사전지식을 일단 잘 알고넘어가는게 더 중요해서
SMTP는 Simple Mail Transfer Protocol의 약자입니다. 인터넷을 통해 이메일 메시지를 보내고 받는 데 사용되는 통신 프로토콜입니다. 메일 서버 및 기타 메시지 전송 에이전트(MTA)는 SMTP를 사용하여 메일 메시지를 보내고, 받고, 중계합니다.