OTP Application's StartArgs

[Serge Aleynikov]

I am sure everyone using the OTP application behavior knows that the 
second argument to the application's start/2 callback is the StartArgs 
from the *.app specifications file:

Module:start(StartType, StartArgs) -> {ok, Pid} | {ok, Pid, State} | 
{error, Reason}

But is it really?  The documentation says that:

   "StartArgs is the StartArgs argument defined by the application
    specification key mod."

In the process of creating a boot file for our application called myapp 
we create the application spec file and a release file:

ebin/myapp.app
priv/myapp.rel

then do:

$ cd priv
$ erlc -pa ../ebin -o ../ebin myapp.rel

This builds the ebin/myapp.boot. (Note: traditionally the boot file 
should go to the "releases/X.Y directory", but it's not important in 
terms of the content of this email).

Now, if I wanted to pass some startup arguments [a, b, c] to 
myapp:start/2 function would I need to add the following entry to the 
myapp.app file?

{application, myapp,
   [ ...
     {mod, {myapp_app, [a, b, c]}}
     ...
   ]
}.

Right?  No, that's wrong!  The boot file myapp.boot has the application 
spec embedded, and therefore if we are starting our system using the 
myapp.boot file, the modified application spec myapp.app will *not* be read.

However, if we stop the application, unload it, and start it again, the 
application spec myapp.app will be read and modified startup arguments 
will be passed to the myapp:start/2 function.

Perhaps this behavior is apparent for some people on the list, but I 
wanted to share this finding with the community, as it indeed cost me an 
hour of digging through the OTP sources to figure it out.

I suggest that the OTP documentation of release handling and application 
behavior reflects this artifact.

Regards,

Serge

-- 
Serge Aleynikov
R&D Telecom, MIS, IDT Corp
Tel: +1 (973) 438-3436
Fax: +1 (973) 438-1464