Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
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  ap-
       plication resource file called for each application Ap-
       plication 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 exam-
       ple 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 application.

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

       {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},
	  {runtime_dependencies, RTDeps}]}.

		    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}	 []
       Phases	    [{Phase,PhaseArgs}]	 undefined
       RTDeps	    [ApplicationVersion] []
	 Module	= Name = App = Par = Phase = atom()
	 Val = StartArgs = PhaseArgs = term()
	 ApplicationVersion = string()

       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.

       The RTDeps type was introduced in OTP 17.0  and	might  be  subject  to
       changes during the OTP 17 release.

	   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

	   All names of	registered processes started in	this application. sys-
	   tools uses this list	to detect name clashes between	different  ap-

	   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	appli-
	   cations have	dependencies to	(at least) kernel and stdlib.

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

	   Specifies the application callback module and a start argument, see

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

	   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  Mod-
	   ule:start_phase(Phase,Type,PhaseArgs)  for each start phase defined
	   by the start_phases key, and	only after this	extended start	proce-
	   dure	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 pri-
	   mary	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  pri-
	   mary	 application. Refer to OTP Design Principles for more informa-

	   A list of application versions that the application depends on.  An
	   example of such an application version is "kernel-3.0". Application
	   versions specified as runtime  dependencies	are  minimum  require-
	   ments. That is, a larger application	version	than the one specified
	   in the dependency satisfies the requirement.	For information	on how
	   to  compare	application versions see the documentation of versions
	   in the system principles guide. Note	that that the application ver-
	   sion	 specifies  a  source code version. An additional indirect re-
	   quirement is	that installed binary  application  of	the  specified
	   version  has	 been  built so	that it	is compatible with the rest of
	   the system.

	   Some	dependencies might only	be required in specific	 runtime  sce-
	   narios.  In	the  case  such	optional dependencies exist, these are
	   specified and documented in the corresponding  "App"	 documentation
	   of the specific application.

	 The  runtime_dependencies key was introduced in OTP 17.0. The type of
	 its value might be subject to changes during the OTP 17 release.

	 All runtime dependencies specified in OTP applications	during the OTP
	 17  release  may  not	be  completely correct.	This is	actively being
	 worked	on. Declared runtime dependencies in OTP applications are  ex-
	 pected	to be correct in OTP 18.

       application(3), systools(3)

Ericsson AB			  kernel 3.2				app(5)


Want to link to this manual page? Use this URL:

home | help