01. 파일업로드
MultipartResolver
- 파일 헤더와 바디 해석해준다
02. 오후수업
1. WEB-INF
- 숨김파일
- 브라우저에서 접근을 못함
- 서블릿에서 리다이렉션하거나, 포워딩할때만 볼 수 있음
2. 횡단처리 : 부관심사
- 보안, 로그남겨라 등 항상 동작할 수 있도록 남긴다
- AOP 적용에 나오는 에스팩트 부분
- advice 클래스명 나오면 전처리, 후처리다 라고 생각하면 됨
3. application.properties
- 환경변수 설정임
- rootconfig 에서 value에 적기만 하면 된다.
- 여기에서 파일명만 바꾸면 벨류들이 다 바뀐다.
4. Hikari
- 커넥션 툴 라이브러리
- db쓸때 많이 쓰는 기술
# 리마인드 (8/6) -- 노션에 붙여넣으세욤 !!!!!!!
## 세팅 step 3 (dynamic web 템플릿):
**1) settings.gradle에서 프로젝트명을 바꿔주기**
rootProject.name= “xxxxxxx”
**2) annotation processor**
shift shift(퀵 액션) — annotation processors — enable
**3) tomcat**
외장톰캣을 달아줌. 디버거 툴(run configuration) 에서 tomcat server (local) 추가하기
deployment — artifact (war(웹 배포 아카이브 파일) artifact) 생성 — application context를 /로
(”이 build된 war를 배포해 !”)
help - vm option에서 Dfile, Dconsole encoding을 복사해서 tomcat configuration에 붙여넣기.
UTF-8로 바꿔주는 것.
rootConfig = spring을 달아줌. gradle 파일의 라이브러리들을 넣어줘야 함.
build.gradle에서 junit, spring, lombok, java 버전을 넣어주고 spring, aop 등등 넣어주기.
주의: testAnnotationProcessor — 중앙에 lombok 빠져있었으므로 넣어주기
---
## WEB-INF
숨김 폴더. 브라우저에서 직접 접근을 막음. index.jsp를 여기에 넣으면 servlet에서
redirect/forward했을 때만 볼 수 있음. 서블렛 버전 등 명세를 직접 보여지지 않도록.
jsp view들을 여기에 넣어놓고 servlet에서 응답하는 애들만 볼 수 있게 함.
- web-inf 밑의 views
## log4j 설정 (logger)
로그 레벨 어떤 설정으로 쓸 것인지
가장 중요한 것은 root logger — info 레벨 console을 쓰겠다.
spring 모니터링을 위한 logger도 설정되어 있음 — application logger
탬플릿에서 사용하는 패키지는 spring config인 이상, 구조는 무관하다.
ex. org.example의 config에 설정해도 spring 세팅이 되고, org.scholar에 config 설정해도
spring 세팅이 된다. configuration annotation을 root config로 잘 설정했느냐가 중요함.
## Config
### rootConfig
rootConfig — spring import 하고 spring configuration을 사용할 것임.
root config를 한 다음부터는 spring을 쓰게 되는 것임. 딴 config없이 rootConfig만 존재하게 되면,
spring web이 아닌 spring만을 쓰게 되는 것.
그래도 앱은 돌아감. spring을 쓰긴 썼지만 다른 자바 파일도 동작할 수 있기 때문에.
configuration은 해도 spring bean들을 만들어놓지는 않은 거라서, application context만 있고
그 밑의 모듈들은 모두 없는 상태인 것임.
### webConfig & servletConfig
spring web mvc를 구축했을 때, 웹요청을 가장 먼저 받는 객체가
dispatcher servlet = front controller
이를 위해서 webconfig가 있음. 웹에서 사용할 bean이나 view들을 맵핑하고 인코딩은 어떻게 할 것인지
등등을 설정함.
`AbstractAnnotationConfigDispatcherServletInitializer` 에 원래 있던 내장된 기능인데,
이걸 override로 커스터마이징해서 사용함.
ex. getRootConfigClasees: dispatcher servlet에서 → spring을 달아줌.
ex. getServletConfigClasses: 서블렛에 대해서도 config를 해줌. spring web에서는
자바가 돌아가야 함. 톰캣(=서버)은 서블렛(서비스의 대상)을 서비스하는 기능이 있음.
이 내장 기능을 사용하는 것. 그 서블렛에 대해서 커스터마이징(=설정, config)해서 쓰는 것이다.
원래 서블렛을 서비스하는 주체는 톰캣. 그 톰캣의 기능을 webconfig에서 설정한다.
“servlet에서 서비스할 때는 이러이러한 자바 로직을 실행할 수 있어야 해. “
**“다른 말로, 스프링에서 서블렛을 서비스하는 기능을 추가한 것이다. 원래 spring core에는
웹 서비스 기능이 없지만, spring web 모듈을 장착해서 쓰기 때문에 웹 서비스가 가능해짐. ”**
cf) 레스토랑에서 (서빙하는 사람 = 서버)를 부른다. 서빙하는 사람 = 서버, 내가 요청(=request)
부를 수 있는 사람. 요청을 받고 응답을 하는 주체가 서버.
servlet config를 작성해서 모듈을 만들어놓고 그거를 등록해서 쓰는 것이 webconfig이다.
cf) webconfig vs servlet config
나머지 servlet들에 해당하는 config를 모아놓은 것이 servlet config
// web 전반에 대한 config를 모아놓은 것이자, 핵심인 dispatcher servlet을 설정하는 것이
servlet config
- 스프링의 기본 개념: 조립을 해서 쓴다.
rootConfig(application context)에 webConfig와 servletConfig를 조립해서 쓴다.
그것을 해주는 것: 자바 프로그램. 클래스(spring application context)가 돌아갈 때,
조립이 되는 것이다. 동적으로 의존성이 주입된다. 프로그램이 실행될 때 미리 bean들을 등록해놓고,
bean들을 조합해서 spring이 동작한다.
spring에는 core가 있고, web 기능을 추가해서 쓴다.
web을 달게 되는 순간, dispatcher servlet이 요청과 응답을 책임 지는 부품이 된다.
우리가 webconfig 모듈을 config하는 순간부터 ‘web 기능’이 생긴 것이다.
이는 마치 마더보드가 spring의 역할이고, 안에 있는 그래픽카드나 ram 등의 부품이
spring bean들이 된다.
그 위에다 servlet config를 추가해서 servlet 기능을 단다면, 스프링의 servlet 서비스 기능이
조립된 것이다.
config가 어느 패키지에 있어도 상관없다. annotation만 잘 달고 spring이 찾을 수만 있다면 위치는
무방함. annotation을 다는 순간 singleton 객체가 되고 프로젝트 전체에 작용되기 때문이다.
ex. @component → component 클래스가 됨. 앱이 실행될 때 컴포넌트 인스턴스가 생기고,
application context에 등록되게 됨. 그 등록된 인스턴스에 의존성을 주입해서 사용하는 것이다.
그 제어를 spring이 담당하는 것이다.
rootConfig가 한번 spring에 등록되면 그때부터 spring을 쓸 수 있게 됨.
cf) 왼쪽 사이드바 more tool - spring을 선택해서 확인할 수 있음.
결국, spring web을 쓰기 때문에 servletconfig, webconfig가 필요한 것이다.
이 이후부터 controller package를 만들어서 컴포넌트를 만들어서 스프링에 등록해줌.
그러면 그 제어는 스프링의 몫. 컨트롤러들은 spring web 모듈의 controller들이 등록되어 있음
이 전까지의 과정을 템플릿화함.
- 템플릿화하기
new projects setup — save project as template
## AOP: aspect oriented programming
db에 트랜젝션을 생성하고 끊는 것은 부관심사(부가로직인 aspect, 부관심사를 aspect라고 자주 지칭함),
user table에 user를 넣는 것이 주관심사
db에 로그인을 한 상태로 트랜젝션을 만들고 로그를 남기는 것은 항상 동작하는 부관심사.
횡단로직 crosscutting logic
ex. exception 처리
AOP → advice: 전처리 혹은 후처리 = 대부분의 주관심사 전이나 후에 공통적으로 적용될 수 있는 것들.
프로그래밍할 때 어떤 패러다임을 쓸지만 생각하면 됨.
cf) 객체 지향과 관점 지향
객체 지향은 객체들이 존재한다는 패러다임(커먼센스, 정말 기본적인 상식)으로,
관점 지향은 관점이 존재한다는 패러다임으로 바라봄. 관점 지향에서는 메인 관심사와
crosscutiing 관심사(부관심사)
수평적 = 넓게, 한국인의 횡단 관심사(수저), 미국인의 횡단 관심사(포크 = 항상 그렇게 먹음).
모든 나무를 일렬로 나열해놨을 때 한번에 쫙 적용시킬 수 있는 것. = 수평으로 쫙 그어버림.
## application properties
환경변수를 나열한 파일. 파일로 만들어놓는 이유는, 환경변수를 갈아끼우기만 하면
새로운 환경변수로 사용할 수 있기 때문이다.
## connection pool - HikariCP
HikariCP: connection pool을 사용할 수 있게 해주는 라이브러리 중 하나.
미리 thread를 준비해놓음. db 접근에 대해서 thread가 즉각처리할 수 있도록 connection pool을
만들어놓음. .
ex. default pool size = 10 - transaction(데이터베이스의 상태를 변화시키는 일련의 연산들을
하나의 작업 단위로 묶는 것) 처리를 위해 10개의 스레드를 마련해놓는다.
db pool을 미리 만들어놓는다는 것은, ‘통로’라고 생각해놓을 것. pool이 요청할 때만 열리면
차단기 올리고 내려가는 시간이 너무 아까움. 하이패스로 10차선이면 쾌적하게 빠른 속도가 가능해짐.
미리 마련해놓는 통로라고 생각하자.
## jackson
java 객체가 문자열이 아님. 사람이 읽고 쓰기 편하게 json으로 변환해야 함. —> 그걸 jackson이 해줌.
뷰(웹문서 중 html)와 유사하게 json(text) 만으로도 응답이 가능함.
## bean (동작 원리)
자바에서 클래스, 인스턴스가 있음. 앱 실행 전에는 클래스가 있고 앱을 실행할 때 new 키워드로
인스턴스를 만들어냄. 실체화하는 것이다. 프로그램은 메모리에서 임시저장해가면서 실행되는 것.
프로그램이 꺼지면 만들어졌던 인스턴스가 사라진다.
미리 인스턴스들을 프로그램 시작하자마자 메모리에 올려놓음. 컴포넌트 annotation만 써도 스프링에서
다 만들어놓음. 이 bean들은 프로그램이 동작하는 중에 무조건 계속 존재함. 내가 만든 클래스로
객체가 하나밖에 없는 singleton에서도 마찬가지.
의존성을 주입했다 뽑았다, 즉 프로그램에서 뺐다 꼈다 하면서 사용할 수 있음. 조합해서 !!
의존성을 주입을 안해도 스프링에서 미리 등록해놓은 것이므로 레고 부품처럼 들어가는 있는 상태.
그걸 조합하는 게 의존성 주입(레고 부품 끼우기) ⇒ 클래스를 선언할 때가 아니라, setA, setB 등
동적의 방식으로.
혼자 보려고 만든 기록장 | 또또는 귀여워 🐈⬛