Imitate Spring to implement a class management container

Overview

The original intention of the project was to independently create a mature and distinctive IOC container, but because the process referred to Spring too much and could not make too many improvements, the purpose became to use this project as a springboard to understand Spring. Unlike some frameworks that imitate Spring on the Internet, this project is mainly aimed at annotations. The address is Thales

process

In Spring, the formation of a bean is divided into three major stages:

Bean definition phase (including BeanDefinition loading, parsing, and registration)
Bean instantiation phase (including object creation and property injection)
Bean initialization phase (including initialization of some resources, such as opening files, establishing connections, etc.)
This is just a rough division, and there is no explicit mention of post-processing such as BeanPostProcessor.

Class Design

If you just want to understand how a bean is born and dies, you only need to debug it step by step. If you don't understand, debug it several times. But if you want to implement a similar container, you must understand the class design, responsibility allocation, and interface implementation inheritance (unless you want several classes to do everything).

Following is the class diagram of DefaultListableBeanFactory

Can't stand it?

Let’s look at another picture

The first picture is for Spring 5.0, and the second picture is for Spring 0.9, so there is no need to introduce too much design complexity at the beginning.

Let's look at a set of comparison pictures

It is clear at a glance which one is 0.9 and which one is 5.0.

The purpose of saying so much is to show that we don’t have to aim for the most perfect goal from the beginning. We can do it step by step and add functions step by step.

Implementing simple IOC
As we all know, the most basic of SpringIoC is BeanFactory

Let's first define a BeanFactory interface

 //For now, just give this method public interface BeanFactory { /** * Get the Bean instance by name * @param name * @return */ Object getBean(String name);}  

beanDefinition

Because it is in the form of annotations, we can no longer give a resource file and then parse it like XML, but should scan all classes with @Component under the classPath.

At this time, the parameter we need to give changes from the file path to the package path. We only need to scan the qualified classes in this package and its subpackages, convert them into BeanDefinition and then register them. The class that performs this function is ClassPathBeanDefinitionScanner. At this step, it is different from the traditional process. We will pass in a ResourceLoader to implement the specific scanning function (ie positioning), but there will be no special class to handle the parsing step.

 public   interface Resource { File getFile(); String getFilename(); String getFilePath();} //This abstract class seemed useless in the initial design, but considering the future expansion, it is better to put it here first public abstract class AbstractResource implements Resource { @Override public String getFilename() { return getFile().getName(); } @Override public String getFilePath() { return getFile().getPath(); }}//This is the Resource class we use when instantiating beans. It is not used directly in Spring, but integrated into RootBeanDefinition through the facade pattern public class ClassPathResource extends AbstractResource { private final String path; private ClassLoader classLoader; private Class<?> clazz; public ClassPathResource(String path, ClassLoader classLoader, Class<?> clazz) { this.path = path; this.classLoader = classLoader; this.clazz = clazz; }}  

 public   interface ResourceLoader { Resource getResource(String location);} //This class can load multiple resources public interface ResourcePatternResolver extends ResourceLoader { String CLASSPATH_ALL_URL_PREFIX = "classpath*:"; List<? extends Resource> getResources(String location);} //This class is officially used for scanning public class PathMatchingResourcePatternResolver implements ResourcePatternResolver { private final ResourceLoader resourceLoader; public PathMatchingResourcePatternResolver(ResourceLoader resourceLoader){ this.resourceLoader = resourceLoader; } @Override public Resource getResource(String location) { return resourceLoader.getResource(location); } //In Spring, the conversion from package name to path is completed through layer-by-layer method packaging, and then each file is scanned and converted to Resource. Here we will take a step forward and put the specific implementation in the tool class @Override public List<? extends Resource> getResources(String location) {        Set<Class<?>> classes = ClassUtils.getClasses(location); List<ClassPathResource> classPathResources = new ArrayList<>(); for (Class<?> clazz:classes) { classPathResources.add(new ClassPathResource("",clazz.getClassLoader(),clazz)); } return classPathResources; }}  

But the PathMatchingResourcePatternResolver is not used directly in the end

Instead, use it as a property of ClassPathBeanDefinitionScanner and call it in this class.

Now that we have a Resource, how do we get the corresponding BeanDefinition?

