#classloader
Posts
-
Digging into Gradle's Source 6: Projects and Build Scripts — How build.gradle.kts Gets Run
What does one build.gradle.kts file turn into inside Gradle? We follow the code that builds DefaultProject from the descriptors settings left behind, the evaluator chain that runs under a project lock with its beforeEvaluate and afterEvaluate states, the selector that picks Groovy or Kotlin by the end of the file name, the two DSLs that cut out plugins {} and compile twice, the generated accessors that make tasks.compileJava possible, and the class loader scopes that run from settings down to subprojects, running the same script in both DSLs and printing a stack trace to check each step against the source.
-
Digging into Gradle's Source 7: Applying Plugins — From the plugins {} Block to apply()
What does a single plugins { java } line turn into in the source? DefaultPluginRequestApplicator resolves every request first and only then applies them all; a resolver chain asks core plugins, buildSrc, included builds and the Plugin Portal in turn, using marker artifacts; META-INF/gradle-plugins descriptors turn an id into a class; DefaultPluginManager runs a plugin only once even if you apply it twice; withPlugin fires at a precise moment; extensions get attached; java pulls in java-base and base; and buildSrc and precompiled script plugins fit in — all checked with a plugin we write ourselves.
-
Digging into Tomcat's Source 4: Class Loaders — Each Web App Sees Its Own Classes
Why can two web apps in a single Tomcat process use different classes with the same name? We find the answer in the source — the common, server and shared loaders that Bootstrap builds from catalina.properties, the per-app WebappClassLoaderBase whose loadClass() turns parent delegation around, filter() which picks out exceptions such as jakarta.servlet, the delegate setting, and reloadable reloads with their thread-leak warnings — and check each one on a Tomcat built from the reference commit.
-
Digging into Tomcat's Source 16: Embedded Tomcat, JMX and Logging — and Wrapping Up the Series
What the startup/Tomcat class builds for you when you start Tomcat from code without server.xml, and what it does not; how every component registers an MBean for JMX; and how JULI's ClassLoaderLogManager gives each web app its own logging configuration — all checked against the source and with examples, followed by a look back over the 16-part series.