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