[erlang-questions] inets services startup

[Daniel Goertzen]

We've used linux FUSE with great success to integrate a number of 3rd 
party apps in an embedded system.  Whenever one of those apps reads a 
config file, our FUSE code generates the config on the fly.

Mind you, this was all in C++, but there is some work being done on an 
erlang binding for FUSE: 
http://www.erlang.org/pipermail/erlang-questions/2007-January/025055.html

I don't know if this would solve all your problem... and it would force 
you to use linux.

Dan.

Serge wrote:
> I've been trying to work around the inets startup issue described in the 
> former email of failing to crash inets in case of a inability to start 
> for a httpd service given its configuration file.  I also need to run 
> inets as an embedded application.  The best solution I could come up 
> with was not to use inets' own supervisor, but start a custom one, 
> register it as 'httpd_sup' so that httpd_sup:start_child/1 could be used 
> to link to this supervisor.  Since httpd_sup:start_child/1 doesn't 
> accept the supervisor name I am enforced to call this supervisor 
> 'httpd_sup'.  Are there any more elegant ways of embedding inets and 
> solving the described issue aside from patching the distribution?
>
> What I would like to see implemented in inets is a function:
>
> httpd_sup:start_child(Supervisor, ConfigList)
>    Supervisor = atom()            % Name of a parent supervisor
>    ConfigList = [{Option, Value}] % What's returned by httpd_conf:load/1
>
> Serge
>
>
> -module(test_app).
> -behaviour(application).
>
> %% application callbacks
> -export([start/2, stop/1]).
>
> %% supervisor callbacks
> -export([init/1]).
>
> %%%-------------------------------------------------------------------
> %%% Callbacks functions from application
> %%%-------------------------------------------------------------------
>
> %%--------------------------------------------------------------------
> %% @spec start(Type, StartArgs) -> Result
> %%         Result = {ok, Pid}        |
> %%                  {ok, Pid, State} |
> %%                  {error, Reason}
> %% @doc Start application callback
> %% @end
> %% @private
> %%--------------------------------------------------------------------
> start(_Type, StartArgs) ->
>      {ok, ConfigFile} = application:get_env(test_app, httpd_config_file),
>      case supervisor:start_link({local, httpd_sup}, ?MODULE, []) of
>      {ok, Pid} ->
>          case catch httpd_sup:start_child(ConfigFile) of
>          {ok, _Child} ->
>              {ok, Pid};
>          {error,Error} ->
>              {error, Error}
>          end;
>      {error, Error} ->
>          {error, Error}
>      end.
>
> %%--------------------------------------------------------------------
> %% @spec stop(Reason) -> any
> %% @doc Stop application callback
> %% @end
> %% @private
> %%--------------------------------------------------------------------
> stop(_Reason) ->
>      ok.
>
> %%%-------------------------------------------------------------------
> %%% Callback functions from supervisor
> %%%-------------------------------------------------------------------
>
> %%%-------------------------------------------------------------------
> %%% Internal functions
> %%%-------------------------------------------------------------------
>
> init(_Args) ->
>      {ok, {{one_for_one, 10, 3600}, []}}.
>
>
> Serge Aleynikov wrote:
>   
>> While accidentally entering wrong information in inets' server 
>> configuration file I got an error report stating that a child spec was 
>> not created.  As a result the corresponding service didn't get started.
>>
>> Upon examining sources, I found the following code with 
>> exit({error,Reason}) commented out:
>>
>> httpd_sup.erl:
>> ==============
>> child_spec([], Acc) ->
>>      Acc;
>> child_spec([{httpd, HttpdService} | Rest], Acc) ->
>>      NewHttpdService = mk_tuple_list(HttpdService),
>>      %%    Acc2 = child_spec2(NewHttpdService,Acc),
>>      NewAcc=
>>      case catch child_spec2(NewHttpdService) of
>>          {ok,Acc2} ->
>>          [Acc2|Acc];
>>          {error,Reason} ->
>>          error_msg("failed to create child spec for ~n~p~ndue to: ~p",
>>                [HttpdService,Reason]),
>> %       exit({error,Reason})
>>          Acc
>>      end,
>>      child_spec(Rest,NewAcc).
>>
>> I was wondering what the authors had in mind by somewhat silently 
>> ignoring the critical error at startup.  Wouldn't it be proper to 
>> uncomment that line?
>>
>> Serge
>>
>>     
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
>