#configuration
글
-
Gradle 소스 파헤치기 8: 태스크와 지연 설정 — DefaultTask, TaskContainer, Provider
tasks.register 한 줄은 태스크를 만들지 않습니다. 이름과 설정 블록만 맡겨 둔 TaskCreatingProvider가 언제 실제 태스크가 되는지, configureEach가 지금 있는 태스크와 나중에 올 태스크에 함께 걸리는 원리, withType { }처럼 모르는 새 모든 태스크를 만들어 버리는 API, TaskFactory와 DefaultTask가 액션 목록을 쥐는 법, 그리고 Provider가 값 대신 "값을 만드는 태스크"를 들고 다녀 dependsOn 없이 순서가 생기는 이유와 Property를 굳히는 세 가지 방법까지, 예제 세 개로 소스와 함께 확인합니다.
-
MariaDB 소스 파헤치기 3: 기동과 플러그인 — mariadbd가 첫 연결을 받기까지
mariadbd 를 켜면 첫 연결을 받기 전까지 무슨 일이 일어나는지 sql/mysqld.cc 의 mysqld_main() 을 따라 읽습니다. my.cnf 한 줄이 시스템 변수가 되는 길, InnoDB·Aria 같은 엔진까지 전부 플러그인으로 등록하고 초기화하는 plugin_init(), 엔진이 handlerton 을 채우는 ha_initialize_handlerton(), 신호 스레드와 poll() 루프, 그리고 종료가 기동의 거꾸로 일어나는 모습을 오류 로그와 gdb 로 확인합니다.
-
nginx 소스 파헤치기 2: 전체 지도 — 마스터와 워커, 모듈, cycle, 설정 문맥
nginx 소스를 처음 여는 중급 프로그래머를 위한 연재 전체의 지도입니다. 마스터 하나와 워커 여럿이 각각 어디서 기다리는지, 모든 기능이 ngx_module_t 하나로 꽂히는 모듈 구조와 "CORE"·"HTTP" 글자로 된 모듈 종류, 실행 중인 nginx의 전부를 담은 ngx_cycle_t와 conf_ctx, nginx.conf의 main·events·http·server·location 문맥이 비트 플래그로 검사되는 방법, 한 워커의 이벤트 루프가 수백 개의 연결을 도는 모습을 실제 소스와 ps·gdb 예제로 확인합니다.
-
nginx 소스 파헤치기 4: 기동과 설정 읽기 — main()에서 ngx_init_cycle까지
nginx 를 켜면 main() 이 명령줄을 읽고, ngx_init_cycle() 이 nginx.conf 를 읽어 cycle 이라는 설정 한 벌을 만든 뒤에야 마스터 프로세스가 돌기 시작합니다. 설정 파서가 파일·블록·명령줄(-g) 세 경우를 한 함수로 처리하는 법, 한 글자씩 읽어 낱말로 나누는 ngx_conf_read_token(), 오류 메시지가 찍히는 자리, reload 가 같은 ngx_init_cycle() 을 다시 부르며 옛 cycle 에서 듣기 소켓과 공유 메모리를 물려받는 과정을 nginx 1.31.9 소스와 gdb·strace 예제로 따라갑니다.
-
nginx 소스 파헤치기 5: 모듈과 디렉티브 — nginx.conf 한 줄이 모듈의 설정 구조체가 되기까지
nginx 의 모듈은 ngx_module_t 구조체 하나이고, 디렉티브는 그 구조체가 가리키는 ngx_command_t 표의 한 줄입니다. configure 가 만드는 모듈 배열, load_module 로 읽는 동적 모듈, 디렉티브 이름으로 함수를 찾는 ngx_conf_handler(), http·server·location 마다 모듈별 설정 구조체를 만드는 ngx_http_block(), 그리고 설정 때 한 번에 끝나는 병합(merge)을 소스로 따라갑니다. 디렉티브 넷을 가진 동적 모듈을 직접 만들어 콜백 순서와 병합 결과, 오류 메시지를 확인합니다.
-
Apache httpd 소스 파헤치기 5: main()과 기동 — 설정을 두 번 읽는 이유와 재시작
httpd를 켜면 main() 안에서 무슨 일이 일어나는지 server/main.c 914줄을 따라 읽습니다. 설정 파일을 왜 두 번 읽는지, apachectl graceful 한 줄이 어떻게 main()의 루프를 한 바퀴 더 돌게 하는지, 루트로 시작한 서버가 어디서 User로 내려가는지를 소스와 실제 실행 로그로 확인합니다.
-
Apache httpd 소스 파헤치기 7: 설정 파일과 디렉티브 — httpd.conf 한 줄이 C 구조체가 되기까지
httpd.conf 에 적은 한 줄이 어떻게 모듈의 C 함수를 부르고 구조체에 값을 넣는지 server/config.c 를 따라갑니다. 파일을 트리로 읽는 단계와 그 트리를 걷는 단계, 이름으로 디렉티브를 찾는 해시, TAKE1·FLAG·ITERATE 같은 인자 방식, "not allowed here" 가 나오는 비트 검사와 AllowOverride, 그리고 Directory·Location·VirtualHost 섹션의 값이 언제 병합되는지를 직접 만든 디렉티브로 확인합니다.
-
Tomcat 소스 파헤치기 2: 전체 지도 — Server, Service, Connector, 그리고 컨테이너 넷
Tomcat 소스를 처음 여는 사람을 위한 지도입니다. server.xml의 Server·Service·Connector·Engine·Host가 각각 어떤 클래스가 되는지, Engine·Host·Context·Wrapper 네 컨테이너가 부모·자식으로 어떻게 이어지는지, 커넥터(Coyote)와 서블릿 컨테이너(Catalina)를 왜 나눴고 Adapter 하나로 어떻게 잇는지, Jasper·EL·JULI·Naming은 어디에 있는지를 실제 소스와 직접 돌린 예제로 확인합니다.
-
Tomcat 소스 파헤치기 3: Lifecycle과 기동 — catalina.sh start 뒤에 일어나는 일
catalina.sh start 한 줄 뒤에서 Bootstrap이 클래스로더를 만들고, Catalina가 Digester로 server.xml을 객체 나무로 바꾸고, 모든 부품이 같은 Lifecycle 상태 기계를 따라 init·start되는 과정을 소스로 따라갑니다. 부모가 자식을 어떤 순서로 시작시키는지, 커넥터가 실패해도 서버가 뜨는 이유, 종료 포트 8005가 하는 일을 리스너와 예제로 직접 확인합니다.
-
Tomcat 소스 파헤치기 10: 웹앱 배포와 Context 설정 — WAR 하나가 서비스되기까지
webapps 폴더에 WAR 파일 하나를 넣으면 Tomcat 안에서 무슨 일이 일어나는지 소스로 따라갑니다. HostConfig가 10초마다 폴더를 살펴 Context를 만들고, ContextConfig가 web.xml·conf/web.xml·어노테이션을 합치고 ServletContainerInitializer를 찾으며, StandardContext.startInternal()이 SCI·리스너·필터·서블릿을 정해진 순서로 깨웁니다. Spring의 SpringServletContainerInitializer가 불리는 자리도 Tomcat 쪽에서 확인합니다.