Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342677

Summary: Provide a means to configure an ApplicationContext
Product: [RT] RAP Reporter: RĂ¼diger Herrmann <ruediger.herrmann>
Component: RWTAssignee: Frank Appel <fr.appel>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: fr.appel
Version: unspecified   
Target Milestone: 1.5 M1   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 341763, 342846    

Description RĂ¼diger Herrmann CLA 2011-04-13 04:38:12 EDT
After an ApplicationContext is created it should give all the instances that it manages the chance to configure themselves.
A simple approach to this could be to introduce an 
  interface Configurable {
    void configure( ApplicationContext appCtx );
  }
and provide a means to register a list of Conigurables with the ApplicationContext.
The ApplicationContext could then, after all managed instances are created, invoke the configure() methods in order to configure instances from the application scope before they become accessible from the outside.
Comment 1 Frank Appel CLA 2011-05-29 07:34:12 EDT
Implementation is in CVS-HEAD.

The ApplicationContext has been refactored to create all instances of subsystems that live in application scope hard wired. This allows to provide concrete getter methods for those subsystems. Additionally the context provides methods for addition/removal of Configurable callback implementations as well as lifecycle methods for activation and deactivation handling (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=342846).

Usage scenario:
- create ApplicationContext -> this creates instances of all subsystem
- addConfigurables -> this registers all configurable implementations that are needed to configure subsystems before activation
- activate applicationContext -> this first calls all configurables and afterwards initializes the subsystems in order to have the system up an running once the first request comes in
- deactivate applicationContext -> the subsystems are stopped and afterwards the reset method of the configurable implementations are triggered. The application context and its subsystems should be in the same state as before activation. (I say should because deactivation of the subsystems is not completely implemented yet).

While there still is room for refactorings and improvements in the subsystem managment I resolve this issue as fixed since the core requirement of this request has been implemented.