Back-end

▶ApplicationContext란? 스프링을 공부할 때 ApplicationContext를 많이 들어봤을것이다. 듣기만 하고 넘기면 안된다. ApplicationContext란 뭘까? 바로 스프링 컨테이너이다. 스프링 컨테이너의 이름이 ApplicationContext이다. 그러면 컨테이너는 뭘까? 컨테이너는 빈의 생명주기를 관리하고, 객체를 어떤 방식(싱글톤, 프로토타입)으로 만들지 정하는 역할을 한다. 즉, 스프링의 핵심이다. 그러면 빈은 뭘까? 빈. Bean은 컨테이너가 관리하는 객체를 말한다. 즉, 빈을 관리하는 컨테이너는 스프링의 핵심이고. 그 핵심인 스프링 컨테이너의 이름이 ApplicationContext 인 것이다. ▷Spring Framework의 핵심모듈 그림을 보면 Core Con..
▶상황 깃허브에서 Repository 만들고 README 파일을 만들어줬다. 그리고 인텔리제이에서 스프링 웹 프로젝트를 만들고 git branch –M main git remote add origin [레포 주소] 이렇게 로컬과 원격를 연결 해 준 후 커밋하고 git push origin main 로컬의 main브랜치의 내용을 원격의 origin으로 push할려고 했는데 ▶문제 발생 이게 뭐람..? $ git push -u origin main To https://github.com/wlaud2000/likelion_shop.git ! [rejected] main -> main (non-fast-forward) error: failed to push some refs to 'https://github.c..
WAS(톰캣)가 Web.xml 파일을 통해서 서블릿을 찾듯이 DispatcherServlet도 /WEB-INF/”서블릿이름”-servlet.xml 파일을 통해서 파일에 설정된 친구들과 함께 요청을 처리하게 된다. 우선 톰캣이 서블릿을 찾고, DispatcherServlet한테 처리해달라고 하면 DispatcherServlet은 이러쿵저러쿵 잘 해서 사용자한테 응답화면을 보여준다는건데... 과연 이게 어떻게 이루어질까? 궁금해졌다. ▶ /WEB-INF/”서블릿이름”-servlet.xml 파일 서블릿이 가지고있는 설정 파일이다. "서블릿이름"부분은 Web.xml에 작성해주면 된다. ▶Controller 스프링이 지원해주는 혜택을 받기위해서는 내가 만든 클래스들을 Bean으로 등록해야한다. 빈은 빈태그를 사용..
저번 포스팅에서 Servlet의 문제점으로 각 Servlet의 service() 메서드에서 중복되는 부분이 많다. Servlet에 종속적인 구조를 가진다. 이후, 각 컨트롤러에서 공통으로 처리해야하는 로직이 생기면 중복이 발생한다. 이렇게 3가지의 문제점이 있다고 말했다. 어떻게 이 문제점을 해결할 수 있을까? 그전에 Front Controller패턴에 대해서 알아 볼 필요가 있다. ▶Front Controller란? 클라이언트 요청을 받는 최앞단에 모든 요청을 받을 수 있도록 컨트롤러를 하나 만들고 이곳에서 각 요청별로 처리하는 로직을 찾아서 이를 전달해 요청을 수행하도록 하는 방법이다. Front Controller 패턴을 활용한 구조를 통해서 매 요청마다 각각의 서블릿을 사용하는 것이 아닌 하나의 ..
▶ Servlet이 나온이유 초기 웹 서비스는 정적데이터만 전달 할 수 있었다. 사용자(요청)에 따라 다른 처리를 해줄 수 없었다. 동적인 처리를 해주는 웹 애플리케이션이 없었다. ▷ 그래서 나온것이 CGI(Common Gateway Interface) CGI는 동적데이터를 처리해준다. Web Server와 프로그램사이의 규약이다. 점점 CGI사용자가 증가하기 시작했다. 근데 CGI에는 몇가지 비효율적요인이 있었다. ▷CGI의 비효율성 1. Request를 받을 때 마다 Process를 만든다. 같은 요청에도 프로세스를 생성해서 처리하는 구조는 상당한 비효율성을 낳았다. 요청이 엄청나게 들어오면 프로세스가 순식간에 늘어나고 서버가 죽어버리게 된다. 코드와 공유 데이터 정적인 영역은 공유하고, 스택과 힙 ..
▶GitHub Action이란? GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화 할 수 있는 CI/CD 플랫폼이다. GitHub Repository가 있다면 GitHub Action을 사용하여 workflow를 구성할 수 있다. GitHub Actions는 단순한 DevOps를 넘어 Repository에서 다른 event가 발생할 때 workflow를 실행할 수 있도록 한다. ▶ GitHub Action 구성요소 ▷ Workflows Workflows는 GitHub Actions의 기본 구성 단위이다. 일반적으로 “.github/workflows/[이름].yml” 파일에 정의된다. Workflows는 하나 이상의 작업을 포함할 수 있으며 Repository에서는 push 또는 pu..
LearningStudy
'Back-end' 카테고리의 글 목록 (2 Page)