Importing same spring application context file multiple times

Question

I have a big web project which is split across multiple modules. Each of the module has its own spring application context xml file. In the parent project's applicationContext.xml file I have imported all the child module's applicationContext.xml files. Say I have following child applicationContext.xml files

    -aContext.xml
    -bContext.xml
    -cContext.xml

In the parent project's applicationContext.xml file all of these are being imported. But some of the places I see inside aContext.xml bContext.xml and cContext.xml are being imported again?

The hierarchy is something like this -

     -applicationContext.xml(parent)
         -aContext.xml
             -bContext.xml
             -cContext.xml
         -bContext.xml
         -cContext.xml

I can understand that there is no harm doing it as my web application is up and running perfectly. Only thing I am trying understand is, is there any performance glitch of doing it this way? If I remove the nested xml files and import them only once, will I see any performance improvement?

Answer 1

Typically when a spring web application context is loaded it tracks the bean definitions and overrides if it finds same bean definitions later in the context. From there you get "Overriding bean definition" messages as explained here. So I believe that the only impact is in creating lots of bean definitions unnecessarily. However while creating and wiring beans only the final effective bean definition is used. Also for a web application context , the beans are eagerly initialized by default, so this overhead is typically on application deployment on server startup. So from performance perspective in context of serving requests by application this has no such effect other than an overhead at server startup and some annoying log messages.

Answer 2

This is an interesting question actually. If you look here, there's an open request for Spring to develop a feature to mitigate this issue: https://jira.spring.io/browse/SPR-1142.

If you read through that and the comments/proposed solutions, you can get a better idea of what is actually going on.

If you're interested in seeing how many instances of your defined objects get created, you should do a test. I'd recommend creating an object that increments a static counter in its constructor, and putting a bean definition for it in your doubly-imported spring file. Then you can load your configuration file with the double import and see how many instances of the defined bean are actually created when the container loads.

This question leads to the same report Ability to avoid loading the same spring file multiple times.

Answer 3

I know this post is quite old, but I though of posting this answer as there are scenarios where such implementation can also cause different issues apart from performance one. When fixed, definitely there will be performance improvement but, if not fixed, it may cause issues to your web application. I have recently got this issue in a high traffic web application where the same application context file was getting initialized multiple times and caused multiple threads hung on the web application server.

During this application context initialization it was trying to initialize some Spring MVC classes which further down the line tried to initialize some charsets and one of the charset specific to IBM SDK - 'IBM1385' tried to access ExtendedCharsets and then AbstractCharsetProvided.aliases which got deadlock because of multiple concurrent calls. This is a known issue and more details can be found here

This is one instance where initializing same application context file multiple times in a multi threaded env (like web applications) have caused issues and cause a high down time on the server. Similarly there can be even more issues with such implementation and should be avoided.

Also, I agree with @Shailendra answer and when this will be fixed, it will definitely improve the performance as well as in that case Spring will not instantiate multiple instances of the same class which as such not required by our application.

Hope that helps.