ApplicationContext 초기화 중에 CommandLineRunner와 ApplicationRunner 인터페이스를 구현한 빈들이 등록됨
이 빈들은 애플리캐이션 초기화가 완료된 후 추가 작업을 실행할 수 있음.
6.자동설정(Auto Configuration)
Spring Boot는 @EnableAutoConfiguration을 통해 여러 자동 설정 클래스(AutoConfiguration)을 활성화함.
자동 설정은 클래스 패스 및 환경 변수를 기반으로 애플리케이션에 필요한 빈을 자동으로 구성함.
Ex) DB Connection 설정, Web server 설정, Spring Security 설정 등
7.빈(Bean) 등록 및 DI(의존성 주입)
스프링 애플리캐이션 컨텍스트 내에서 모등 @Component, @Service. @Repository, @Controller 등의 빈을 스캔하여 등록
등록된 빈들 간의 의존성을 주입(생성자, 세터, 필드 기반)
프로파일 조건에 따라 특정 빈만 활성화될 수도 있음.
8.내장 웹서버 시작(Optional)
웹 어플리케이션인 경우, Spring Boot는 내장된 톰캣, 제티, 언더토우 등을 통해 HTTP서버를 시작
HTTP 포트, SSL설정 등이 적용됨.
서블릿 컨테이너가 초기화 되고 DispatcherSErvlet이 설정됨.
9.Spring MVC 또는 WebFlux 설정(웹 애플리케이션인경우)
DispatcherServlet을 통해 요청을 처리하는 기본 매핑을 설정
HandlerMapping,HandlerAdapter,ViewReolver등을 초기화 하여 웹 요청에 필요한 구성요소를 준비
10.이밴트 발행 및 리스너 실행
Spring Boot는 애플리케이션 실행 과정에서 여러 이벤트를 발행함.
ApplicationStartingEvent
ApplicationEnvironmentPreparedEvent
ApplicationPreparedEvent
ApplicationStartedEvent
ApplicationReadyEvent
위 이벤트를 통해 특정 시점에 사용자 정의 작업을 실행할 수 있음.
11.애플리케이션 준비 완료
애플리케이션 컨택스트 초기화가 완료되고, 모든 빈이 생성되고 초기화됨
CommandLineRunner 및 ApplicationRunner구현체가 실행됨.
ApplicationReadyEvent 가 발행되며 애플리케이션이 요청을 처리할 준비가 완료됨
12.애플리케이션 실행 상태 유지
Spring Boot는 실행 상태를 유지하며 HTTP요청을 대기하거나 비웹 애플리케이션에서는 작업을 지속함.
내부적으로 애플리케이션 컨택스트는 필요에 따라 라이프 사이클을 관리함.
13.애플리케이션 종료
애플리캐이션 종료시 Spring Boot는 ApplicationContext를 닫으며 빈의 destroy() 메서드 호출 및 리소스 정리를 수행
ApplicationFailedEvent 가 발행될 경우 애플리케이션 시패를 기록
Spring Boot Application으 LifeCycle에 대해 간략하게 정리 해 보았다. Spring 기반의 서비스를 운영 / 개발 하는 회사라면 자주 나오는 질문이니 숙지하고 있으면 좋다. 세부 내용까지는 힘들더라도 1~12번 넘버링 되어있는 순서만이라도 기억하면 좋다.
With the recently achievedstability of Kotlin Multiplatform, development teams worldwide can now seamlessly and confidently adopt it in production. However, this is just the beginning for KMP and its ecosystem. To equip you with the best cross-platform development experience, JetBrains aims to deliver a host of further improvements to the core Kotlin Multiplatform technology, Compose Multiplatform, KMP tooling, and KMP libraries in 2024. Read on to learn what we’re planning and our priorities in these areas.
최근 완성된 코틀린 멀티플랫폼의 안정성 덕분에, 세계의 많은 개발팀들은 이제 장애물 없이 코플린 멀티 플랫폼을 프로덕션에 자신있게 적용할 수 있게 되었다. 하지만 이는 단지 KMP(Kotlin Multiplatform)과 에코시스템을 시작하는것일 뿐이다. 최고의 크로스 플랫폼 개발을 경험을 갖추게 하기 위해서, 2024년에 JetBrains는 핵심 코틀린 펄티플랫폼기술, 컴포즈 멀티 플랫폼, KMP도구와 라이브러리 같은 미래의 발전을 주도할것이다. 이 분야에서 무엇을 배워야하고, 어떤 순서로 배뭐야할지 알아보자.
We’re dedicated to makingCompose Multiplatforma framework that allows creating beautiful and performant applications that look the same way on all supported platforms. Right now, our main focus is to getCompose for iOS to Beta, but we’re also working on other things. Here’s what we plan to do:
Make all Jetpack Compose core APIs and components multiplatform.
Improve rendering performance on iOS.
Make scrolling and text editing in Compose for iOS apps behave the same as in iOS native apps.
Implement a common API for sharing all types of resources.
Integrate with iOS and Desktop accessibility APIs.
Provide a solution for multiplatform navigation.
Many of the aforementioned improvements benefit Compose for Desktop, as well. In addition, we’re working on improving its stability and evolving it according to the feedback from those who use it in production.
We’ll also continue to explore what’s possible with Compose for Web, specifically with Wasm. Our nearest goal is to promote it to Alpha, which includes:
Allowing you to port your existing apps and reuse all of your common code.
Supporting different screen sizes, orientations, and densities.
Supporting input from a mouse, touchscreen, physical keyboard, or onscreen keyboard.
Improving performance and binary size.
우리는 컴포즈 멀티플랫폼을 만들기 위해 헌신했다. 컴포즈 멀티플랫폼은 우리가 지원하는 모든 플랫폼에서 어플리케이션이 동일하게 동작하고 동일하게 보이도록지원해주는 아름답고 효율적인 프레임워크이다. 지금 당장 우리가 집중하고 있는것은 iOS를 위한 컴포즈 Beta 버전이다. 하지만 우리는 다른것들도 진행하고있다. 아래는 우리의계획이다.
모든 Jetpack Compose 코어API와 멀티플랫폼 컴포넌트 제작
iOS에서의 랜더링 퍼포먼스 향상
iOS 앱용 컴포즈에서의 스크롤링, 문자 수정(text edting) 동작을 iOS네이티브 앱과 동일하게 만들기
모든 타입의 리소스를 공유할 수 있는 공통API 구현
iOS와 데스크탑의 접근성 API 통합
멀티플렛폼 네비게이션을 위한 소루션 제공
앞서 말한 많은 개선사항은 컴포즈 for 데스크탑에도 역시 도움이 된다. 더욱이, 우리는 제품 사용자들의 피드백을 통해서 안정성 향상과 새로운 기능 향상 작업도 진행하고있다.
우리는 또한 컴포즈 for Web, 특히 Wasm에 대한 작업도 지속하고있다. 우리의 가장 가까운 목표는 컴포트 for Web을 알파 버전으로 만드는 것이다. 알파버전엔 다음이 포함된다.
이미 존재하는 앱들의 포팅기능, 공통코드의 재사용 기능.
다양한 화면 사이즈(size, orientation, densitie) 지원,
마우스, 터치스크린, 키보드, 스크린 키보드 지원
퍼포먼스와 용량 향상.
Tooling
We’re committed to providing a great IDE experience for Kotlin Multiplatform. That means not only investing in the core platform and, for example, migrating Kotlin IDE plugin to K2 compiler frontend, but also providing a single tool (Fleet) for all Kotlin Multiplatform targets and codebases where you integrate it, eliminating the need to constantly switch between different IDEs.
We plan to quickly iterate over your feedback aboutusing Fleet for Kotlin Multiplatform development to make sure that we have everything you need for your development experience to be great. Among other things, we’re going to deliver in the following areas:
Enhanced support for Compose Multiplatform, including live preview for common code and visual debugging tools.
The IDE helping you with project configuration.
Unified and enhanced debugging experience for all parts of your Multiplatform project.
우리는 Kotlin Multiplatform을 위한 훌륭한 IDE 환경을 제공하기 위해 최선을 다하고 있습니다. 이는 Kotlin IDE plugin을 K2 compiler frontend 마이그레이팅 하는것 같은 코어 플랫폼 뿐만 아니라 개발자들이 통합하게 될 모든 Kotlin Multiplatform 타겟과 코드베이스를 위한 싱글툴(Fleet)을 제공하여 끊임없는 IDE변경을 제거한다는 의미입니다.
One of the popular Kotlin Multiplatform scenarios is sharing code with the iOS target. We want to focus on the development experience of iOS developers who work with Kotlin Multiplatform frameworks in their codebases.
The main initiative in this area is adirect Kotlin-to-Swift export. It will eliminate the Objective-C bottleneck, allowing for broader Swift language support and more natural exporting of APIs. Additionally, we are creating tools specifically for Kotlin library authors. These tools are designed to improve the compatibility and user-friendliness of Kotlin APIs when exported to Swift. We’re also paying close attention to tooling. The IDE and build systems are essential parts of the developer experience, and our goal is to ensure that the Swift Export integrates smoothly.
Our other initiatives include speeding up Kotlin/Native compilation, enhancing CocoaPods integration, and introducing support for exporting your framework with SwiftPM.
We also plan to continue exploring ways to improve the build setup of Kotlin Multiplatform applications. With Kotlin 1.9.20, we releasedhuge improvementsin the Gradle Multiplatform DSL, making it easier to read and write. We will continue to gradually improve it. In addition, we’re experimenting withAmper, a new project configuration tool focused on usability, onboarding, and IDE support.
Kotlin Multiplatform의 가장 유명한 시나리오 중 하나는 iOS 타겟괴 코드를 쉐어 하는 것 이다. 코드 베이스에서 코틀린 멀티플랫폼 프레임워크를 사용하는 iOS개발자의 경험에 중점을 두고 있다.
이 분야에서의 주요 계획은 Kotlin-to-Swift의 직접 번역(direct export)이다. 이를 통해 Object-C 보틀렉을 제거와 광범위한 Swift언어 지원, 자연스러운 API exporting이 가능해진다. 더욱이, 우리는 코틀린 라이브러리 개발자들을 위한 도구(tool)들을 만들었다. 이 도구들은 Swift로 export될 때 Kotlin API의 호환성과 사용자친화성을 개선하도록 디자인 되다. 우리는 툴링(tooling)에도 세심한 주의를 기울이고 있다. IDE와 빌드 시스템은 개발자 경험의 중요한 부분입니다. 우리의 목표는 Swift Export를 부드럽게 만드는 것 이다.
우리의 또 다른 우선순위는 Kotlin/Native 컴파일의 속도 증가, CocoaPods의 강화, SwiftPM을 사용한프레임워크 exporting 서포트 소개 를 포함하고 있다.
우리는 또한 코틀린 멀티 플랫폼 어플리케이션의 빌드 셋업 향상을 위한 방법도 지속적으로 탐험할 계획이다. Kotlin1.9.20애서 우리는 Gradle Multiplatform DSL의 거대한 향상을 릴리즈하여 읽고, 쓰기 쉽게 만들었다. 우리는 계속적으로 향상시킬 예정이다. 더욱이 우리는 Amper라는 실험을 하고있다. Amper는 사용성, 온보딩, IDE서포트에 초점을 맞춘 새로운 프로젝트 configuration tool이다.
As the Kotlin Multiplatform ecosystem is growing fast, the backward compatibility of the libraries becomes crucial. To ensure it, the JetBrains team and library creators must work together. Here’s our plan:
Improve the klib format so library creators can leverage their knowledge of building JVM libraries.
Implement the same code-inlining behavior in Kotlin Multiplatform libraries as for the JVM.
Provide a tool that ensures that your multiplatform library public API hasn’t changed in an incompatible way.
We’re also going to improve the publishing process for KMP libraries. Specifically, we plan to:
Make it possible to build and publish a KMP library without having a Mac machine.
Provide templates and extensive guidelines for creating and publishing a KMP library.
Even though Kotlin Multiplatform is now stable, we’re planning significant updates. But don’t worry: Libraries built with the current format will still work with newer Kotlin versions.
코틀린 멀티플랫폼의 에코시스템이 빠르게 성장함에 따라 라이브러리들의 이전 버전과의 호환성이 중요해졌다. 호환성을 위해서 JetBrains 팀과 라이브러리 제작자들은 함께 일해야만한다. 아래는 우리의 계획이다.
klib format 발전으로 라이브러리 크리에이터들이 그들의 JVM라이브러리 빌드 지식을 향상시킬 수 있다.
코틀린 멀티플랫폼의 code-inlining 행동이 JVM에서의 행동과 동일하도록 구현한다.
멀티플랫폼 라이브러리의 퍼블릭 API들이 호환되지 않는 방향으로 변경되지 않게 하는 도구를 제공한다.
우리는 또한 KMP라이브러리의 퍼플리싱 프로세스 향상할 것이다. 특히, 아래와 같은 계획이다.
문서화, 모든 개발자의 숙제이다. 필요한 이유는 알고있지만 하기 싫고 귀찮은 작업 중하나이다. 소프트웨어 개발 산출물 중 하나이기도 하고 다른 개발자 혹은 미래의 자신을 위해서 필요한 작업이기도하다.
필요성을 인지하고 있기때문에 모두 작성을 하려고하긴 하지만 어떻게 작성해야하는지를 잘 모른다. 책의 서두에도 나오는 '지식의 저주' 때문에 '이런것은 이미 알고있겠지' 혹은 '이렇게 자세히 쓰면 아무도 안읽을거야' 같은 생각을 하게된다.
사실 이책의 내용의 대부분은 이미 알고 있는 이야기였다. 그럼에도 이 책은 나에게 도움이 되었다. 왜냐면 "왜?"에 대한 답을 주기 때문이다. 문서화를 하다가 동료팀원에게 보완점을 이야기 했을때 "왜 그렇게 해야하죠?" 라는 말에 대답을 못하는 경우가 있다. 왜냐면 내 기준에선 당연한 이야기 이기 때문이다. 물론 '당연히 그렇게 해야죠'라는 말을 하면 싸움밖에 안날것이기때문에 당황하는 경우가 있었는데 이 책은 왜 그렇게 해야하는지에대해 알려주기 때문에 속이 시원해지는 경험을 했다.
이미 알고는 있지만 왜인지 몰랐던 문서에 대한 이야기들은 큰 도움이 되었다. 물론 내가 몰랐던 이야기들도 있었고, 문서화 방향에 대한 가이드이기 때문에 큰 도움이 되었다.
내용이 어렵지도 않고 술술 잘 읽히니 시간이 날때 카페에서 커피 한잔과 함께 가볍게 읽어보면 좋은 책이다.
