MVC패턴이 생겨난 이유 > 원래 하나의 서블릿이나 JSP로 다 처리했었는데 이렇게 하나로 다 모아두면 유지보수도 힘들고 비효율적임 > 그래서 JSP로 처리하던 것을 컨트롤러(Controller)와 뷰(View)라는 영역으로 서로 역할을 나누고 컨트롤러가 HTTP요청을 받고 비즈니스로직을 실행하고 모델은 이제 뷰에 출력할 데이터들을 담아둠 그냥 통이라고 생각하면 됨 그래서 이제 뷰는 모델만 뒤져서 모델에 담겨있는 데이터를 화면에 그리는 일에 집중할 수 있게됨 (html 생성하는 부분) FrontController Overv

(나중에 또 까먹을까봐) 오랜만에 인텔리제이로 프로젝트파일을 열어봤는데 어노테이션들이 한 개도 인식이 되지 않고있었다. build.gralde을 보니 인식이 아무것도 안되고 있었다. https://kth990303.tistory.com/235 구글링 끝에 위의 블로그를 찾았고 임의적으로 build.gralde에 변화를 주어 새로고침 하게 했고 이후에 정상적으로 어노테이션들을 인식하는 것을 확인할 수 있었다.

배포 + DNS aws로 배포 하고 DNS 설정하는 것 까지는 https://steady-coding.tistory.com/625 이 분을 따라했다! (보안그룹->인바운드 규칙 에서 443port도 잊지말고 추가해줘야함) >- DNS를 설정하는 이유 (출처 : 위의 분 블로그 중 발췌) DNS 설정 전에는 EC2의 퍼블릭 아이피를 이용해 스프링과 통신 중 -> 하지만 외부에 퍼블릭 아이피를 공개하는 것은 위험하고, 숫자로 된 아이피를 기억하기 어려움 -> 따라서 아이피를 우리가 보기 쉬운 문자 형태인 도메인으로 바꿈 -> 이때 아이피를 도메인으로 바꿔 주고, 도메인을 다시 아이피로 변환하는 시스템을 DNS라고 함 배포 과정 MAC은 pem 키가 존재하는 디렉토리 경로로 이동한 다음 ssh -i Lionz.pem ubuntu@13.~ sudo apt update sudo apt install openjdk-17-jdk // 배포할 소스 코드 clone $ git cl

상황 일단 현재 스프링부트 버전은 3.0.2이다. Swagger랑 연동시키려면 (연동이라는 표현이 맞는지는 모르겠는데) springfox vs springdoc 둘 중 하나를 쓴다고 하는데 스프링부트 버전이 올라오면서 springfox는 그에 맞춰 업데이트가 잘 안되고 springdoc이 업데이트가 잘 돼서 springdoc을 쓴다고 한다. 아무튼 구글링을 해도 스프링부트버전이 2.x 인 것들만 많이 나와서 정보가 많이 없어서 SwaggerConfig파일도 추가하고 이런저런 의존성들도 추가했었는데 결국 답은 하나였다 방법 : 의존성 추가 (단 한 줄) build.gradle 의존성 부분에 요거 하나 추가해주면 다른 설정없이 http://localhost:8080/swagger-ui/index.html 여기로 들어갈 수 있다! 문제점 현재 JWT를 사용중이라 발급받은 토큰 없이는 localhost:8080 이나 localhost:8080/swagger-ui 등

