[erlang-questions] Application startup order in a release

[Cloud]

发送自魅族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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130109/91f891cb/attachment.htm>