Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

Linux 2.6 - man page for app (linux section 5)

app(5)					      Files					   app(5)

       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 Applica-
       tion.app 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 Application.app where  Application  is  the
       name of the application. The file should be located in the ebin directory for the applica-

       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 .

	 description :
	   A one-line description of the application.

	 id :
	   Product identification, or similar.

	 vsn :
	   The version of the application.

	 modules :
	   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.

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

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

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

	 included_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.

	 applications :
	   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
	   stdlib .

	 env :
	   Configuration parameters used by the application. The value of a configuration parame-
	   ter	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) ).

	 mod :
	   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

	 start_phases :
	   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  Mod-
	   ule: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, fol-
	   lowed  by  calls to Module:start_phase/3 for each start phase (as defined for the pri-
	   mary application) both for the primary application and for each of its included appli-
	   cation, for which the start phase is defined.

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

       application(3erl) , systools(3erl)

Ericsson AB				  kernel 2.14.3 				   app(5)

All times are GMT -4. The time now is 08:07 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password