Splitting component containers to simplify dependencies
Eugene Petrenko at Spring I/O 2017
The bigger a monolithic application, the larger the dependency set. Adding or changing dependencies becomes a tricky task. Similarly, the complexity is in a number of beans and their dependencies in components container.
In this talk, we’ll discuss a way to simplify things by splitting component containers into smaller ones.
We’ll see how to split a monolithic ApplicationContext into a number of sub-contexts, how to isolate sub-context internal beans, clear their APIs and avoid non-trivial dependencies.
Each sub-context can have its own classpath, which tackles the dependency hell problem.
After being divided, a monolithic system becomes easier to split into a set of micro-services or processes.
From the talk, attendees will learn several practical tips and tricks on how to split component containers into smaller ones
In this talk, we’ll discuss a way to simplify things by splitting component containers into smaller ones.
We’ll see how to split a monolithic ApplicationContext into a number of sub-contexts, how to isolate sub-context internal beans, clear their APIs and avoid non-trivial dependencies.
Each sub-context can have its own classpath, which tackles the dependency hell problem.
After being divided, a monolithic system becomes easier to split into a set of micro-services or processes.
From the talk, attendees will learn several practical tips and tricks on how to split component containers into smaller ones