CODEWITHSUNDEEP
javaspringjakarta-ee
Cris
Cris

Reputation: 5007

Spring multiple application contexts vs single application context in an ear

I have inherited an app which is packaged as ear file that has inside

 - ear :
        -APP-INF/lib (persitence.jar - hibernate+spring ... etc)
        -war (web-services)
        -jar (mdb)
        -jar (mdb)

As I studied the app noticed that each module has inside the jar creates it's own Spring application context that is loaded on runtime.

It works ok but it would not be better to have only one application context ? I wonder what are the benefits and drawback which this structure compared to the one where it is only an single application context used ?

To be more clear on runtime there are 3 application context roots loaded.It is not only that there are more application context files

Thanks

Upvotes: 0

Views: 11879

Answers (4)

bhantol
bhantol

Reputation: 9616

I stumbled on this thread which seeking a solution for multi-tenant application. Most articles are just about datasource (Spring HotSwapable datasource targets) etc but what you have is a separate context at the war level.

This gives me another idea of bundling my application in a way that makes it multi-tenant. If the wars are skinny just to inject special runtimes and provide additional context path qualifies this may work for a large multi-tenant application. Common classes will be loaded at the EAR level and application contexts per war. I guess this should be ok for small number of tenants.

Upvotes: 0

Tom
Tom

Reputation: 4180

first of all: are you sure it isn't the same application context everywhere ? have you tested this ?

if they are all seperate: the advantage is that those application contexts are shielded from eachother, which you could call loose coupling, which is a good thing; one can't influence the other, it keeps things clearer for the programmer. the disadvantage is, it might be harder to access one application context from the other, but you can always find a way around this.

Upvotes: 4

mprabhat
mprabhat

Reputation: 20323

Few points against single application-context file that I can think of:

  1. One file will get huge and it will be maintenance nightmare.
  2. Developers of each component will modify,update same file can lead to errors.
  3. Changes in one component will lead to changes in one centralized file, again may lead to issues.
  4. It gives every component developer "Separation of Concern", they don't have to see, know others work while carrying out there task.

Upvotes: 1

Japan Trivedi
Japan Trivedi

Reputation: 4483

If the application very large then the application context of different modules is easy to manage and it doesn't create any overhead. At the time when application is up all the context xml files will be combined.

And I will also prefer to maintain separate application context files for separate set of configurations eg. security, datasource, aop etc. should be placed in separate context files.

When the application is small then you can go for single application context file for whole application. Otherwise different application context for different modules is easy to manage in case when you need to do some changes in any one of them. If you combine all of them then it will be very difficult to do any changes in that.

Hope this helps you. Cheers.

Upvotes: 3

Related Questions