<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Hmm, there's an old catch here. Someone will have to hollar if it is no longer relevant - but if it isn't, some documentation patch is called for.</div><div><br></div><div>In <a href="http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2">http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2</a></div><div><br></div><div><p style="font-family: Verdana, Arial, Helvetica, sans-serif; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); font-size: medium; "><span class="code" style="font-family: courier; font-weight: normal; ">StartType</span> defines the type of start:</p><ul style="color: rgb(0, 0, 0); font-family: Verdana, Arial, Helvetica, sans-serif; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); font-size: medium; "><li><span class="code" style="font-family: courier; font-weight: normal; ">normal</span> if it's a normal startup.</li><li><span class="code" style="font-family: courier; font-weight: normal; ">normal</span> also if the application is distributed and started at the current node due to a failover from another node, and the application specification key <span class="code" style="font-family: courier; font-weight: normal; ">start_phases == undefined</span>.</li><li><span class="code" style="font-family: courier; font-weight: normal; ">{takeover,Node}</span> if the application is distributed and started at the current node due to a takeover from <span class="code" style="font-family: courier; font-weight: normal; ">Node</span>, either because <span class="code" style="font-family: courier; font-weight: normal; ">application:takeover/2</span> has been called or because the current node has higher priority than <span class="code" style="font-family: courier; font-weight: normal; ">Node</span>.</li><li><span class="code" style="font-family: courier; font-weight: normal; ">{failover,Node}</span> if the application is distributed and started at the current node due to a failover from <span class="code" style="font-family: courier; font-weight: normal; ">Node</span>, and the application specification key <span class="code" style="font-family: courier; font-weight: normal; ">start_phases /= undefined</span>.</li></ul><div>Note that StartType = {failover, Node} is only used if start_phases /= undefined. I will guess that it is for this reason that start_phases is actually set to undefined as default. If it isn't, it was a happy coincidence, since it actually preserves backward compatibility.</div></div><div><br></div><div>This particular oddity was introduced many years ago, in the 90s - possibly even before Erlang was released as Open Source, so the legacy argument may not be that relevant.</div><div><br></div><div>OTOH, I don't think many people use the start_phases attribute, so even new code might break if the Mod:start/2 function is suddenly called with a StartType that was never seen before.</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><br><div><div>On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>The default value for 'start_phases' in .app files should be [], but<br>it is incorrectly set to 'undefined' when generating a release. This<br>happens when the original .app file does not set a value for<br>'start_phases' explicitly.<br><br>The reltool application defines its own copy of a record to handle<br>.app files (#app_info{}, defined in lib/reltool/src/reltool.hrl) that<br>has different default values than the one used by systools<br>(#application{}, defined in lib/sasl/src/systools.hrl). In particular,<br>the 'start_phases' entry is assumed by all of OTP to be [] when it is<br>not explicitly set but reltool sets it to 'undefined' by default. This<br>causes badmatch errors when trying to generate release upgrades.<br><br>Without this patch, all of the rebar examples that generate release<br>upgrades that I've found on the web will fail. The bug was introduced<br>in R14A.<br><br>git fetch <a href="git://github.com/jcomellas/otp.git">git://github.com/jcomellas/otp.git</a> jc-fix-default-start-phases<br><br>Juanjo<br>_______________________________________________<br>erlang-patches mailing list<br><a href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-patches<br></div></blockquote></div><br></body></html>