수민정의 기술블로그

springframework 예제를 쳐보던 중에 언제나 web.xml에 쳐오던 CharacterEncodingFilter에 대해 더 알게 됬다.. 내가 보아왔던 그녀석인데, 뜯어보면 경로매핑과 파라미터 설정이 되어있다. encodingFilter chap19.Util.CharaterEncodingFilter encoding UTF-8 encodingFilter /* public class CharaterEncodingFilter implements Filter { private String encoding; public CharaterEncodingFilter() { // TODO Auto-generated constructor stub } public void destroy() { // TODO Aut..

chain의 doFilter 메서드를 사용하면 필터결과 이후 필터로 넘기고 넘겨 Servlet으로 넘기는 역할을 하게된다. 그렇다면, 필터를 거쳐서 다시 거슬러올라가려면 doFilter() 메서드 뒤에 Statement를 정의하면 된다. Response의 조작 기능은 HttpSerlvetResponseWrapper클래스를 상속받은 클래스에 정의 되어 있으니, 둘이 같이 사용하는 것이 이롭다고 봐야겠다. 들어온 순으로 다시 나가게 되므로 응답은 Serlvet부터 거쳐온 필터를 역으로 거슬러서 올라가게 된다. public class FilterEx1 implements Filter { public FilterEx1() { // TODO Auto-generated constructor stub } public..

Filter에서 요청과 응답 값을 조작하는 것은, HttpServletRequestWrapper 클래스와 HttpSerlvetResponseWrapper 클래스로 한다. 생성자를 지정만 해준다면 HttpServletRequest를 매개값으로 굳이 전부 다 재정의 할 필요가 없는 Wrapper환경을 만들어 준다고 보면 될 듯 하다. Filter의 doFilter메서드에서 값을 조작해야할 경우, 사용한다. HttpServletRequestWrapper 클래스와 HttpSerlvetResponseWrapper 클래스를 상속한 클래스를 만든다. 상속클래스에서 원하는 메서드를 재정의한다. 해당 클래스를 생성하여 사용한다. 까지가 방법이다. RequestWrapper클래스를 상속해서 getParameter 메서드를..

스프링 프레임워크 시동시 CharaterEncodingFilter 등 filter들을 web.xml에 정의해두는 일을 보면서 의아해한적이있다. 태그에는 으로 필터의 별칭을, 필터 클래스를 명시한다. 구현필터는 Filter를 구현하고 있다. Servlet과 Filter를 매핑 하려면 태그 안에 을 주면되며, url로 매핑하고 싶다면 을 주면된다. 하나 필터에 다수의 서블릿 이름도 줄 수 있다. 태그를 주면 경우에 따라 필터를 적용시킨다. REQUEST 클라이언트의 요청인 경우 필터적용(기본값) FORWARD forward()를 통해서 제어흐름을 이동하는 경우 적용 INCLUDE includ() 를통해서 포함되는 경우 적용 ServletEx1 chap19.ServletEx1 ServletEx1 /Servle..

수업이 mvc2로 넘어가고 있다. 내가 모르는 점, 내가 이해못했떤 점들을 알려주시니 난 그저 원없이 고마운 마음을 드릴 따름인 것 같다. 남는시간에는 spring5 입문서를 들여다보는 일상인데,, @Valid 에노테이션을 보면서 문득 생각하기를 '어, 나 이거 봤는데' 하며 반가워 했다. 검증에 사용되는 것이구나..했더랬다. 돌아와서는 토비의 스프링 책소개를 보면서 시간을 보냈다. 전자정부 프레임 워크 핵심 기술이라...정말 만만치 않겠구나..해보았다. 다 좋다, 다만 시간을 허투로 쓰지만 않았으면 좋겠다. 열심히 공부하고, 내가 할 수있는 만큼 하고, 그랬으면, 난 더 바랄게 없을 것 같다. 정말 그 외에는 바랄 것도 없고...그 걸로도 너무나도 과분한 일만 같다.

web.xml의 초기화 파라미터, 즉 서블릿의 init() 시에 서블릿을 바로 객체화 시키는 데 사용하는 것이 태그이다. 태그의 몸통 부분에는 WAS 구동시 초기화 순서를 지정한다. 예를 들어 InternalResourceViewResolver나 DispatcherSerlvet 같은 경우, Default 서블릿 같은 경우에 사용하는 듯 싶다. 또한 서블릿 객체화 시에 parameter를 줄 수도 있는데 이는 으로 정의한다. 의 자식태그로 을 줘서 파라미터 이름을 지정하고 태그로 값을 정의한다. DispatcherSerlvet의 경우는 dispatcher 가 인 것으로, 값에 org.springframework.web.serlvet.DispatcherServlet 인 것으로 기억하고 있다. initMeth..

이 글의 참고는 https://beyondj2ee.wordpress.com/ [BeyondJ2EE] 분의 블로그입니다. 스프링 빈이 싱글톤을 가지고 있고, ApplicationContext라는 스프링 컨테이너가 static Sharing Pool을 생성한다는 것은 알고 있으나, Thread에 Safe 한지는 모르는 와중, 궁금증이 생겨 서문에 기제한 개발자 분의 글에서 도움을 얻었습니다. 즉 멀티 쓰레드 환경에서 등록된 Bean들은 공유하게 되고. 여기까지는 ...아는데. 문제는 다음입니다. Component 들은 ComponentScan 에 의해 springBean으로 등록되는데, @Component들의 멤버변수들은 Sharing 되는가? 가 궁금증이었습니다. 예제를 타이핑하면서 @Autowired된 ..

request: 구조상 Tread - Safe 하다. 하나의 요청단 하나의 Thread가 사용되는 구조이다. 쓰는 작업은 여기서 진행하는게 이롭다. Session: 한 브라우저 상의 모든 서블릿이 공유하므로 쓰기작업을 하기에 좋지않다. redirect 요청같이 불가피한 작업의 정보공유는 session에서 하기도한다. Application: 웹 어플리케이션안에 모든 서블릿이 공유하므로 쓰기 작업을 하기에 좋지않다. 보장되는 경우가 존재한다.

해당 링크를 클릭하면 해당 주소로 움직이게 되고, 이는 해당 URL로 GET요청을 한다는 것 같다. 관리자 로그인 그럼 컨트롤러 단에서는 @RequestMapping @PostMapping @GetMapping 등으로 요청을 받아낼텐데. 이때 속성값은 "~~~login.do"가 될 것이다. 하지면 리턴하는 view 코드는 .jsp파일의 이름이며, 이는 InternalResourceViewResolver가 잡아주는 해당 .jsp 파일의 경로와 이름이다. 그럼 do로 매핑을 하면 사용자는 무엇을 볼 수 있나. 사용자는 주소 창에 .jsp가 아니라 .do를 보게된다. 가상주소를 보게되는 것이고, 사용자는 파일의 실제 경로를 알 수 없으며, 소스 보기를 해도 파일과 경로는 알 수 없다고 한다.

이렇게 매핑되어 있다는 가정하에. 정확한 경로 매핑 경로매핑 /* *.do 같은 확장자 매핑 / 기본매핑 순으로 우선 순위를 가지며 *.do 같은 확장자 매핑과 /~/~ 같은 경로매핑이있다. Serlvet1 *.do Servlet2 /foo/bar Servlet3 /foo/* /blue.do > 확장자 매핑 3순위 :Servlet1 /foo/bar > 정확한 매핑 1순위 :Servlet2 foo/bar/blue.do > 경로매핑 2순위 :Servlet3 /foo/blue.do > 경로매핑 2순위 :Servlet3 /fred/blue.do > 확장자 매핑 3순위 :Servlet1 /foo > 경로매핑 2순위 :Servlet3 /foo/bar/foo.fo > 경로매핑 2순위 :Servlet3 /fred/bl..