[erlang-questions] initializing library applications without processes

[Ulf Wiger]

Just beware that my example is mailing-list-quality code.
I've not tried to compile or run it. It is only "obviously
correct".

BR,
Ulf W

karol skocik wrote:
> "Hijacking" supervisor this way is pretty nice idea :)
> Will do for my case.
> 
> Thank you guys for suggestions.
> Karol
> 
> On Sat, Apr 3, 2010 at 8:41 PM, Ulf Wiger
> <ulf.wiger@REDACTED> wrote:
>> I received exactly this question while at the SF Erlang Factory.
>>
>> My suggestion is: start a supervisor with no children. A reasonable
>> "cheat" is to put all of this in the app file
>>
>> -module(myapp).
>> -behaviour(application).
>> -export([start/2, stop/1]).
>> -behaviour(supervisor).
>> -export([init/1]).
>>
>> start(_, _) ->
>>   supervisor:start_link({local,?MODULE},?MODULE,[]).
>>
>> stop(_) -> ok.
>>
>> init([]) ->
>>   %% create tables here...
>>   {ok, {{one_for_one,3,10},[]}}.
>>
>> Baking the supervisor into the application callback module is
>> in a sense against the OTP design rules, but the most notable
>> example of this is surely OTP's 'kernel' application, so you
>> won't be tarred and feathered for doing so. :)
>>
>> BR,
>> Ulf W
>>
>> karol skocik wrote:
>>> Hi,
>>>  sometimes, I just need a library "application" without processes,
>>> which works with some state in ETS. To function properly,
>>> they have to make the ETS table and populate it with values
>>> from config files. When that step is done, there is nothing left to do
>>> for processes, they would just serve as a useless proxy for
>>> querying the ETS table, and that's not needed when you can (in some
>>> contexts)
>>> access the table directly.
>>>
>>> I like the mechanism of applications and their dependency solving,
>>> and I would ideally do application:start(my_app_with_ets_initialised)
>>> but that won't do, since {ok, SupPid} is expected as a result.
>>>
>>> But I don't want to start any processes, I just want to ensure that
>>> application_master:init/4 calls my "start" function,
>>> and declare application as "running" when 'ok' is returned
>>> or fail otherwise (unless it's {ok, SupPid} - as it is now).
>>>
>>> Currently, when we have library application, application:start(...)
>>> does not call anything since 'mod' is not specified in .app file.
>>> Could it be changed, and application behaviour would just call
>>> start/2 and stop/1 as usual, but start the SupPid optionally when it's
>>> supplied?
>>> Or - alternatively - is there any way how to ensure that some init
>>> function is done
>>> fitting nicely with application dependencies as declared in .rel file?
>>>
>>> Thanks,
>>>  Karol
>>>
>>> ________________________________________________________________
>>> erlang-questions (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>
>>
>> --
>> Ulf Wiger
>> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
>> http://www.erlang-solutions.com
>> ---------------------------------------------------
>>
>> ---------------------------------------------------
>>
>> WE'VE CHANGED NAMES!
>>
>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG
>> SOLUTIONS LTD.
>>
>> www.erlang-solutions.com
>>
>>
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 


-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com