Post Processors

What is a PostProcessor means ?

PostProcessor means, applying some post processing login ontop of an entity/object after it has been created, and before it is being used by others. PostProcessors are the container extension points or plugins into the ioc container, through which we can enhance the features/functionality of the ioc container.

There are 2 types of Post Processors are supported by the ioc container

1. BeanFactoryPostProcessor

BeanFactoryPostProcessor is used for performing the post processing ontop of the ioc container itself, when?

1.1 upon creating the ioc container

1.2 after loading the bean definition information as an in-memory metadata

1.3 before ioc container begins instantiating the object for the bean definitions

we wanted to apply post processing on the in-memory metadata, using BeanFactoryPostProcessor, so that with the modified metadata we want ioc container to instantiate the object of the bean definitions

2. BeanPostProcessor

BeanPostProcessor is used for performing post processing logic onto of the bean definition object, upon the ioc container has created the object, before it returns the object to the application for usage

What is the difference between BeanFactoryPostProcessor and BeanPostProcessor?

BeanFactoryPostProcessor is used for performing post processing on ioc container itself, whereas BeanPostProcessor is used for performing post processing on the bean definition object that ioc container has created

1. BeanFactoryPostProcessor

BeanFactoryPostProcessor is meant for applying post processing logic on top of the ioc container, after the ioc container has been created, after the metadata has been loaded, before the ioc container begins instantiating the objects for the bean definition we wanted to apply the post processing then we need to use "BeanFactoryPostProcessor"

From the above we can understand, using the BeanFactoryPostProcessor we can only apply post processing on in-memory metadata of the ioc container, 

why do we need to modify the in-memory metadata, why can't we change the physical configuration file directly

There are many reasons or usecases under which we want to modify the runtime metadata rather than physical configuration file, let us try one usecase.

How does the deployer has to deploy the application across the various different environments?

1. pull the source code from source code management repositories.

2. the deployer has to compile the application by setting the classpath with dependencies required in compiling the application.

3. package the application based on packaging standard like jar, war or ear etc...

4. deploy the application onto the server and run the application.

problems:

1. The deployer dont know what dependencies are required in building the application, what versions of the to be used.

2. how to compile the application 

3. along with building the application the deployer has to modify the configuration files pertaining to the env on which he is deploying. but the deployer dont know which configurations has to be modified before packaging the application

The developer has to write documentation in building, packaging and deploying the java application, so that deployer can follow it in performing the operation.

with the documentation also still we have problems:

1. The deployer has to gothrough the documentation througly in building and packaging the application which is a tedious job.

2. the deployer has to download the dependencies manually with right versions of them and set them to the classpath which is time taking job

3. manually modifying the configurations within the application before packging the application is very difficult

3.1 identify which configuration files has to be modified and locating them in the project is difficult

3.2 the configuration file could be huge, identifying the right configuration to be changed is challenging

3.3 since the deployer dont know the configuration file format or standard, always there is a chance of modifying it wrongly that breaks the syntax or sematics of it, that leads to deployment error or broke the functionality

4. there could be plenty of steps that has to be carried in sequential order to perform build/deployment of the application, and this has to carried several times in deploying the application so performing these activities manually may not be always accurate and results into error

5. if something goes wrong, the deployer may not be able to identify what went wrong and might have to start from scratch that leads to huge amount of rework and waste of time.

To overcome the above problems, the build tools are introduced.

1. ant

2. maven

3. gradle

etc

since the developer knows the entire process of building, packaging the application he/she has to write the build instructions using ant, maven or gradle in automating the process of building the project

The deployer will quickly conduct the build for the project by running these build tools, rather than manually building the applications.

From the above we can understand we are modifying the physical configuration files of the application before building and deploying the application, this has many problems:

1. the source code of the configuration files has tokens rather than values, during the development since the developers will no rely on build tools for deploying the application, rather they use ides so they need to manually change these tokens into values for running the application locally this could result into lot of problems

1.1 the developer might commit/push the configuration files without tokens mistakenly that will fail in building the application and deploying across other environments

1.2 to eliminate the problem we need to maintain 2 copies of the files, one for local env (without tokens), and another for build tools (with tokens), this leads to huge maintenance and inconsistency

2. if something has been wrongly modified in the properties file and build, to update the configuration values again, the deployer has to checkout the whole code of the program from sourcecode management repository to begin from scratch this leads to huge wastage of time

instead update the in-memory metadata of the ioc container with the actual values by using bean factory post processor.

There are lot of places we can use BFPP

1. instead of relying on build tools to change the configurations we can use BeanFactoryPostProcessor.

2. there could be passwords written in encrypted form in the configuration files, that can be replaced with decrypted passwords at runtime within the in-memory metadata of the IOC container before instantiating the objects with that configuration using BeanFactoryPostProcessor

In-Short: using BeanFactoryPostProcessors, we update the in-memory metadata of the ioc container