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 <> wrote:
>>> 发送自魅族M9
>>> -------- 原始邮件 --------
> 发件人：Karolis Petrauskas <>
> 时间：周六 1/5 7:25
> 收件人：> 主题：[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
>>http://erlang.org/mailman/listinfo/erlang-questions