2020-12-29

jsbak·2020년 12월 29일

웹기반 어플리케이션

목록 보기

33/40

@컨트롤러
트레이싱
@R.M으로

handler Adapter는 호출하는 역할만

명령 분석, 검증, 로직태우기
LogicalName이라고 부르는 이유
전체 뷰에 대한 경로 를 가지고 있지 않기 때문에

EL, JSTL을 레이아웃엔진? 템플릿엔진? 이라고도 한다.

언제나 자기만의 다이어그램

오늘

파일업로드처리
파일 업로드 처리를 구현하는 과정에서 Filter

총 동원 게시판 ㅇㅅㅇ 살려줘
담주는 part3 스프링

파일 업로드

파일 업로드할때와 안할때의 차이??

한글과 같은 특수 문자 인코딩, 문자열

우리는 이런 일반적인 문자열이 아니라 2진 데이터를 보내야한다.

파일의 메타데이터 밖에 없다.(파일 이름)

그럼 바디에 문자가 아니라 다른걸 넘겨야한다.

이게 존재해서 문자열이 인코딩되어서 넘어가는 것

문자가 아니라 2진 데이터를 그대로 유형해야한다. -> 바디에 여러데이터 형식이 다 들어 가야한다. -> 바디를 여러개로 쪼개야한다. 3개를 넘겨야한다고 하면 3개로 영역을 쪼개야한다.

boundary 경계선

------WebKitFormBoundaryjvbxIKCh2JrirqrF 기준으로 나눠진다.

이 안에는 문자가 없고 part 만 존재한다.
1.문자 데이터
2.파일 데이터
두개가 서버로 가는데 ,총 3개의 파트가 가는데 우리는 이걸 처리, 파일 가는 데이터는 서버에 저장하고 업로드 처리도 해줘야한다.
걱정?문자가 없을때의??

지금은
파라미터가 없고
파트가 존재한다.
파트를 받는 방식이 서블릿 2.5 와 3.0 이후 방식이 나뉜다.

multipart 관련해서는 req.getPart()가 존재하는데 Servlet 3.0에서부터 지원하는 것이다.
고급자바때는 2.5방식으로 해봤으니 지금은 3.0 방식으로 해보자

예외나옴
java.lang.IllegalStateException: Unable to process parts as no multi-part configuration has been provided
이걸 처리할 녀석이 없다?

그래서 찾아보니
IllegalStateException - if the request body is larger than maxRequestSize, or any Part in therequest is larger than maxFileSize, or there is no @MultipartConfig or multipart-config indeployment descriptors

@MultipartConfig 그래서 집어 넣는게 이녀석

청크?

참고 : https://en.wikipedia.org/wiki/Chunk_(information)

location 위치 정보를 저장, 생략하면 JDK가 가진 기본 경로를 이용
max-file-size 파일 하나당 허용할 수 있는 크기
max-request-size 파일이 몇개가 오든 request당 허용할 수 있는 크기
file-size-threshold
파일이 작아서 청크로 쪼개지 않아도 되는 녀석(일반적으로 100MB라고 하면, 업로드 파일 1kb) 굳이 이렇게 작아도 임시 저장소에다가 저장할 것이냐 인메모리 방식으로 저장하는게 빠르다. 이 기준을 정하는 것
예) 10kB 크면 location에 저장, 작으면 인메모리 저장

파일 하나를 온전하게 업로드할 수 있는 구조가 마련된다.

우리는 기본 설정으로 했다. (설정은 web.xml)

설정한 뒤의 결과

db 에는 메타 데이터가 저장되고 실제 파일은 미들티어에 저장한다. (서버, WAS, WS)

파일에 대하여 검증을 한적이 없다.

클라이언트(accept), 서버단 2개(mime, 이름)

절대 겹치지 않는 식별자
universally unique identifier (UUID).

Filter

F.C가 유일한 Servlet이니까 여기가 multipartConfig 설정해준다. 밑당에서는 가지고 놀면된다. PartData를 Controller에 전달할수 있어야한다.
D.F.P(Decorating Filter Pattern)
Decorating 장식품(옵션)을 집어넣기 위한 Filter를 써보자 어플리케이션의 필수기능은 X
건드리지 않는 상태 에서의 필터?
그래서 필터가 Fronnt Controller 보다 앞에 들어가야한다.
그래서 filter 는 filter chain 의 형태로 운영한다. 그러면 WAS에 등록하면 체인의 형태로 운영한다.

Filter 의 목적

요청에 대한 전처리 완성? - 요청이 가진 일부 성질을 변경하고 싶을때
보안목적의 접근제어 - 비정상적인 요청을 거름, 접근제어에 대해서 전혀 신경쓸 필요가 없다.
응답 데이터의 후처리 - Controller가 내보내는 response와 최종적으로 나가는 response는 다르다 ex) 필터에서 큰 크기의 파일을 압축

기존의 비지니스(코드)를 건드리지 않고 더 풍부하게 연출하고 싶을때 이용한다.

우리는 필터에
1. 파일업로드 처리
2. 어플리케이션의 접근제어 구조(관리자, 일반)

요청의 전처리, 응답의 후처리, 보안(인증, 인가)

Filter도 서블릿이 관리되는 구조와 똑같이 운영된다.(WAS가 SDLC.생명주기 를 관리)

콜백 메서드인 doFilter가 요청하나 하나 처리할수 있는 요청 필터가 되고,
하나 이기 때문에 경계선이 필요하다, 그것을 구분하는것이 FilterChain 이다.
나머지 두개의 init와 destroy는 SDLC 콜백

주의할점 어떤경우에든 요청과 응답이 나갈수 있게 해야한다.

chain.doFilter(request, response);

블라인드 처리?(특정 클라이언트 블라인드??)

리퀘스트하나, 멀티파트 하나 2개를 만듬

커맨드 오브젝트? 클라이언트가 보내주는 데이터
공통적으로 커맨드 오브젝트가 사용된다면

상품 관리에서만 파일처리했는데
현재 3tier 구조
2진 데이터 M.T, Meta-data DB
경우에 따라서는 DB에 2진 데이터를 저장해야할 수도 있다.

data scheme

검색어 : data scheme
링크 : data URI scheme

사용법 - data:[<media type>][;base64],<data>

예제 
<img src="data:image/png;base64,iVBORw0KGgoAAA
ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU
5ErkJggg==" alt="Red dot" />