왕초보 개발자

📌 예외? 프로그램의 정상 실행이 중단될 수 있는 모든 조건과 상황에 대한 통칭

   ==> java.lang.Throwable 타입으로 캡슐화함.
 

  예외 계층(Throwable 하위 타입)

  -> java.lang.Error : 시스템 실패 상황으로 일반적으로 개발자가 처리할 수 없는 에러
  -> java.lang.Exception : 예외 처리 정책에 따라 조건문의 형태로 처리가 가능한 예외
        -> checked exception(non RuntimeException) : 회피/복구/전환 중 어느 한가지 예외 처리 정책을 기반으로 반드시

                                                                                                      처리를 해야 하는 예외(try-catch)

                                                                                                      RuntimeException을 제외한 Exception의 하위 클래스
        -> unChecked exception(RuntimeException 하위 타입) : 개발자가 직접 처리하지 않더라도 자동으로 

                                                                                                                     예외 회피(throws) 전략이 사용되는 예외

                                                                                                                      RuntimeException의 하위 클래스
   ** check uncheck 의 차이점 알아두기 

  예외 처리 정책

   예외 회피(소극적 처리) : throws 키워드를 이용해 메소드의 콜스택 데이터를 기반으로 호출자에게 예외 처리를 떠넘기는 전략.
   예외 처리(적극적 처리) : try(){}catch(){}finally{} 구문으로 직접 처리하는 전략
    try(Closable 객체 생성 및 선언){
           예외 발생 가능 구문
    }catch(처리 가능한 예외 선언, Throwable 하위 타입){
         -> 예외 복구
                  -> 예외 로그 기록 -> 일정시간 지연 -> 예외 발생 작업에 대한 재실행
          -> 예외 전환 : 명확한 조건이나 상황을 표현할 수 있는 예외의 형태로 변경(wrapping)
               catch(IOException e){
                        throw new FileCopyFailureException(e);
                   }

  ** Custom Exception
    1. 예외의 특성에 따라 상위 타입을 결정(Exception vs RuntimeException)
    2. throw 예외 객체 생성
     }finally{
            예외 발생 여부와 상관없이 실행되는 구문
      }

Throwable class

 Throwable 클래스는 Java 언어의 모든 오류 및 예외의 슈퍼 클래스이다.
 이 클래스의 인스턴스(또는 그 서브 클래스 중 하나)인 객체만 Java Virtual Machine에 의해 발생되거나
 Java throw 문에 의해 발생될 수 있다.
 예외의 compile-time checking을 위해, RuntimeException 또는 Error의 서브 클래스가 아닌
 Throwable 및 Throwable의 서브   클래스는 Checked 예외로 간주된다.

Error class

Error는 Throwable의 하위 클래스로서, 응용 프로그램의 심각한 문제를 나타내는 클래스이다.
시스템에 비정상적인 상황이 생겼을 때 발생한다. (시스템 레벨에서 발생한다.)
이러한 오류는 대부분 비정상적인 상태이다. "정상"조건이지만 ThreadDeath 오류는 대부분의 응용 프로그램이
이를 잡아 내려고 하지 않기 때문에 Error의 하위 클래스이기도 하다.Error의 서브 클래스를 throws 선언할
필요는 없다.
Error 및 해당 서브 클래스는 예외 컴파일 시간 검사를 위해 unchecked Exception으로 간주된다.

Exception class

Exception 클래스와 그 subclass는 응용 프로그램이 catch 할 수 있는 조건을 나타내는 Throwable 형식이다.
Exception 클래스와 RuntimeException의 subclass가 아닌 서브 클래스는 checked exception이다.
직접 구현하여 개발자가 비즈니스 로직에 맞게 생성 가능하다.
수많은 subclass가 있으므로 꼭 reference를 확인해 보자.

RuntimeException

RuntimeException은 Java Virtual Machine의 정상적인 작동 중에 발생할 수 있는 예외의 슈퍼 클래스이다.RuntimeException 및 해당 서브 클래스는 unchecked exception이다. unchecked exception은 메서드 또는 생성자의 실행에 의해 발생한다.
메서드 또는 생성자 경계 외부로 전파될 수 있는 경우 메서드 또는 생성자의 throws 절에서 선언될 필요가 없다.

📌웹어플리케이션에서 흐름 제어(A->B) 방법

1. Request Dispatche(요청 분기)

   - Forward : 요청은 A(서블릿)로 응답은 B(JSP 활용케이스가 많음.)에서만 처리됨(Model2 구조에서 활용). 

                    서버사이드 위임 처리 방식
   
   - Include : 요청은 A로 전송 -> 서버내에서 B로 이동->A로 복귀
              (최종 응답은 A+B의 형태로 전송, A가 B를 내포함.) => 페이지 모듈화에서 활용
   