First consider this question, what kind of class can be registered BeanDefinition?

Added @Component annotation or met other registration conditions Not an interface or abstract class So we can abstract a method boolean isCandidateComponent(Class<?> clazz) to determine whether it is registered

Now it is time to register. We still adhere to the concept of interface-oriented programming and take single responsibility into consideration. We abstract the registration bean definition separately.

 public   interface BeanDefinitionRegistry { void registerBeanDefinition(BeanDefinition beanDefinition);}

As mentioned above, the location, parsing, and registration of Bean definitions are all done in ClassPathBeanDefinitionScanner, so BeanDefinitionRegistry naturally becomes one of the attributes of ClassPathBeanDefinitionScanner.

So the ClassPathBeanDefinitionScanner is constructed

 public   class ClassPathBeanDefinitionScanner { //Responsible for specific Resource positioning private ResourcePatternResolver resourcePatternResolver; //Responsible for BeanDefinition resolution private BeanDefinitionRegistry registry; public ClassPathBeanDefinitionScanner(BeanDefinitionRegistry registry,String...basePackage) { this.registry = registry; this.resourcePatternResolver = new PathMatchingResourcePatternResolver((ResourceLoader) registry); this.scan(basePackage); } public void scan(String...basePackages){ doScan(basePackages); } void doScan(String[] basePackages){ Set<BeanDefinition> beanDefinitions = new LinkedHashSet<>(); for (String basePackage:basePackages) { Set<BeanDefinition> candidates = findCandidateComponents(basePackage); for(BeanDefinition candidate:candidates){                beanDefinitions.add(candidate); registry.registerBeanDefinition(candidate); } } } //Get the collection of registered beans private Set<BeanDefinition> findCandidateComponents(String basePackage) { Set<BeanDefinition> candidates = new LinkedHashSet<>(); List<? extends Resource> resources = getResourcePatternResolver().getResources(basePackage); for(Resource resource:resources){ if(resource instanceof ClassPathResource){ ClassPathResource classPathResource = (ClassPathResource)resource; if(isCandidateComponent(classPathResource.getClazz())){ AnnotationBeanDefinition beanDefinition = new AnnotationBeanDefinition(); beanDefinition.setClazz(classPathResource.getClazz());                    beanDefinition.setBeanName(BeanUtils.generateBeanName(classPathResource.getClazz().getName())); candidates.add(beanDefinition); } } } return candidates; } private ResourcePatternResolver getResourcePatternResolver() { return this.resourcePatternResolver; } //Determine whether it is registered boolean isCandidateComponent(Class<?> clazz){ Component declaredAnnotation = clazz.getDeclaredAnnotation(Component.class); return declaredAnnotation!=null&&!clazz.isInterface(); } ;}  

Instantiation

When is it instantiated? We say that it is instantiated when getBean() is called and there is no existing bean.

 public   abstract   class AbstractBeanFactory implements BeanFactory{ @Override      public Object getBean(String beanName) }

Object creation

There are two ways, through the default reflection implementation of Jdk, or through the cglib proxy implementation.

The default is naturally a no-parameter constructor, but if parameters are passed in, you need to match the corresponding constructor according to the type and number of parameters and use it to instantiate

So we abstract InstantiationStrategy as the instantiation interface. Both instantiation methods need to implement this interface. When we actually use it, we only need to call the method of this interface.

 public   interface InstantiationStrategy { Object instantiate(BeanDefinition beanDefinition, String beanName, BeanFactory owner);} public   class SimpleInstantiationStrategy implements InstantiationStrategy {}

Property Injection

Get field value

There are two ways to get field values:

Directly annotate Autowired or Value
If the value is not filled in the value but the placeholder, then we need to parse the placeholder to get all the fields through the Class object, and then traverse all the fields to find the annotations added to the fields to get them (this is just a way of injection in Spring)

 //Process @Autowired annotations for(Field field:declaredFields){ Autowired autowired = field.getDeclaredAnnotation(Autowired.class); if(autowired != null){ pvs.add(new PropertyValue(field.getName(),new BeanReference(BeanUtils.generateBeanName(field.getType().getName()),field.getType()))); } } //Process @Value annotation for(Field field:declaredFields){ Value value = field.getDeclaredAnnotation(Value.class); if(value != null){ String value1 = value.value(); pvs.add(new PropertyValue(field.getName(),value1)); } }  

Field value filling

After getting the field value, fill it into the corresponding field through reflection

 for (Field field:mbd.getBeanClass().getDeclaredFields()){ field.setAccessible( true ); if (field.getName().equals(propertiesValue.getName())&&field.getType().isAssignableFrom(newValue.getClass())) { field.set(bean,newValue); } }

initialization

Call the specified initialization method to initialize the resources. How to get the initialization method? In XML mode, just add a tag. If it is annotation mode, add an annotation or add a parameter to an annotation to represent the initialization method. This has not been implemented yet.

Function filling

Postprocessor added

Above we have implemented a Bean container that can perform dependency lookup and dependency injection. Let's review the Spring process and see what we are missing. The easiest thing to think of is the post-processor, including BeanFactoryPostProcessor and BeanPostProcessor. The former modifies the beanFactory, while the latter modifies the bean. It is also interface-oriented programming.

First, create a BeanPostProcessor

 public   interface BeanPostProcessor { Object postProcessBeforeInitialization(Object bean, String beanName); Object postProcessAfterInitialization(Object bean, String beanName) ;}

At present, what needs to be done by BeanPostProcessor? We can separate the code that processes annotations and obtains injection properties and use a BeanPostProcessor to process it.

All custom implemented BeanPostProcessors need to inherit this interface. Since the function of BeanPostProcessor is to process other beans, it must be created before other processed beans are instantiated. So we add registerBeanPostProcessors(beanFactory) before finishBeanFactoryInitialization(beanFactory); to instantiate all BeanPostProcessors

The importance of these beanPostProcessors is different. For example, the priority of the BeanPostProcessor that handles annotation injection is higher than that of the general BeanPostProcessor, so it needs to be instantiated first.

Aware interface added

In fact, now we can completely hand over an object to the IOC container, but the relationship between the object and the container is one-way. The container can operate the bean, but the bean cannot use the container. In order to solve this problem, we add an Aware interface as a marker interface, which is inherited by each more specific Aware. After the attributes are instantiated, the initialization method is executed to complete the injection of related container attributes.

Event listener added

Listener is an implementation of the observer pattern

Let's first define the following basic interfaces

 public   interface ApplicationEventPublisher { /** * Publish events * @param event */      void publishEvent(ApplicationEvent event);} public   interface ApplicationEventMulticaster { /** * Add broadcast event * @param event */      void multicastEvent(ApplicationEvent event); /** * Add a listener for an event * @param listener */      void addApplicationListener(ApplicationListener listener); /** * Remove the specified listener * @param listener */      void removeApplicationListener(ApplicationListener listener);} public   interface ApplicationListener <E extends ApplicationEvent> extends EventListener { /** * Listen for specific events * @param event */      void onApplicationEvent(E event);}

The specific calling process is that a specific listener is added to the broadcaster, and the event is published uniformly through the publisher. The publishEvent will finally call the multicastEvent (ApplicationEvent event) method, and the corresponding listener will make corresponding operations after the corresponding judgment.

How to determine whether this listener is interested in this event?

The listener we implemented beforehand is generic, and we can judge by the relationship between this generic and the incoming event type.

 public   boolean supportEvent(ApplicationListener<ApplicationEvent> listener,ApplicationEvent event){ //Get the Class object first Class<? extends ApplicationListener> listenerClass = listener.getClass(); //Get all the interfaces it implements (including generic information) Type[] genericInterfaces = listenerClass.getGenericInterfaces(); for (Type genericInterface:genericInterfaces){ //Judge whether it is a generic interface if(genericInterface instanceof ParameterizedType){ ParameterizedType parameterizedType = (ParameterizedType) genericInterface; //Get all generic parameters Type[] actualTypeArguments = parameterizedType.getActualTypeArguments(); for(Type actualTypeArgument:actualTypeArguments){ try { Class<?> aClass = Class.forName(actualTypeArgument.getTypeName()); //Judge whether the event type of interest is the same as the incoming event, or its parent class if(aClass.isAssignableFrom(event.getClass())){ return true; } } catch (ClassNotFoundException e) { e.printStackTrace(); } } } } return false; }  

FactoryBean added

Currently, all beans are generated by BeanFactory.

We use the FactoryBean interface to identify this special Bean that produces Beans.

Solving circular dependencies

Circular dependency means that A depends on B while B depends on A. The solution is to separate instantiation and initialization. If we only consider the general case, two-level cache is actually enough.

Code Optimization

Implementing simple AOP

If you start with the orthodox AOP, a bunch of concepts will follow, including pointcuts and notifications.

Let's first look at what AOP does

So the core of AOP is dynamic proxy. Let's take Cglib as an example to see how to use dynamic proxy.

 Enhancer enhancer = new Enhancer(); //1. Which class is the proxy for enhancer.setSuperclass(Buy.class); enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> { //2. Which method of the class is the proxy for if(method.getName().equals("buyOne")){ //3. What exactly does the proxy do System.out.println("hello"); } //4. Call the original object methodProxy.invokeSuper(o,objects); return o; });//5. Generate the proxied object Buy o = (Buy)enhancer.create();  

This is the core function of dynamic proxy, and also the core function of AOP. The ultimate goal of AOP is code 5, that is, to generate a proxy object and hand it over to IOC for management.

In order to achieve this goal, the AOP framework needs to do what code 1-4 needs to do. Code 1 and 2 are combined to form JoinPoint, 3 is called Advice, and these two are combined to form Advisor. Can we write them all in one or several classes without distinguishing them? Of course, Spring 0.9 does this, but now, this division method has been adopted. This project also adopts this classification.

Let's start with the connection point. How to determine where to implement functional enhancement is nothing more than two levels: class and method;

Let's first define the two interfaces ClassFilter and MethodMacther

 public   interface ClassFilter { /** * Whether the given type matches * @param clazz * @return */      boolean matches(Class<?>clazz);} public   interface MethodMatcher { /** * Whether the corresponding method of the corresponding class matches * @param method * @param targetClass * @return */      boolean matches(Method method,Class< ? > targetClass);}

These two interfaces must be used in combination, so we use PointCut to combine them

 public   interface Pointcut { /** * Get ClassFilter * @return */ ClassFilter getClassFilter(); /** * Get MethodMatcher * @return */ MethodMatcher getMethodMatcher();}

The interface only defines abstract functions, which must be implemented in detail.

By default, we use Java regular expressions to match method names, thereby constructing JdkRegexMethodMatcher

 public   class JdkRegexMethodPointcut implements MethodMatcher, Pointcut{ private Pattern[] compiledPatterns = new Pattern[ 0 ]; @Override      public ClassFilter getClassFilter() { return   null ; } @Override      public MethodMatcher getMethodMatcher() { return   this ; } @Override      public   boolean matches(Method method, Class<?> targetClass) { String name = method.getName(); for (Pattern pattern :compiledPatterns) { Matcher matcher = pattern.matcher(name); if (matcher.matches()){ return   true ; } } return   false ; } //Precompile private Pattern[] compilePatterns(String[] source) throws PatternSyntaxException { Pattern[] destination = new Pattern[source.length]; for (int i = 0; i < source.length; i++) { destination[i] = Pattern.compile(source[i]); } return destination; } public void initPatternRepresentation(String[] patterns) throws PatternSyntaxException { this.compiledPatterns = compilePatterns(patterns); }}  

In Spring, MethodMatcher is not directly inherited. Considering the different syntax of regular expressions, an additional layer of abstraction is made, but it is omitted here.

JdkRegexMethodMatcher also implements the PointCut class, which means that the cut point is now ready.

Let’s look at Advice

Since there are many extensibility points to consider, the inheritance levels have also increased.

 public   interface Advice {} public   interface BeforeAdvice extends Advice{} public   interface MethodBeforeAdvice extends BeforeAdvice{ void before(Method method, Object[] args, Object target) throws Throwable;}

Now that the Advice is defined, we leave the specific implementation to the user.

The next step is to integrate it into Advisor

 public   interface Advisor { Advice getAdvice();} public   interface PointcutAdvisor extends Advisor{ Pointcut getPointcut();} public   abstract   class AbstractPointcutAdvisor implements PointcutAdvisor{ private Advice advice; @Override      public Advice getAdvice() { return advice; } public   void setAdvice(Advice advice) { this .advice = advice; }}

The Advisor functionality has been defined.

Let's implement this interface

 public   class RegexMethodPointcutAdvisor extends AbstractPointcutAdvisor { JdkRegexMethodPointcut pointcut = new JdkRegexMethodPointcut(); private String[] patterns; public RegexMethodPointcutAdvisor() { } public RegexMethodPointcutAdvisor(Advice advice) { setAdvice(advice); } public   void setPattern(String pattern) { setPatterns(pattern); } public   void setPatterns(String... patterns) { this .patterns = patterns; pointcut.initPatternRepresentation(patterns); } @Override      public Pointcut getPointcut() { return pointcut; }}

RegexMethodPointcutAdvisor integrates PointCut and Advice. Through it, we can determine where to make enhancements.

The current advisor can complete the function of checking whether a class needs to be proxied, but if this class needs to be proxied, the advisor cannot save the corresponding information of this class

So we need a class to combine the advisor with the corresponding proxy class, which is AdvisedSupport

 public   class AdvisedSupport { private TargetSource targetSource; private List<MethodInterceptor> methodInterceptors = new ArrayList<>(); private List<PointcutAdvisor> advisors = new ArrayList<>(); public TargetSource getTargetSource() { return targetSource; } public   void setTargetSource(TargetSource targetSource) { this .targetSource = targetSource; } public List<MethodInterceptor> getMethodInterceptor() { return methodInterceptors; } public   void addMethodInterceptor(MethodInterceptor methodInterceptor) { this .methodInterceptors.add(methodInterceptor); } public List<PointcutAdvisor> getAdvisor() { return advisors; } public   void addAdvisor(PointcutAdvisor advisor) { MethodBeforeAdviceInterceptor methodBeforeAdviceInterceptor = new MethodBeforeAdviceInterceptor(); methodBeforeAdviceInterceptor.setAdvice((MethodBeforeAdvice) advisor.getAdvice()); addMethodInterceptor(methodBeforeAdviceInterceptor); this .advisors.add(advisor); }}

The TargetSource in the above class attributes is the class that actually holds the proxy object information.

Now that everything is ready, we just need to use Cglib to create new classes using the information we already have.

 public   class CglibAopProxy implements AopProxy{ private   final AdvisedSupport advised; public CglibAopProxy(AdvisedSupport advised) { this .advised = advised; } @Override      public Object getProxy() { Enhancer enhancer = new Enhancer(); //1. Which class to proxy enhancer.setSuperclass(advised.getTargetSource().getTargetClass()); enhancer.setCallback(new DynamicAdvisedInterceptor(advised)); //5. Generate the proxy object return enhancer.create(); } private static class DynamicAdvisedInterceptor implements MethodInterceptor { private final AdvisedSupport advised; public DynamicAdvisedInterceptor(AdvisedSupport advised) { this.advised = advised; } @Override public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable { CglibInvocation cglibInvocation = new CglibInvocation(method,objects,o,methodProxy); //2. Which method of this class to proxy for(PointcutAdvisor advisor: advised.getAdvisor()){ if(advisor.getPointcut().getMethodMatcher().matches(method,advised.getTargetSource().getTargetClass())){ //3. What exactly does the agent do return advised.getMethodInterceptor().get(0).invoke(cglibInvocation); } } //4. Call the source method return cglibInvocation.proceed(); } }}  

Comparing this code with the original code using cglib, you will find that the process is almost identical. However, as a framework, it should be as convenient as possible for users.

So we need a Creator to do all this. It is responsible for combining Advice and PointCut into Advisor, assembling Advisor and TargetSource into AdvisedSupport, and then handing AdvisedSupport to Cglib dynamic proxy to generate proxy objects. Users only need to write Advice and pointcut expressions.

Functional Demonstration

Property injection Basic types Reference types Circular dependencies Container awareness
FactoryBean generates objects
AOP aspect enhances custom BeanPostProcessor

Difficulties and solutions

First of all, the problem is design
FactoryBean Implementation
Combination of AOP and IOC Field Injection