과제공지글(tasknotice),과제(task) 들을 title(제목)이나 explanation(설명) 그 글이나 과제에 딸린 tag의 name으로도 검색이 가능한 기능을 개발한다 기능 설명: Tasknotice는 title,explanation 으로 검색 task는 explanation으로 검색 tag name으로도 검색가능 추가된 부분: Tasknotice와 Task 의 Repository,Service파일에 findByName 메서드 추가 TasknoticeTag와 TaskTag 의 Repository, Service파일에 findByTagName 메서드 추가 AllSearchApiController에서 구현 완료 >tasknotice task도 똑같이 함 >tasknotice_tag ![

No serializer found for class org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer 개발하던 중 위와 같은 에러가 떴다. 상황 > 위와 같은 엔티티에서 tasknotice와 tag를 join해서 결과를 가져오려했다. > 그래서 Repository에 위와 같이 메서드를 만들고 문제 발생 >![](https://velog.velcdn.com/images/97gkswn/po

위 처럼 줄 바꿈해서 쓰고싶으면 저렇게 바꾸기 직전 line에 공백(space)를 넣어주는게 좋다. 저렇게 하지 않으면 에러가 계속 났음..

어떻게 보면 당연한건데 순간 헷갈렸다 @PathVariable로 저렇게 받는다는 것은 저 id라는 변수가 url에 포함되어 있어야한다.

CrudRepository.java안에 이런게 있다 공부예정

1. 아래처럼 도메인 객체를 생성하고 2. Repository 생성하면 (extends JpaRepository) 방금 만들어준 메소드 이름만으로도 알아서 쿼리문을 짜준다 추가예정

@JoinColumn 현재 Task와 Tag가 다대다 관계라 중간에 Task_Tag테이블을 생성해 각각 1대다 & 다대1로 풀어준 상태 @JoinColumn에 있는 name속성은 Task_Tag엔티티 안에있는 task필드를 DB에 어떤 이름으로 저장할 것인가를 의미한다 아래와 같이 Task엔티티에서 id의 name이 task_id라서 그런것이 아니고 근데 Task_Tag는 지금 Task와 연관관계가 있는지 아닌지는 어떻게 알지? ->ferencedColumnName속성 이라는게 있는데 디폴트가 대상테이블의

Tasknotice에 target이라는 필드가 있고 여기에는 파트인 FE or BE가 들어간다 이 때 해당 파트의 Tasknotice만 조회하고 싶은데 그렇게 하기위해서는 Tasknotice Repository에서 JPQL을 작성했어야 했는데 약간 잘못알고 있었던게 있다 select * t from tasknotice t where t.tasknotice_target = FE 로 해야하는 줄 알았는데 DB상에서의 column으로 조회하는게 아니라 객체속 필드이름으로 조회를 하는것 같다 따라서 아래와 같이 >select t from Tasknotice t where t.target = FE 로 해주어야 한다 (왜 "FE"처럼 따옴표가 없어도 되는지는 모르겠다 ![](https://velog.velcdn.c

위와 같이 로그인을 하면 accessToken과 refreshToken이 response로 오게되는데 이 다음부터 "내가 나다" 라는 것을 명시하기 위해 Authorization에서 Type을 Bearer Token으로 설정한 후 "accessToken"을 넣어주면 된다 accessToken: 유효기간 짧음 refreshToken : 유효기간 김 그래서 accessToken 유효기간이 끝나면 refreshToken을 통해 재발급 받음 반대로 access는 유효한데 refresh가 끝나면 access를 통해 재발급 받음

어차피 따라한거지만 복잡해서 까먹을까봐 적어놓는 구현흐름 장고했을때 회원가입 + 로그인 구현하는것은 그렇게 복잡하지 않았던 것으로 기억한다. 하지만 스프링 하면서 로그인을 해보려니 너무 복잡하고 어려웠다.. 버전 신경써야하고 deprecated된 것들이 꽤 많아서 애를 먹었다. 구글링해도 괜찮은 참고자료를 찾기 어려웠는데 우연히 https://velog.io/@tank3a/Security-%EC%84%A4%EC%A0%951 를 알게되었고 이 분을 통해 아래링크의 블로그를 알게되었다 >https://bcp0109.tistory.com/301 이 블로그가 최고인것같다 폴더 구조 >우선 현재 폴더구조는 아래와 같다 원래 하던 프로젝트에 로그인을 구현하기위해 추가한것 들이 많아 무엇을 추가했었는지 작성하도

엔티티매니저팩토리가 요청이 올대마다 엔티티매니저를 생성해서 줌 영속성 컨텍스트란 뭘까? 엔티티를 영구 저장하는 환경이라는 뜻 근데 DB에 저장한다는게 아니고 영속성 컨텍스트에 저장하는것임 persist 하면 영속상태 em.persist하면 비영속상태였던 객체가 엔티티 매니저 안에 들어가서 영속상태가 됨 app계층과 DB사이에 계층이 하나 더 있다고 보면됨 @Entity 클래스랑 테이블 매핑 name이라는 속성이 있긴한데 기본값으로 클래스이름임 @Table(name="MBR) 하면 DB의 MBR테이블에 매핑이됨 create : drop and create 기존테이블 삭제 후 새로 생성 create-drop : create와 같지만 종료시점에 drop update : 변경분만 적용 (운영DB에는 사용X) validate : 테이블과 매핑이 정상매핑 됐는지만 확인 none : 말 그대로 none 주의 할 점 운영 시 에는 절대 create, crerate-drop, update사용

Entity 엔티티란 데이터 베이스의 테이블과 연결되는 클래스를 의미한다 @Entity 를 이용해 매핑이 가능 영속성 컨텍스트 영속성 컨텍스트란 엔티티를 영구저장하는 환경이다 실제 DB에 가기전에 보관해주는 가상의DB라고 생각해면 된다 임베디드 타입(복합 값 타입) 새로운 값 타입을 직접 정의해서 사용할 수 있는데, JPA에서는 이것을 임베디드 타입(embedded type)이라 합니다. 중요한 것은 직접 정의한 임베디드 타입도 int, String처럼 값 타입이라는 것입니다. '1' 대 '다' 관계에서는 무조건 '다'쪽 테이블에 외래키(FK)가 존재한다 방향 둘 중 한 쪽만 참조한다면 단방향 관계 양쪽 모두 서로 참조하는 것은 양방향 관계 객체를 양방향 연관관계로 만들면 연관관계의 주인을 정해야 한다. 참고: 외래 키가 있는 곳을 연관관계의 주인으로 정해라. > 연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로

웹 서버와 웹 애플리케이션 서버 요즘 시대에서는 대부분 HTTP프로토콜로 모든 데이터와 메시지를 전달한다 Web Server는 정적 리소스를 제공한다 -> 이 말은 서버에 이미지나 데이터 같은 것들을 두고있고 HTTP로 요청이 오면 서버에서 HTTP로 응답을 해준다는 말 WAS (Web Application Server) -> 정적리소스 제공 + 웹 서버 기능 정적리소스(HTML,이미지 등)은 Web server가 처리하고 동적리소스 처리 같은게 필요하면 WAS가 처리하게끔 함 클라이언트가 요청-> 정적인것은 web server가 다 처리함/ 어 근데 동적인 로직이 필요하네? -> WAS한테 넘김 ![](https://velog.velcdn.com/images/97gkswn/post/c212e

스코프란? 스프링빈이 존재 할 수 있는 범위를 의미함 스코프 종류 싱글톤 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토타입 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다. 웹 관련 스코프 request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다. session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다. application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.

초기화 = 객체 다 만들어지고 의존관계다 생성되고나서 처음으로 뭔가 제대로 실행되는것 그래서 의존관계 주입이 완료되면 스프링은 스프링 빈에게 이제 초기화(앱을 이제 사용하라) 하라고 콜백메서드를 통해 알려줌 또 소멸할 때도 소멸콜백을 줌 >- 스프링 빈의 이벤트 라이프사이클 스프링 컨테이너 생성 ->스프링 빈 생성 의존관계 주입 ->초기화 콜백(이제 주입까지 끝났으니 사용해)-> 사용 ->소멸전 콜백 ->스프링 종료 객체의 생성과 초기화 분리 생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는등 무거운 동작을 수행함 따라서 분리하는게 유지보수 측면에서 좋다 @PostConstruct, @PreDestroy 이거 두 개 사용하면됨 의존관계 주입 끝나면 @PostConstruct 붙은 메서드를 실행하고 소멸전에는 @PreDestroy 붙은 메서드를 실행하게됨

다양한 의존 관계 주입 방법 생성자 도입 ComponentScan 할 때 OrderService가 @Component 붙어있으니 컨테이너에 등록을 해줄텐데 그 때 생성자가 호출이 되고 생성자를 호출할 때 @Autowired가 있네 하면서 스프링 컨테이너 에서 MemberRepository랑 DiscountPolicy 이 두 스프링빈을 꺼내서 딱 주입해줌 getter setter로 접근하게 해놓으면 에러가 발생 할 확률이 높아서 getter setter로 접근하게 하면 안됨 참고로 생성자가 한 개만 있으면 @Autowired 생략가능함 수정자 주입(setter 주입) ![](https://velog.velcdn.com/images/97gkswn/post/a33863fa-a29c-48bd-8d64