2. Redirect

요청은 A로 전송 -> Body 가 없고, 상태코드가 3xx 인 응답 전송(Location 헤더 포함)  ==> *connectLess, stateLess

    connectLess : 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을 유지 하지 않는 것
-> Location(B) 방향으로 새로운 요청 전송 -> B에서 최종 응답 전송
       301/302 : 원본 요청(A)에 대한 정보가 삭제된 후, GET 방식의 새로운 요청이 redirection.
                         POST ->redirect->GET ==>PRG(앞글자) 패턴 처리구조
       307 : REST 처리에서 많이 활용되며, PUT/DELETE 요청에서 활용.
                원본 요청이 발생하고, redirection 될 때, 원본의 method와 body를 복사해서 새로운 요청이 발생함.
  

<수업필기>
N-Tier미들티어M/T : 톰캣(w.a.s)

레이어드 아키텍처(5-Layer)
   <-프레젠테이션레이어              <-
C->컨트롤러레이어(C.L) 서블릿,jsp1.2.3.     -> 2-1.로우데이터확보 2-2.데이터만듬 3.scope를 통해서 받음    <------의존관계-->service(information을만듬)<----의존관계를형성  <------>  dao: persistence layer <-> D.B(엔터티/릴레이션)에 접근?
v.o(D.L)

프레임워크(구조를 그리고 이해)

JSP ? 서블릿 스펙 기반의 스크립트 형태로 동작하는 템플릿 엔진 (스크립트로 보이지만 컴파일언어)

	jsp 소스의 표준 구성요소
	1. 정적 텍스트(Front-end) : 텍스트, HTML, JS, CSS
	2. 동적 요소(Back-end)
		1) 스크립트 요소
			- scriptlet : (지역코드화,_JSPSerivce) : <%
			// java code , 지역변수
				int currentYear = Calendar.getInstance().get(Calendar.YEAR);
				
			%>
			- expression : <%= "출력값" %>, <%=currentYear%>, <%=txt1 %>
			- directive : <%@page buffer="16kb"  %> : 실행코드에 영향을 미치지 않음, 현재 jsp 페이지의 환경 설정, 전처리(ex.import), 속성으로 설정.
			   	page(required) : required,꼭필요함
			   	include(option) : option,해도되고 안해도됨/ 정적 내포
			   	taglib(option) : custom tag library 로딩
			- declaration(전역코드화): 
			<%!
				private static String txt1 = "텍스트1";
				private String txt2 = "텍스트2";
				public void test(){}
			%> ,선언부, 어느위치에 있어도 위로올라가서 전역코드화가됨
			- comment : <%-- jsp comment --%>
			 	client side comment : HTML, JS, CSS / 프론트
			 	<!-- HTML comment -->
			 	<script type="text/javascript">
			 		// JS comment
			 	</script>
			 	<style type="text/css">
					/* CSS comment */
			 	</style>
			 	server side comment : java comment, jsp comment / 백엔드 / 주석을 사용하려면 server side 주석을 사용해야함, 이유 : 클라이언트에게 보여지지 말아야한다,무거워진다
			 	<%// java comment %>
			 	<%-- jsp comment --%>
			 	
		2) EL(expression language)
		3) jsp 액션 태그 
		4) JSTL(jsp standard tag library)

JSP 컨테이너의 역할

  1. 현재 요청을 처리할 JSP 검색(싱글턴 인스턴스 검색)
  2-1. 검색됐다면, callback 메소드를 호출해 응답 전송
  2-2. 검색에 실패한 경우,
     3. jsp템플릿을 대상으로 서블릿 소스 생성(work)
     4. 컴파일
     5. 싱글턴 인스턴스 생성
     6. callback 메소드 호출해 응답 전송
   

Servlet 컨테이너의 역할

  1. 현재 요청을 처리할 서블릿의 인스턴스 검색
  2-1. 검색됐다면, callback 메소드를 호출해 응답 전송
  2-2. 검색에 실패한 경우,
    3. 싱글턴 인스턴스 생성
    4. callback 메소드 호출해 응답 전송   

차이 : 서블릿컨네이터는  서블릿 소스생성과 컴파일을 직접 해야한다

callback 함수란?

1. 다른 함수의 인자로써 이용되는 함수.

2. 어떤 이벤트에 의해 호출되어지는 함수.

변수의 범위 : 블록변수<지역변수<전역변수<스태틱

