When to use erlang application:start or included_applications and a supervisor?
Asked Answered
G

3

6

I have an Erlang application which has a dependency in its deps directory on another application.

From what I understand I can either;

a) start my dependent application from my including application by calling application:start(some_other_app) which starts the application and shows it running standalone within Observer.

b) include my dependent application in my .app file with {included_applications, [some_other_app]} so that the application is loaded and not started and then start the included application from my own top level supervisor. This again starts the included application and shows its running below my own supervision hierarchy in Observer.

My question is when should I use either approach? If I use option “a” and my dependent application exits will it be restarted or should I be using approach “b” so that any dependencies I have are monitored accordingly?

On a side note I use Rebar to package and manage my dependencies.

Thanks,

Andy.

Giantess answered 21/6, 2012 at 15:11 Comment(0)
V
1

Having your dependencies declared in your application descriptor is the way to go, so you should use option B in most of the scenarios.

The application controller will ensure that all your dependencies are present and started (in order) before starting your application and will also make your app fail if those terminate with errors. Also, the application controller will shutdown everything when needed.

Other than that, if you choose option A, when starting an application with application:start/1, you will get a temporary application by default, so you should use application:start/2, passing the permanent atom as the second argument.

EDIT: Having your dependencies in the application descriptor also helps visibility, it's easy to know your deps without scanning the source code.

Vanya answered 21/6, 2012 at 15:36 Comment(4)
Thanks marcelog, that helps clarify things. I thought the application controller would just ensure my dependency is loaded and its the reponsibility of my top level supervisor to start the supervisor of my dependent application or can i do this from my application descriptor? Good point about application:start/2 I'll keep that in mind if I have to use option a).Giantess
@Giantess Hi, see: erlang.org/doc/man/app.html filling the {applications, Apps} option will make those Apps start (and their deps) before yours. included_applications will not start them, just load them. Glad to be of help, dont forget to accept the answer if it was useful. CheersVanya
yes thanks I didnt realise that apps added to {applications, Apps} were also started when a full blown release is generated with reltool. Its fails if i just start my app with application:start(my_app) locally in erlide but can can easily write a function to work around this. Thanks accepting this answer :-)Giantess
Yeah they are started when a release is generated, but they should not be included_applications if you are using releases (which is preferable)Llovera
L
4

You probably shouldn't do either a) nor b)

From Learn You Some Erlang

Look at the chapter: Included Applications

It is more and more recommended not to use included applications for a simple reason: they seriously limit code reuse. Think of it this way. We've spent a lot of time working on ppool's architecture to make it so anybody can use it, get their own pool and be free to do whatever they want with it. If we were to push it into an included application, then it can no longer be included in any other application on this VM, and if erlcount dies, then ppool will be taken down with it, ruining the work of any third party application that wanted to use ppool.

For these reasons, included applications are usually excluded from many Erlang programmers' toolbox. As we will see in the following chapter, releases can basically help us do the same (and much more) in a more generic manner.

In the chapter Release is the Word you can read about how several applications are bundled into a relase and how they are started.

Llovera answered 5/7, 2012 at 18:17 Comment(0)
V
1

Having your dependencies declared in your application descriptor is the way to go, so you should use option B in most of the scenarios.

The application controller will ensure that all your dependencies are present and started (in order) before starting your application and will also make your app fail if those terminate with errors. Also, the application controller will shutdown everything when needed.

Other than that, if you choose option A, when starting an application with application:start/1, you will get a temporary application by default, so you should use application:start/2, passing the permanent atom as the second argument.

EDIT: Having your dependencies in the application descriptor also helps visibility, it's easy to know your deps without scanning the source code.

Vanya answered 21/6, 2012 at 15:36 Comment(4)
Thanks marcelog, that helps clarify things. I thought the application controller would just ensure my dependency is loaded and its the reponsibility of my top level supervisor to start the supervisor of my dependent application or can i do this from my application descriptor? Good point about application:start/2 I'll keep that in mind if I have to use option a).Giantess
@Giantess Hi, see: erlang.org/doc/man/app.html filling the {applications, Apps} option will make those Apps start (and their deps) before yours. included_applications will not start them, just load them. Glad to be of help, dont forget to accept the answer if it was useful. CheersVanya
yes thanks I didnt realise that apps added to {applications, Apps} were also started when a full blown release is generated with reltool. Its fails if i just start my app with application:start(my_app) locally in erlide but can can easily write a function to work around this. Thanks accepting this answer :-)Giantess
Yeah they are started when a release is generated, but they should not be included_applications if you are using releases (which is preferable)Llovera
P
0

I had a similar question, How do you include dependencies in an erlang project, and then how do you release them?

I had some help from various friends, and the erlang mailing list...and after re-reading some docs and more trial and error... I figured some stuff out. It's long, so check out the gist:

https://gist.github.com/3728780

-Todd

Patella answered 16/9, 2012 at 2:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.