Using Spring by Creating Multiple ApplicationContexts to manage bean life time - is this okay?

Question

I have used Spring before but I am no expert and only used it for standard web-development previously.

Currently, I am working on a project where Spring is being used very differently. It's a stand-alone Swing app which has many displays and the user can switch between a display via a toolbar. When the display changes, all the components need to be destroyed (garbage-collected).

Currently, this is done by having separate ApplicationContexts associated with each display. So when the display is changed, the idea is that the AppCtx associated with the display is destroyed then a new app context is created (from a different XML file) to load the components in the new display.

Is this an appropriate way of using Spring? I don't know much about the internals of the Spring Container and the way the container manages the beans so I can't figure out whether it's a good thing or not.

Answer 1

Sounds to me like you should be using a custom scope.

As of Spring 2.0, the bean scoping mechanism in Spring is extensible. This means that you are not limited to just the bean scopes that Spring provides out of the box; you can define your own scopes, or even redefine the existing scopes (although that last one would probably be considered bad practice - please note that you cannot override the built-in singleton and prototype scopes).

The problem with your approach is mainly performance, as you will be parsing/configuring/defining/instantiating spring beans on every screen change. I suggest you use instead a custom scope of screen ( let's say ), which returns separate objects per scope.

See the Scope javadoc for implementation details.