<수업필기>

          P to P
                         Request
     --------------------------------------------------------->
c  <---------------------------------------------------------s
                         Response
                         R.Line : Status.Code(xxx/성공,실패) exP 100,200,300,400,500
                         R.Header  : M.D --- content-*
                                                    ----cache-*
                                                    ----refresh
                         R.Body

동기 처리 : rock을 가지고 있기때문에 응답데이터가 다 와야 처리가 됨 (질서가 있는구조)
비동기 처리 : rock의 개념이 없고 빨리 선점하면 처리가 됨 (질서가 없는 구조)

📌 클라이언트의 의도적 전송 데이터 분류

1. requset parameter(문자열, urlEncoded[percent encoded] string)
                : String getParameter(name), Map&lt;String,String[]&gt; getParameterMap(),
                  String[] getParameterValues(name), Enumeration&lt;String&gt; getParameterNames()
 - line 을 통한 query string(1.보내는 모든 데이터는 문자열 2.이름과 값 쌍의 구조) / 
 - body 을 통한 form data

2. multi part : Part(servlet 3.x 부터) 타입으로 하나의 part 데이터를 캡슐화함.
                   getPart, getParts

3. content payload : body 영역을 통해 특정 컨텐츠 타입(Content-Type)으로 전송되는 경우
                  역직렬화 -> 언마샬링 구조 필요(ObjectMapper), request.getInputStream()

📌 Http(Stateless, Connectless) response packaging

: HttpServletResponse(응답과 관련된 모든 정보를 가진 객체)활용

1. response Line : 요청 처리 결과를 표현하는 상태코드(status code)
ex) sendError(sc), setStatus(sc)

 ***status code

100~ : ING...webSocket : Http 의 하위 프로토콜 형태로 connectfull구조를 가짐/

                                         Sless, Cless(연결이 수립되면 연결끊어서 과부하방지)
200~ : OK(success)
300~ : 클라이언트 다음 액션에 대한 유도, body 가 없이 line+header 로만 응답이 구성됨

304 : Not Modified / 캐시와연결 / 캐시가 유효하다/ 캐시가 변경된적 없다는 표시
301/302/307 : Moved + Location 헤더와 병용 / 

      301: 영구로 이동, 302,307: 임시로 이동 /

      302: 데이터를 지우고 ..

      307: 이전 요청의 바디의(메소드와 파라미터)를 복사해서 가져온다
     
400~ : client side failure
400 : Bad Request, 요청 데이터 검증에 활용
404 : Not Found, 자원이없다 / 자원이 제공할 수 있는 서비스가 아닐 때
405 : Method Noa Allowed/ do 계열의 callback메소드를 사용하지 않았을 때?

                                         /  서버가 요청 메서드를 알고 있지만 대상 리소스가 이 메서드를 지원하지 않음을 가리킵니다.
401/403 : Authentication(인증)/Authorization(인가) 기반의 접근제어에 활용 /권한 여부를 검증 / 허가된 유저인지 확인
406/415 : 요청이나 응답의 컨텐츠 타입과 관련하여 활용
406 : Not Acceptable - accept request header 에 있는 MIME 컨텐츠를 생성할 수 없음
415 : UnSupported Media Type - request body content 를 해석할 수 없음
500~ : server side failure, 500(Internal server error)

2. response Header : response content 에 대한 meta data, Content- *

ex) setHeader(name, value), setInHeader(name, intValue), setDataHeader(name, longVale)
addHeader(name, value)
  1) response body content에 대한 설정
  2) 캐시 제어를 위한 설정 : Cache-Control
     <a href="cacheControl.jsp">캐시제어</a>

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Insert title here</title>
</head>
<body>
<h4>응답 헤더를 이용한 캐시 제어</h4>
<pre>
	Pragma(http 1.0), Cache-Control(http 1.1), Expires(all version) // 웹 표준화, 3개 다 사용
	
	Pragma(http 1.0), Cache-Control(http 1.1)
		- public : 양쪽에 다 저장?
		- private : proxy에 저장 x
		- no-cache : 캐싱하지 않는다. 저장된 캐시가 있다면 만료여부를 항상 확인한다.
		- no-store : 캐싱하지 않는다.
		- must-validate : 
		- max-ages : miliseconds
		<%
			response.setHeader("Pragma", "no-cache");
			response.addHeader("Pragma", "no-store");
			response.setHeader("Cache-Control", "no-cache");
			response.addHeader("Cache-Control", "no-store");
			response.setDateHeader("Expires", 0);
			
		%>
		
