#configuration
Posts
-
Digging into Gradle's Source 8: Tasks and Lazy Configuration — DefaultTask, TaskContainer and Provider
A single tasks.register line does not create a task. We follow when the TaskCreatingProvider that only holds a name and a configuration block becomes a real task, how configureEach reaches tasks that exist now and tasks that come later, which APIs like withType { } quietly create every task, how TaskFactory and DefaultTask hold the action list, why a Provider that carries "the task that makes this value" gives you ordering without dependsOn, and the three ways a Property gets locked — checked against the source with three runnable examples.
-
Digging into MariaDB's Source 3: Startup and Plugins — Until mariadbd Takes Its First Connection
What happens between starting mariadbd and its first connection? We follow mysqld_main() in sql/mysqld.cc — how a line in my.cnf becomes a system variable, how plugin_init() registers and initializes everything as a plugin (even InnoDB and Aria), where ha_initialize_handlerton() lets an engine fill its handlerton, the signal thread and the poll() loop, and how shutdown runs startup in reverse — checked with the error log and gdb.
-
Digging into nginx's Source 2: The Big Picture — Master and Workers, Modules, the Cycle and Config Contexts
The map for the whole series, written for intermediate programmers opening the nginx source for the first time. Where the single master and the workers each spend their time waiting, how every feature plugs in as one ngx_module_t and why module types are the ASCII letters "CORE" and "HTTP", what ngx_cycle_t and conf_ctx hold for a running nginx, how the main, events, http, server and location contexts of nginx.conf are checked with bit flags, and how one worker's event loop juggles hundreds of connections — all checked against the real source with ps and gdb examples.
-
Digging into nginx's Source 4: Startup and Reading the Config — From main() to ngx_init_cycle
When you start nginx, main() reads the command line, and ngx_init_cycle() reads nginx.conf and builds one complete set of configuration called a cycle — only then does the master process start running. We follow how one parser function handles three cases (a file, a block, and the -g command-line string), how ngx_conf_read_token() splits text into words one character at a time, where the error messages come from, and how reload calls the same ngx_init_cycle() again and inherits listening sockets and shared memory from the old cycle — using the nginx 1.31.9 source and gdb and strace examples.
-
Digging into nginx's Source 5: Modules and Directives — How One Line of nginx.conf Becomes a Module's Config Struct
An nginx module is a single ngx_module_t struct, and a directive is one row in the ngx_command_t table that struct points to. We follow the module array configure generates, dynamic modules read with load_module, ngx_conf_handler() finding a function by directive name, ngx_http_block() creating per-module config structs for every http, server and location, and the merge that finishes once, at config time. We build a dynamic module with four directives to watch the callback order, the merged values and the error messages.
-
Digging into Apache httpd's Source 5: main() and Startup — Why the Config Is Read Twice, and Restarts
What happens inside main() when you start httpd, followed through all 914 lines of server/main.c. Why the config file is read twice, how one apachectl graceful makes main()'s loop go round once more, and where a server started as root drops to User — checked against the source and against real log output.
-
Digging into Apache httpd's Source 7: The Config File and Directives — How One Line of httpd.conf Becomes a C Struct
How does one line you write in httpd.conf end up calling a module's C function and filling in a struct? We follow server/config.c — reading the file into a tree and then walking it, the hash that finds a directive by name, argument styles like TAKE1, FLAG and ITERATE, the bit test behind "not allowed here" and AllowOverride, and when the values in Directory, Location and VirtualHost sections get merged — all checked with a directive we wrote ourselves.
-
Digging into Tomcat's Source 2: The Big Picture — Server, Service, Connector and the Four Containers
A map for anyone opening the Tomcat source for the first time. We look at which class each server.xml element (Server, Service, Connector, Engine, Host) turns into, how the four containers Engine, Host, Context and Wrapper are linked as parents and children, why the connector (Coyote) and the servlet container (Catalina) are kept apart and joined by a single Adapter, and where Jasper, EL, JULI and Naming live — all checked against the real source and examples I actually ran.
-
Digging into Tomcat's Source 3: Lifecycle and Startup — What Happens After catalina.sh start
We follow the source from catalina.sh start to a running server — Bootstrap building class loaders, Catalina turning server.xml into a tree of objects with the Digester, and every component being initialized and started by the same Lifecycle state machine. With a listener and small examples we check the order in which parents start their children, why the server still comes up when a connector fails, and what the shutdown port 8005 does.
-
Digging into Tomcat's Source 10: Deploying a Web App — From a WAR to a Running Context
We follow in the source what happens inside Tomcat when you drop a WAR file into the webapps folder. HostConfig checks the folder every 10 seconds and creates a Context, ContextConfig merges web.xml, conf/web.xml and annotations and finds ServletContainerInitializers, and StandardContext.startInternal() wakes up SCIs, listeners, filters and servlets in a fixed order. We also look, from Tomcat's side, at where Spring's SpringServletContainerInitializer gets called.