Provided by: erlang-manpages_14.b.4-dfsg-1ubuntu1_all bug


       app - Application resource file.


       The  application  resource  file  specifies the resources an application uses, and how the
       application is started.  There  must  always  be  one  application  resource  file  called for each application Application in the system.

       The  file  is read by the application controller when an application is loaded/started. It
       is also used by the functions in systools, for example when generating start scripts.


       The application resource file should be called where  Application  is  the
       name  of  the  application.  The  file  should  be  located  in the ebin directory for the

       It must contain one single Erlang term, which is called an application specification:

       {application, Application,
         [{description,  Description},
          {id,           Id},
          {vsn,          Vsn},
          {modules,      Modules},
          {maxP,         MaxP},
          {maxT,         MaxT},
          {registered,   Names},
          {included_applications, Apps},
          {applications, Apps},
          {env,          Env},
          {mod,          Start},
          {start_phases, Phases}]}.

                    Value                Default
                    -----                -------
       Application  atom()               -
       Description  string()             ""
       Id           string()             ""
       Vsn          string()             ""
       Modules      [Module]             []
       MaxP         int()                infinity
       MaxT         int()                infinity
       Names        [Name]               []
       Apps         [App]                []
       Env          [{Par,Val}]          []
       Start        {Module,StartArgs}   undefined
       Phases       [{Phase,PhaseArgs}]  undefined
         Module = Name = App = Par = Phase = atom()
         Val = StartArgs = PhaseArgs = term()

       Application is the name of the application.

       For the application controller, all keys are optional. The respective default  values  are
       used for any omitted keys.

       The  functions  in systools require more information. If they are used, the following keys
       are mandatory: description, vsn, modules, registered and applications. The other keys  are
       ignored by systools.

           A one-line description of the application.

           Product identification, or similar.

           The version of the application.

           All  modules  introduced  by this application. systools uses this list when generating
           start scripts and tar files. A module can only be defined in one application.

           Deprecated - will be ignored
           The maximum number of processes allowed in the application.

           The maximum time in milliseconds that the application is allowed  to  run.  After  the
           specified time the application will automatically terminate.

           All names of registered processes started in this application. systools uses this list
           to detect name clashes between different applications.

           All applications which are included by this  application.  When  this  application  is
           started,  all  included  application will automatically be loaded, but not started, by
           the application controller. It is assumed that the topmost supervisor of the  included
           application is started by a supervisor of this application.

           All  applications  which  must  be  started  before  this application is allowed to be
           started. systools uses this list to generate correct start scripts.  Defaults  to  the
           empty  list, but note that all applications have dependencies to (at least) kernel and

           Configuration parameters used  by  the  application.  The  value  of  a  configuration
           parameter   is  retrieved  by  calling  application:get_env/1,2.  The  values  in  the
           application resource file can be overridden by values in  a  configuration  file  (see
           config(5)) or by command line flags (see erl(1)).

           Specifies the application callback module and a start argument, see application(3erl).

           The  mod key is necessary for an application implemented as a supervision tree, or the
           application controller will not know how to start it. The mod key can be  omitted  for
           applications  without  processes,  typically  code  libraries  such as the application

           A list of start phases and corresponding start arguments for the application. If  this
           key  is  present,  the  application  master  will  -  in addition to the usual call to
           Module:start/2 - also call  Module:start_phase(Phase,Type,PhaseArgs)  for  each  start
           phase  defined  by  the start_phases key, and only after this extended start procedure
           will application:start(Application) return.

           Start phases may be used to synchronize startup of an  application  and  its  included
           applications. In this case, the mod key must be specified as:

         {mod, {application_starter,[Module,StartArgs]}}

           The  application  master  will  then  call Module:start/2 for the primary application,
           followed by calls to Module:start_phase/3 for each start phase  (as  defined  for  the
           primary  application)  both  for  the primary application and for each of its included
           application, for which the start phase is defined.

           This implies that for an included application, the set  of  start  phases  must  be  a
           subset  of  the set of phases defined for the primary application. Refer to OTP Design
           Principles for more information.


       application(3erl), systools(3erl)