</pre>
</body>
</html>

  3) auto request : Refresh
     <a href="autoRequest.jsp">auto request</a>

<%@page import="java.time.LocalDateTime"%>
<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta http-equiv="Refresh" content="5;url=https://www.naver.com">
<!-- Refresh : rock을 걸수 있는 동기에서만 동작 -->
<title>Insert title here</title>
<script type="text/javascript" src="<%=request.getContextPath() %>/resources/js/jquery-3.6.3.min.js"></script>
</head>
<body>
<h4>현재 서버의 시간 : <span id="timeArea"></span></h4>
<h4>주기적인 자동 요청 발생</h4>
<pre>
1. server side : response header(Refresh)<%--  <% response.setIntHeader("Refresh", 1); %> --%>
2. client side :
	- JS : scheduling function(setTimeout, setInterval) 
    <!-- setInterval 간격,주기를 설정 -->
	- HTML : meta

</pre>
<textarea rows="5" cols="100"></textarea>
<script type="text/javascript">
	let timeArea = $('#timeArea');
	setInterval(function(){
		$.ajax({
			url : "<%=request.getContextPath()%>/07/getServerTime.jsp",
			dataType : "html"
		
		}).done(function(resp, textStatus, jqXHR) {
			timeArea.html(resp);
		}).fail(function(jqXHR, status, error) {
			console.log(`상태코드 : \${status}, 에러메시지 : \${error}`);
		});	
	}, 1000);
</script>
</body>
</html>

  4) flow control : Location

3. response Body[Content-Body, Message-Body] : 클라이언트가 요청한 컨텐츠 자체.

 📌 Stream : 일련의 연속성을 가진 순차적 데이터의 흐름. 데이터 전송을 위한 단방향 통로

   
 * 스트림의 종류

   1. 전송 데이터 크기에 따른 분류
    1) byte stream(1byte) : inputStream/OutputStream
       ex) FileIn(Out)putStream, ByteArrayIn(Out)putStream, SocketIn(Out)putStream
    2) char stream(2byte) : Reader/Writer
       ex) FileReader(Writer), OracleClobReader(Writer), PrintWriter

   2. 스트림 생성 방법과 필터링 여부에 따른 분류
    1) 1차 스트림 : 매체를 대상으로 직접 생성 및 개방할 수 있는 스트림
       ex) FileIn(Out)putStream, FileReader(Writer)
    2) 2차(연결형) 스트림 : 1차 스트림을 대상으로 연결형으로 생성되는 스트림 // 기본생성자가 없고 1차스트림에 연결
    buffered : BufferedReader(:Scanner와 유사/ BufferedWriter:System.out.println();과 유사), BufferedIn(Out)putStream
    filtered : DataIn(Out)putStream
   직렬화/역직렬화 : (Serialization/Deserialization) : ObjectIn(Out)putStream
   ***-Serializable 객체의 상태를 전송이나 저장을 위해 바이트 배열의 형태로 바꾸는 작업 
   - 매체 저장되어 있거나 전송된 바이트 배열로부터 Serializable 객체의 상태를 복원하는 작업(역직렬화)
 

   **스트림을 통해 데이터를 읽는 단계

 1. 매체를 핸들링 할 수 있는 형태의 객체로 생성. ex) new File("d:/contents/cat1.jpg");
 2. 단방향 1차 스트림 객체 생성, 매체를 대상으로 생성. ex) new FileInputStream(file);
     2-1. 필요시, 1차 스트림을 대상으로 2차 스트림 연결형으로 생성
 3. EOF, EOS(end of file, end of stream)(-1,null)반복적인 읽기
 4. 2차에서 1차 순으로 stream 종료(close) 

📌Request Header : 클라이언트와 요청을 수식하기 위한 비의도적 메타데이터

    <%=request.getHeader("Accept") %>

    name/value 쌍의 문자열 형태로 전송
    ex) Accept-* : 응답 컨텐츠의 속성을 제한하는 요청 헤더/ 우선순위대로 나열 (data type)
         Content-* : request body를 통해 전송되는 컨텐츠의 속성을 표현하는 헤더
              Content-Type : application/xml
              Content-Length : 12222
         User-Agent : 클라이언트가 사용하는 시스템에 대한 정보를 표현하는 헤더
         ex) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit(렌더링엔진: 번역담당)/537.36 (KHTML, like Gecko)

               Chrome/110.0.0.0 Safari/537.36 Request Body(Content Body, Message Body)
               Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 

               Safari/537.36 Edg/110.0.1587.57 
                /*모바일 환경인지 네트워크 환경인지 구분*/

📌Request Body(Content Body, Message Body )  

        : 클라이언트가 전송하는 의도적 입력 데이터(컨텐츠) 영역
        : Content-Type 요청 헤더에 따라 컨텐츠 형식이 다를 수 있음.
         ex) Content-Type : application/x-www-form-urlencoded -> 파라미터로 전송된 문자열
               Content-Type : multipart/form-data -> 파트 형태로 전송된 컨텐츠
               Content-Type : application/json -> JSON 형태로 전송된 컨텐츠

====> HttpServletRequest 객체의 형태로 캡슐화됨

<수업필기>

mashalling : native data 를 공통 표현 방식(json, xml)형태로 바꾸는 작업.(직렬화와 비교)
unmashalling : 공통 표현 방식(json, xml)의 데이터를 native 언어 형태로 바꾸는 작업.

xml : 무겁다
json : 가볍다

Traversing 기능: 
각각의 요소간의 접근방법
예를 들어 어떤 요소의 자식요소, 부모요소를 찾아갈 때 사용하는 방법
요소에 id 속성을 부여해서 접근하는 방법이 있지만 traversing을 사용하면 id를 부여하지 못하는
상황에서도 접근이 가능하다.

📌Http Request packaging

Request Line : protocol/version, URL(URI, 자원에 대한 식별자, 명사), http Method(자원에 대한 행위, 동사)
http(request) Method : 요청의 의도(목적)와 패키징 방식을 표현

GET(R)   : default method, 서버로부터 데이터(자원)를 조회하기 위한 목적의 리퀘스트

                  body 영역이 형성되지 않음
POST(C) : 서버로 데이터를 전송하기 위한 목적의 리퀘스트

                  클라이언트의 의도적 전송 컨텐츠가 존재함. 

                  body 영역이 형성됨.

                  content-*종류의 요청 헤더들이 존재함

HEAD : response body 가 없는 형태로 응답이 전송됨

             GET방식과 동일하나 응답 메시지를 제외한 헤더 등의 메타데이터만 조회

* PUT, DELETE
<form method="post">
<input type="hidden" name="_method" value="put">
<input type="hidden" name="_method" value="delete">
</form>

PUT/PATCH(U) :

     PUT: 전체를 한 번에 수정,이미 존재하는 서버상의 리소스를 변경하기 위한 리퀘스트 /body 영역이 형성됨

     PATCH: 부분 수정/  body 영역이 형성됨
DELETE(D) : 서버 상의 리소스를 삭제하기 위한 리퀘스트
OPTION : 서버가 현재 지원하는 http 메소드를 조회하기 위한 리퀘스트

                 preFlight : 요청으로 본 요청의 메소드 지원 여부 파악

TRACE : server debugging 용도로 제한적 사용, 요청 데이터 중 일부를 다시 돌려받는 리퀘스트

CONNECT : HTTP 터널링을 수행하기 위해 터널 예약을 위한 리퀘스트

ex) /member/memberList.do
    /member/memberView.do?memId=a001
    /member/memberInsert.do
    /member/memberUpdate.do
    /member/memberDelete.do
    
    RESTful URI 구조
    /member (GET) 
    /member/a001 (GET)
    /member (POST)
    /member/a001 (PUT)
    /member/a001 (DELETE)

📌 JSP?

서블릿 스펙 기반의 스크립트 형태로 동작하는 템플릿 엔진

 1. 정적 텍스트(Front-end) : 텍스트, HTML, JS, CSS
 2. 동적 요소(Back-end)
 
   1) 디렉티브를 비롯한 스크립트 요소

    (1) Directive(지시자)

    : <%@page buffer="16kb"  %> : 실행코드에 영향을 미치지 않음, 현재 jsp 페이지의 환경 설정,

                                                    전처리(ex.import), 속성으로 설정.

   (2) 스크립트요소

JSP 컨테이너의 역할

  1. 현재 요청을 처리할 JSP 검색(싱글턴 인스턴스 검색)
  2-1. 검색됐다면, callback 메소드를 호출해 응답 전송
  2-2. 검색에 실패한 경우,
     3. jsp템플릿을 대상으로 서블릿 소스 생성(work)
     4. 컴파일
     5. 싱글턴 인스턴스 생성
     6. callback 메소드 호출해 응답 전송

Servlet 컨테이너의 역할

  1. 현재 요청을 처리할 서블릿의 인스턴스 검색
  2-1. 검색됐다면, callback 메소드를 호출해 응답 전송
  2-2. 검색에 실패한 경우,
  3. 싱글턴 인스턴스 생성
  4. callback 메소드 호출해 응답 전송