Splitting component containers to simplify dependencies
summary
Monolithic Spring app with ~1.1K beans gets split into independent sub-contexts so each plugin has its own AnnotationConfigApplicationContext (parented to core), exports selected beans via a @Bean factory method to the core, and isolates implementation beans. Practical pitfalls covered: initialize plugin context fields before refresh to avoid NPEs, never cache queried extensions, use thread context classloader when libraries reflect, and solve jar-hell by loading plugins with a per-plugin classloader (parent-first or child-first URLClassLoader depending on needs).
AI-written summary · about
chapters (13)
- 0:00Start
- 1:08Spring Components Diagram
- 1:53Typical Application
- 2:58Problems
- 5:13Component Containers
- 7:40Spring for Plugin?
- 14:08Extensions
- 14:40Tricks: Documentation
- 15:42Extension Registration
- 26:27Use Bean Factory
- 36:49Dependencies (JAR) Hell
- 41:15Classloader Strategies
- 47:00Practice
related talks
47mWhy your shared libraries are ill - and how to cure them
16mPlugins: An internals deep dive
56mBuilding a Framework on top of Spring Boot
27mThe Inner Secrets of Spring
31mArchitecting your codebase
45mCode Once, Use Everywhere: Building a Shared Module used by Multiple Projects
01h 00mFantastic Frameworks and How to Avoid Them
43mInside Spring: The Architecture Behind the Framework