일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- @AspectJ
- spring
- 프로퍼티
- Framework
- java spring
- Dependency Injection
- java
- JdbcTemplate
- Spring JDBC
- Linux
- 마이바티스
- STS
- 리눅스
- spring framework
- pointcut
- XML
- SpringJDBC
- Ubunt
- spring aop
- myBatis
- Spring Boot
- unix
- AOP
- 컨테이너
- JDBC TEMPLATE
- Di
- @JUnit
- @Spring-Test
- POJO
- @test
- Today
- Total
목록2024/10 (54)
개키우는개발자 : )
결론 및 요약팩토리 메서드를 사용하여 Java 코드로 스프링 빈(Bean)을 등록하고 의존성을 주입하는 방법을 다뤘습니다. 또한, 이를 구성하는 스프링 컨테이너에서의 구성 정보 처리 방법을 학습했습니다. 이는 스프링 애플리케이션에서 좀 더 유연하고 복잡한 빈 생성 및 의존성 주입을 지원하기 위해 사용될 수 있습니다.주요 내용 요약팩토리 메서드를 통한 빈 생성:스프링에서 제공하는 팩토리 메서드는 자바 메서드를 사용해 오브젝트를 생성하고, 이를 빈으로 등록할 수 있는 방식입니다.예를 들어, HelloController와 HelloService와 같은 빈 오브젝트를 팩토리 메서드에서 생성하여 스프링 컨테이너에 등록할 수 있습니다.팩토리 메서드의 이점:복잡한 빈 초기화: 복잡한 초기화나 의존성 주입이 필요한 경..
결론 및 요약서블릿 컨테이너의 초기화 작업을 스프링 컨테이너의 초기화 과정에 통합하는 방법을 다뤘습니다. 이전에는 서블릿 컨테이너와 스프링 컨테이너의 초기화 작업이 별도로 이루어졌으나, 이번에는 스프링 컨테이너가 자동으로 서블릿 컨테이너를 초기화하도록 코드 구조를 변경했습니다.주요 내용 요약두 파트로 나뉘었던 초기화 작업:첫 번째 파트는 스프링 컨테이너(SpringContainer) 초기화 및 Bean 등록 작업.두 번째 파트는 서블릿 컨테이너(Servlet Container) 초기화 및 DispatcherServlet 등록 작업.이제 이 두 작업을 하나로 통합하여 스프링 컨테이너가 초기화되는 과정에서 서블릿 컨테이너의 초기화 작업이 자동으로 이루어지도록 설정했습니다.Spring의 onRefresh 메소..
결론 및 요약컨트롤러 클래스 내부에 맵핑 정보를 애노테이션으로 직접 추가하여, 더 간결하게 웹 요청을 처리하는 방법을 배웠습니다. 기존에 서블릿 코드에서 맵핑 작업을 수동으로 처리하던 방식을 스프링의 애노테이션 기반 맵핑으로 전환하는 작업을 했습니다. 이를 통해 코드가 훨씬 간결해지고, 스프링이 제공하는 자동 맵핑 및 바인딩 기능을 활용할 수 있게 되었습니다.주요 내용 요약애노테이션 기반 맵핑:@GetMapping, @RequestMapping 등의 애노테이션을 사용하여, 웹 요청을 처리할 컨트롤러 메소드에 대한 URL 및 HTTP 메소드 매핑을 설정했습니다.RequestMapping을 클래스 레벨에 선언하면, 그 클래스 내부의 메소드들이 URL을 처리하는 기본 경로를 지정하게 됩니다.메소드 레벨에 선언..
결론 및 요약DispatcherServlet을 도입하여, 기존에 우리가 직접 작성했던 서블릿 코드와 맵핑 작업을 제거하고 스프링의 전통적인 서블릿 컨트롤러인 DispatcherServlet이 이를 대신 처리하도록 구현하였습니다. 이를 통해 Servlet Container-less 애플리케이션으로의 전환을 진행했습니다.주요 내용 요약기존 서블릿의 복잡성 제거:이전에는 FrontController 서블릿을 직접 작성하여 모든 웹 요청을 처리하고, 매핑을 수동으로 설정했지만, 이번 시간에 DispatcherServlet을 사용함으로써, 이 복잡한 작업을 대신 처리하도록 하였습니다.이를 통해 서블릿을 다루는 복잡한 코드를 단순화할 수 있었습니다.DispatcherServlet의 역할:DispatcherServl..
결론 및 요약스프링 컨테이너를 이용하여 의존성 주입(Dependency Injection, DI)을 구현하는 방법을 학습했습니다. HelloController와 SimpleHelloService 간의 의존 관계를 인터페이스를 통해 관리하고, 스프링 컨테이너가 이를 자동으로 처리하여 개발자가 의존성을 명시적으로 관리하지 않아도 되도록 만들었습니다.주요 내용 요약인터페이스 도입 및 의존성 분리:기존 SimpleHelloService 클래스는 인터페이스를 구현하지 않았으나, 이를 HelloService라는 인터페이스로 추상화하였습니다.HelloService 인터페이스는 sayHello 메소드를 정의하고, SimpleHelloService는 이를 구현하는 방식으로 변경하였습니다.이렇게 인터페이스를 도입하면, H..
결론 및 요약스프링의 핵심 개념인 의존성 주입(Dependency Injection, DI)에 대해 학습했습니다. DI는 클래스 간의 의존 관계를 효과적으로 관리하여 코드의 유연성과 재사용성을 높이는 방법입니다. 스프링 컨테이너가 DI를 통해 객체들 간의 관계를 설정하고, 개발자가 직접 의존성을 관리하지 않아도 자동으로 객체를 주입하도록 구성할 수 있습니다. 이로 인해 코드가 더 모듈화되고 변경에 대한 유연성이 확보됩니다.주요 내용 요약의존성 주입(DI) 개념:클래스가 다른 클래스에 의존할 때, 직접 인스턴스를 생성하는 대신 외부에서 필요한 객체를 주입받는 방식입니다. 이로 인해 클래스 간의 강한 결합을 피하고 유연한 코드 작성이 가능합니다.HelloController가 SimpleHelloService..
결론 및 요약스프링 컨테이너를 사용하여 애플리케이션에서 객체를 효율적으로 관리하고 재사용하는 방식을 배웠습니다. 특히, 싱글톤 패턴을 적용하여 중복된 객체 생성을 방지하고, 기존의 HelloController의 역할을 분리해, SimpleHelloService라는 서비스 객체를 통해 비즈니스 로직을 위임하는 방식으로 개선했습니다. 이를 통해 코드의 유지보수성을 높이고 책임을 분산시켜 더 효율적인 구조를 만들었습니다.주요 내용 요약스프링 컨테이너의 역할:스프링 컨테이너는 객체를 생성하고 관리하며, 객체를 한 번만 생성하여 재사용하는 방식으로 동작합니다. 이를 통해 여러 요청이 동일한 객체를 사용하게 되며, 이는 싱글톤 패턴과 유사한 효과를 제공합니다.getBean() 메소드를 사용해 스프링 컨테이너에 등록..
결론 및 요약스프링 컨테이너를 활용하여 독립 실행이 가능한 스프링 애플리케이션을 만들었습니다. 기존 Servlet 기반의 애플리케이션에서 직접 객체를 생성하고 관리하던 방식에서, 스프링 컨테이너를 통해 객체를 생성 및 관리하고 이를 필요할 때 가져와 사용하는 방식으로 전환했습니다. 이를 통해 더 유연하고 관리하기 쉬운 애플리케이션 구조를 구축할 수 있었습니다.주요 내용 요약스프링 컨테이너와 Servlet 컨테이너의 역할 분리:Servlet 컨테이너는 여전히 HTTP 요청을 처리하고 응답을 생성하는 역할을 맡지만, 객체(빈)의 생성과 관리는 스프링 컨테이너가 담당하게 되었습니다.기존에는 FrontController가 직접 객체를 생성하고 관리했지만, 이제는 스프링 컨테이너가 이 역할을 맡으며, 스프링 컨테..
결론 및 요약FrontController 패턴을 적용하여, 모든 웹 요청을 중앙에서 처리하고 이를 개별 로직으로 위임하는 방식으로 코드를 개선했습니다. 이를 통해 로직을 분리하고 재사용성을 높였으며, 웹 요청과 관련된 공통 기능을 처리하는 구조를 확립했습니다. 또한, 스프링 없이 순수 서블릿을 사용하여 독립적으로 실행 가능한 프론트 컨트롤러 시스템을 구축했습니다.주요 내용 요약FrontController와 로직 분리:모든 요청을 FrontController가 받아 처리하는 구조를 만들었습니다. 기존의 /hello와 같은 요청을 단일 서블릿에서 처리하던 방식에서, 요청을 처리할 핸들러로 분리하여 로직을 관리하는 방식으로 전환했습니다.HelloController와 같은 로직은 독립적으로 분리되었으며, Fro..
결론 및 요약프론트 컨트롤러 패턴을 적용하여 중앙에서 모든 요청을 관리하고, 각 요청을 적절한 핸들러로 전달하는 방식을 구현했습니다. 기존의 개별 서블릿 방식에서 벗어나, URL과 HTTP 메소드에 따라 요청을 처리할 수 있도록 프론트 컨트롤러가 요청을 분기하는 역할을 맡습니다. 이를 통해 공통된 작업을 중앙에서 처리하고, 더 유연한 요청 처리 로직을 구현할 수 있게 되었습니다.주요 내용 요약프론트 컨트롤러 도입:기존에는 각각의 서블릿이 특정 URL에 맵핑되어 그 요청을 직접 처리했으나, 프론트 컨트롤러를 도입함으로써 중앙에서 모든 요청을 받아 처리하게 되었습니다. 이를 위해 슬래시("/") 이하의 모든 요청을 프론트 컨트롤러가 처리하도록 설정합니다.요청의 분기 처리:프론트 컨트롤러는 요청을 받아 URL..
결론 및 요약프론트 컨트롤러 패턴은 여러 개의 서블릿을 일일이 관리해야 하는 불편함을 줄이고, 중복된 코드 문제를 해결하기 위해 등장한 패턴입니다. 이를 통해 각 서블릿에 분산되어 있는 공통 작업을 중앙에서 처리하고, 각기 다른 요청을 적절한 핸들러로 위임하여 응답을 생성하는 방식으로 웹 애플리케이션을 효율적으로 관리할 수 있습니다.주요 내용 요약서블릿 관리의 복잡성 해결:서블릿을 이용한 개발에서는 각 요청에 대해 별도의 서블릿을 등록하고 맵핑해야 하는데, 이 과정에서 공통적으로 반복되는 코드가 많이 발생합니다. 특히, 여러 서블릿에서 중복된 작업을 처리할 때 이를 효율적으로 관리하는 데 한계가 있습니다.프론트 컨트롤러 패턴의 등장:프론트 컨트롤러는 요청의 공통된 처리를 중앙에서 담당하는 컨트롤러입니다...
결론 및 요약:Servlet에서 응답을 처리하는 방식을 개선했습니다. 하드코딩된 문자열 대신, 스프링에서 제공하는 상수와 enum을 활용해 코드의 안정성과 가독성을 높였습니다. 또한, URL의 쿼리 스트링 파라미터를 이용해 동적인 응답을 생성하는 방법을 배웠습니다.주요 내용 요약:코드 개선:문자열을 직접 입력하는 대신 스프링의 상수와 enum을 사용해 코드의 안전성을 강화했습니다. 예를 들어, Content-Type 헤더는 HttpHeaders.CONTENT_TYPE 상수를 사용하고, 상태 코드는 HttpStatus.OK.value()로 처리했습니다.응답 생성:응답에 포함되는 세 가지 요소는 상태 코드, 헤더, 본문입니다. 상태 코드는 200 OK로 설정하고, 헤더에는 Content-Type: text/..
Spring Boot의 내장형 톰캣 서버를 이용해 Servlet을 등록하고, 이를 통해 서블릿 컨테이너에서 웹 요청을 처리하는 방법을 다루었습니다. 이를 통해 톰캣 서버를 설치하지 않고 간단한 Java 코드로 서블릿을 구현하는 방법을 학습할 수 있었습니다.주요 내용 요약:Servlet 컨테이너 설정:TomcatServletWebServerFactory를 사용하여 임베디드 톰캣 서버를 시작했습니다. 이 클래스는 톰캣 서버를 생성하고 구성하는 작업을 도와주는 팩토리 클래스로, 톰캣 외에도 다른 서블릿 컨테이너를 쉽게 교체할 수 있도록 추상화된 방식으로 작동합니다.서버가 정상적으로 동작하는지 확인하기 위해 8080 포트로 서버를 실행하고, 톰캣이 정상적으로 뜨는지 테스트했습니다. 404 에러는 기본적인 서버 ..
스프링 부트의 컨테이너리스 서블릿 컨테이너 동작 원리를 이해하고, 이를 코드로 구현하는 내용을 다룹니다. 복잡한 서블릿 컨테이너 설치 및 설정 과정을 자동화하고, 개발자가 서블릿에 집중할 수 있게 해주는 스프링 부트의 특징을 설명합니다. 아래는 이 내용을 요약한 설명입니다.주요 내용 요약:서블릿 컨테이너리스 구조:서블릿 컨테이너(Tomcat 등)를 별도로 설치하지 않고도, 애플리케이션 내에서 자동으로 실행할 수 있는 방법을 설명합니다.개발자는 서블릿 컨테이너 설정이나 배포를 신경 쓸 필요 없이, 애플리케이션 코드(빈, 컴포넌트) 작성에 집중할 수 있습니다.Tomcat을 코드로 시작하기:Tomcat을 메인 메소드에서 직접 시작하는 방법을 설명하며, 이를 통해 서블릿 컨테이너를 코드로 실행합니다.Embedd..
스프링 부트의 컨테이너리스 애플리케이션 구조와 동작 원리에 대해 다룹니다. 컨테이너리스를 통해 서블릿 컨테이너와 관련된 복잡한 작업을 자동화하고, 개발자가 애플리케이션 개발에만 집중할 수 있도록 합니다. 아래는 이 내용을 요약한 설명입니다.주요 내용 요약:컨테이너리스(Spring Boot의 특징):스프링 부트는 서블릿 컨테이너와 관련된 복잡한 작업(Tomcat 설치, 배포 설정 등)을 자동으로 처리하여, 개발자가 애플리케이션 코드에만 집중할 수 있도록 돕습니다.서블릿 컨테이너를 설치하거나 XML 설정을 작성하지 않고도, 간단히 메인 메소드 실행으로 스프링 애플리케이션을 구동할 수 있습니다.HelloController 예제:HelloController를 통해 /hello 경로로 요청을 받아 name 파라미..
웹 애플리케이션의 기본 구조:웹 클라이언트(사용자)가 웹 요청을 웹 컨테이너(서버)에 보내면, 서버는 이를 처리할 웹 컴포넌트(컨트롤러 등)를 찾아 요청을 전달합니다.웹 컴포넌트는 요청을 처리하여 응답을 생성하고, 이를 웹 클라이언트에게 반환합니다.웹 요청과 응답은 항상 쌍을 이루며 동작합니다. 요청이 있어야 응답도 발생합니다.HTTP 프로토콜 개요:웹 클라이언트와 서버 간의 통신은 HTTP(Hypertext Transfer Protocol) 프로토콜을 통해 이루어집니다. 이 프로토콜은 요청과 응답의 구조를 정의하고, 이를 기반으로 양쪽이 대화할 수 있도록 합니다.요청과 응답은 구조가 매우 유사하며, 첫 번째 줄에 중요한 정보가 포함되고 그 뒤로 헤더와 바디가 따라옵니다.HTTP 요청 구조:첫 줄: 요청..
우리가 만든 컨트롤러가 기대대로 정상적으로 동작했지만, 이런 테스트가 브라우저 화면에서만 가능한지, 그리고 이것만으로 충분한지 고민해볼 필요가 있습니다. 사실 웹 애플리케이션은 HTTP 요청과 응답의 다양한 과정이 필요하며, 이를 정확히 테스트해야 전체 기능을 확인할 수 있습니다.HTTP API 테스트 방법:브라우저 개발자 도구를 이용한 테스트크롬 개발자 도구를 열면, HTTP 요청과 응답의 헤더, 바디 정보를 확인할 수 있습니다.헤더 정보는 요청 및 응답 시 중요한 구성 요소이며, 특히 Content-Type 헤더는 응답이 HTML, JSON, 텍스트 중 어떤 형식인지 알려줍니다.cURL을 이용한 테스트cURL 명령어를 사용해 커맨드라인에서 HTTP 요청을 보내고 응답을 확인할 수 있습니다.curl -..
IntelliJ에서 프로젝트 불러오기IntelliJ IDEA에서 프로젝트 열기IntelliJ IDEA를 열고, 파일 → Open 메뉴를 선택하여 프로젝트가 있는 폴더를 불러옵니다.또는 커맨드 라인에서 IntelliJ를 실행하는 명령을 통해 현재 폴더를 오픈할 수 있습니다.프로젝트 구조 확인IntelliJ에서 프로젝트 구조가 잘 보이는지 확인합니다. 이 구조는 Spring Initializer를 통해 만든 것과 동일해야 합니다.만약 IntelliJ가 최신 버전으로 업데이트된 상태라면 초기 설정 과정에서 약간의 호환성 문제로 에러 메시지가 뜰 수 있습니다. 그런 메시지는 무시하고 진행해도 무방합니다.간단한 기능 추가이제 간단한 기능을 추가해 보겠습니다. Hello Boot 애플리케이션이니까, /hello라는..
Spring Boot 프로젝트 생성 방법Spring Boot 프로젝트를 만드는 방법은 여러 가지가 있습니다. 여러분이 사용하는 대부분의 방법은 아마도 Spring Initializer를 사용하는 것이 될 텐데요, Spring Initializer는 Spring Boot 프로젝트를 생성해 주는 공식 도구입니다.Spring Initializer 웹사이트 사용웹사이트 주소는 start.spring.io입니다.이 사이트에서 프로젝트의 기본 설정과 필요한 의존성(dependencies)을 선택할 수 있습니다. 설정 후, Generate 버튼을 누르면 프로젝트 템플릿이 ZIP 파일로 다운로드됩니다.여기서 우리는 Gradle과 Java 언어를 선택할 것이며, Spring Boot 버전은 2.7.6을 사용할 것입니다...
SDKMAN 설치 방법과 SDKMAN을 이용한 자바 설치 방법1. SDKMAN 설치 방법SDKMAN은 다양한 SDK(Software Development Kit)를 간편하게 관리하고 설치할 수 있는 도구입니다. 특히 Java 개발 환경에서 유용하며, 여러 Java 버전을 손쉽게 전환하거나 설치할 수 있습니다. SDKMAN 설치 방법은 매우 간단하며, 주로 Unix 계열의 시스템에서 작동합니다.설치 과정:터미널 실행먼저, 터미널을 열어 SDKMAN을 설치합니다.SDKMAN 설치 명령 실행아래 명령을 터미널에 입력하여 설치를 진행합니다:bashcurl -s "https://get.sdkman.io" | bash설치 완료 확인 및 환경 변수 적용설치가 완료되면, 다음 명령을 입력하여 SDKMAN이 정상적으로 ..
스프링 부트 버전 결정강의는 스프링 부트 2.7.6 버전을 기준으로 진행됩니다. 최근 스프링 부트 3.0이 출시되었지만, 변화가 많아 이번 강의는 2.7.6 버전으로 유지됩니다.JDK 버전스프링 부트 버전이 결정되면 JDK 버전도 선택해야 합니다. 스프링 부트 2.7.6에서는 JDK 8, 11, 17 버전을 사용할 수 있습니다.다양한 OpenJDK 빌드를 사용할 수 있으며, Oracle JDK는 유료이기 때문에 Eclipse Temurin, Amazon Corretto, Azul JDK와 같은 무료 OpenJDK 버전을 추천합니다.JDK 관리 도구SDKMAN과 같은 도구를 통해 여러 JDK 버전을 쉽게 관리할 수 있습니다. 이를 통해 다양한 JDK 버전을 설치하고 쉽게 전환할 수 있으며, 프로젝트마다 다..
1. 스프링 부트를 이해한다는 것의 의미스프링 부트를 사용할 때, 모든 기술을 깊이 이해할 필요는 없습니다. 그러나 때로는 그 기술을 이해하는 것이 매우 유익할 수 있으며, 이를 바탕으로 스프링 부트를 더 잘 활용할 수 있습니다.스프링 부트는 이미 검증된 기술과 구성을 제공하므로, 애플리케이션 기능 개발에만 집중할 수 있습니다. 또한, 스프링 부트가 제공하는 외부 설정 파일을 통해 일부 설정을 쉽게 변경할 수도 있습니다.2. 스프링 부트에 대한 오해많은 사람들이 스프링 부트가 모든 기술적 결정을 알아서 해주기 때문에, 애플리케이션 코드만 작성하면 된다고 생각합니다. 그러나 이것은 한계점이 있을 수 있습니다.또 다른 오해는 스프링 부트만 잘 알면 스프링 자체는 몰라도 된다는 생각입니다. 스프링 부트는..
1. opinionated의 의미기본 정의: opinionated는 "자신의 의견을 강하게 고집하는", "독선적인"이라는 뜻을 가지고 있습니다. 스프링 부트가 스스로를 opinionated하다고 소개하는 이유는 개발자가 처음부터 모든 기술적 결정을 직접 하지 않아도, 스프링 부트가 이미 검증된 방식을 제안하기 때문입니다.2. 스프링 프레임워크의 설계 철학유연성: 스프링 프레임워크는 20년 이상 극단적으로 유연한 프레임워크로 알려져 있습니다. 다양한 기술을 통합할 수 있으며, 이로 인해 개발자는 여러 선택지를 가질 수 있지만, 그만큼 많은 결정을 직접 내려야 합니다.다양한 기술의 통합: 스프링은 다양한 기술, 오픈소스, 상용 기술을 모두 수용하는 철학을 가지고 있습니다. 이는 장점이지만, 개발자는 프로..
1. 컨테이너리스란?의미: "컨테이너리스"라는 용어는 단어 그대로 "컨테이너가 없는"이라는 뜻을 가지고 있습니다. 그렇다면 여기서 말하는 컨테이너가 무엇을 뜻할까요? 이 개념은 서버리스(Serverless) 아키텍처와 유사합니다.서버리스와의 유사성: 서버리스 아키텍처는 개발자가 서버의 설치나 관리에 신경 쓰지 않고 애플리케이션 개발과 배포에 집중할 수 있게 하는 방식입니다. 이와 비슷하게, 컨테이너리스는 웹 애플리케이션의 컨테이너를 따로 관리하지 않아도 되도록 돕습니다.2. 컨테이너란 무엇인가?컨테이너의 역할: 전통적인 웹 애플리케이션에서 컨테이너는 웹 컴포넌트를 관리하고 동작시키는 역할을 합니다. 예를 들어, 서블릿 컨테이너는 자바 웹 애플리케이션에서 **서블릿(Servlet)**을 관리하고, 클라..
1. 스프링 부트의 시작출발점: 2012년, 스프링 프레임워크 프로젝트의 이슈 트래커에 "컨테이너리스 웹 애플리케이션 아키텍처"를 위한 스프링 개선 요청이 올라왔습니다. 이는 전통적인 웹 개발 방식이 너무 복잡하다는 문제점을 지적하며, 루비 온 레일스(Ruby on Rails), 노드JS(Node.js), 파이썬 등의 단순한 접근 방식과 비교해 스프링이 복잡하다는 요청이었습니다.2. 스프링 부트 프로젝트의 시작프로젝트의 결정: 스프링 개발자들은 이 요구를 수용하면서, 스프링을 직접 고치는 대신 새로운 프로젝트인 스프링 부트를 시작하기로 결정했습니다.첫 버전 공개: 2013년 8월, 스프링 부트 0.5.0 마일스톤 1(M1) 버전이 공개되었습니다. 이 프로젝트는 빠르게 주목을 받으며, 스프링을 더 쉽고..