[erlang-questions] Application startup order in a release

[Karolis Petrauskas]

Hi,

    Thanks for the reply. Altrough I have some troubles with
understanding your language :) Google translates it as "Sent from
Meizu M9".

Karolis

On Wed, Jan 9, 2013 at 1:31 PM, Cloud <cloudqiu1110@REDACTED> wrote:
>
>
> 发送自魅族M9
>
>
> -------- 原始邮件 --------
> 发件人：Karolis Petrauskas <k.petrauskas@REDACTED>
> 时间：周六 1/5 7:25
> 收件人：erlang-questions@REDACTED
> 主题：[erlang-questions] Application startup order in a release
>
>
> Hello,
>
>     My Erlang based system is composed of several applications.The
> applications can be classified to Core, Plugins and Workers. All
> Plugins and Workers have static dependencies on the Core only. I.e
> Plugin and Worker application modules use modules from the Core, and
> have the application Core listed in their *.app files. The Core
> application provides several behaviours and process registries.
> Plugins are providing callback modules for these behaviours and
> registers corresponding processes to the registries. The Worker
> applications use behaviours defined in the Core and use the registries
> to lookup the needed processes. That way the Worker applications can
> use Plugin processes without knowing about them in advance (behaviours
> are used as interface definitions).
>     I am using sys.config to wire-up all the system (telling Workers
> which Plugin-provided processes to use by specifying process names).
> That way I am getting runtime dependencies between the corresponding
> Workers and Plugins. The corresponding Plugins should be started
> before the Workers that have run-time dependencies on them.
>     I am generating release (using rebar) to run my system. As I
> understand, the applications are started according to their
> application dependencies, as listed in the .app files. Here is my
> question: how can I control application startup order in the release
> without including corresponding Plugin applications into the *.app
> files of the Workers? I want to keep the Worker applications as clean
> as possible. Is there a way to control the startup order during
> generation of the release? The only option I know is to transform the
> application files after they are build (rebar compile) and before the
> release is generated (rebar generate). But that sounds hacky. Maybe
> there are better options or maybe my approach on managing application
> dependencies is wrong?
>
>     For example, the static dependencies are the following:
> Plugin1 -> Core, Lib1
> Plugin2 -> Core, Lib2, Lib3
> Worker1-> Core
> Worker2-> Core
>
>     The Lib1, 2, 3 are other applications (e.g. Yaws). They are not
> needed by Workers till the run-time. Even integration tests
> (common-test) can be executed without them. But for the production
> system the following dependencies should be added (or at least the
> corresponding startup order enforced):
> Worker1 -> Plugin1, Plugin2
> Worker2 -> Plugin1
>
> Karolis
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions