how to include OTP defiened applications in resourse file

[Suresh S]

Hi Ulf,

nice of u for ur mail which well describes mod
attribute in a resourse file.

According to your mail( can be seen below) the mod is
not necessery and we need to make use of attribute 
'included_applications'  in resourse file if an
application inculdes sub-applications
  
Here in my applicaiton i make use OTP defined
applications say SASL , EVA , MNESIA ...

So In this case do i need to use mod key attribute or
include_applicaiton attribute ,

now my resourse file applicatoin attribute is defined
this way    
{applications, [kernel,stdlib]}

do i have to difene for SASL, EVA , MNESIA like
{applications, [kernel,stdlib,sasl,eva,mnesia]}

Thanking u 

suresh s

 --- Wiger Ulf <ulf.wiger@REDACTED> wrote: > Hi
Suresh,
> 
> The passage about the 'mod' key refers to so-called
> "included applications".
> 
> It is possible to create a hierarchy of
> applications, where several
> different applications are combined into one complex
> application. This can
> be very useful if you need to create a large
> "run-time complex", but still
> want to break things up into manageable units. Also,
> if you have several
> programmer teams each working on a certain part, it
> is convenient to allow
> them to package their own code as an application,
> and then build larger
> applications out of several smaller ones.
> 
> The way to create a hierarchy of applications is to
> specify sub-applications
> in the 'included_applications' attribute of another
> application. This will
> be recognized by the release handler and the
> application controller.
> 
> When starting the application, the OTP application
> controller only cares
> about the topmost application, and uses the 'mod'
> key in it to identify the
> start function. It is then up to that start function
> to create any processes
> needed by the sub-applications.
> 
> To be precise, the sub-applications are allowed to
> have a 'mod' key as well;
> it is just ignored by the application controller.
> 
> In AXD 301, for example, the ATM signaling
> application is a fairly large
> complex of smaller applications (each ATM signaling
> protocol is an
> application; generic call control is another;
> resource handling, admission
> control, routing, etc. are also applications. They
> all make up one large
> (hierarchical) application, where the startup and
> recovery procedures are
> tightly integrated using "start phases" (another
> feature of the application
> controller).
> 
> In AXD 301, all applications have the same 'mod' key
> ({sysApp,
> {sysAppCB,[]}}), where sysApp:start(Type, ...) (an
> AXD 301-specific
> function) takes care of starting the topmost
> application as well as all
> included applications. It is not terribly difficult
> to write such a
> function, and it can use application:get_key(App,
> included_applications) and
> application:get_key(App, mod) to extract the
> information needed to start
> included applications automatically.
> 
> Regards,
> Ulf Wiger
> 
> ----- Original Message -----
> From: "Suresh S" <sureshsaragadam@REDACTED>
> To: "Wiger Ulf" <ulf.wiger@REDACTED>
> Cc: <erlang-questions@REDACTED>
> Sent: den 30 december 2002 12:13
> Subject: mod key and its role in resourse file
> 
> 
> > Hi Ulf
> >
> > I have some other OTP Based applications like
> mnesian,
> > eva,.. inculded in my applications
> >
> > Acoording to Design Principles of OTP it says
> >
> > Included Applications
> > ---------------------
> > if you want several applications to include an
> > application, it has to be designed as a library
> > application without a start function (the mod key
> in
> > the .app file).
> >
> > So i should not have mod key in my resourse
> file(.app
> > file)
> > Then how do i specify start function of my
> application
> >
> > with out using mod key
> >
> > Starting Applications
> > ---------------------
> > A primary application can be started in one or two
> > steps. The first step is mandatory and the purpose
> of
> > it is to start the main supervisor of the
> application
> > and possible permanent children. The second step
> is
> > optional and its purpose is to synchronize
> processes
> > within an application.
> >
> > Thanking u sir
> >
> > regards
> > suresh s
> >  --- Wiger Ulf <ulf.wiger@REDACTED> wrote: > The
> part
> > of the OTP documentation that describes
> > > behaviours is:
> > >
> > >
> >
>
http://www.erlang.org/doc/r9b/doc/design_principles/des_princ.html#1.1
> > >
> > > If you want to make a fault tolerant
> application,
> > > the supervisor behaviour
> > > is an essential component. The above document
> also
> > > talks about building
> > > supervision trees. The reference manual for the
> > > 'supervisor' module (part of
> > > stdlib) is also important.
> > >
> > > One of the most common behaviours is gen_server,
> the
> > > generic client-server
> > > behaviour.
> > > Here's a slightly simplified version of
> gen_server.
> > > Perhaps it will clarify
> > > how the callbacks are used. It lacks a few of
> the
> > > gen_server features (see
> > > erl -man gen_server), but behaves essentially
> like
> > > gen_server does.
> >
> >
> >
>
________________________________________________________________________
> > Missed your favourite TV serial last night? Try
> the new, Yahoo! TV.
> >        visit http://in.tv.yahoo.com
>  

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com