## §5.5 Unanticipated team activation

If an application should be adapted unanticipatedly by one or more teams, this can be achieved without explicitly changing the program code of this application.

General activation via config file:
Instead of adding the team initialization and activation code to the main program, it is possible to add the respective teams via a config file. Every line of this text file contains the fully qualified name of a compiled team, which has to be available on the classpath. For the instantiation of these teams the default constructor is used, which means adding a team to an application this way requires the team to provide a default constructor. The activation order (see §5.1) for these teams corresponds to the order in which they are listed in the config file.
Lines starting with a '#' denote comment lines.

##### Example config file:

    # Config file for an ObjectTeams application:
    mypackage1.MyTeam1
    # ...
    mypackageM.MyTeamN

To get this config file recognized by the application the VM argument
'-Dot.teamconfig=<config_file_name>'
has to be used when starting the application.

##### Note:

In the ObjectTeams Development Tooling (OTDT) teams are activated unanticipatedly via a special tab in the "Run-Configuration" (see OTDT features), instead.

Activation adjustment example:
Teams added via the config file mechanism are activated by default. Because no reference to them is stored anywhere, it is not possible to deactivate them later. If deactivation of unanticipated added teams is required, this can be achieved by adding a manager team via config file and encapsulate the actual functionality in another team managed by the manager team. This way a functional team can be activated and deactivated as needed.

##### Example code (Activation Adjustment):

1

    public team class MyManagerTeam {

2

      private FunctionalTeam myFunctionalTeam = new FunctionalTeam();

3

      protected class MyRole playedBy MyApplication {

4

        void startAdaption() { myFunctionalTeam.activate(); }

5

        startAdaption <- before startMethod;

6

        void stopAdaption() { myFunctionalTeam.deactivate(); }

7

        stopAdaption <- after stopMethod;

8

      }

9

    }

    # Config file for the manager team example:
    MyManagerTeam

##### Effects:

- `startMethod` and `stopMethod` are methods which demand the activation and deactivation respectively.
- If the activation/deactivation depends on other conditions these can be checked in addition.