[erlang-questions] Included Applications and application:get_application/0

[Bernard Duggan]

Hi Litao,
	I do get what you mean, and I figured that that might have been the
case (thanks, though, for quoting the docs for me - I did manage to miss
that third sentence, which makes it clear that it's intended behaviour
and not a bug).  It does raise the question, however, of handling
configuration.  It seems like, under the current system, configuration
that I put in the included app's .app file will not be retrieved if I
call application:get_env/1.  Instead I have to explicitly call
application:get_env/2 with the application name.  This means that any
code which is shared between apps in my system but which relies on
per-app configuration needs to have the app name explicitly passed down
from code that is specific to the given app.  Additionally, even code
specific to the app needs to hard-code the application name every time
it gets a config parameter.  In other words, there's no neat way to
override a configuration parameter in an included app's configuration,
since it's not actually that app's configuration...kind of.
	I know that's a bit rambling, but hopefully you can see what I'm
getting at: the configuration given for an included app in it's .app,
sys.config or a specified .config file isn't easily reachable without
hard-coding the included app's name throughout the code.
	Perhaps someone can suggest a tidy workaround for this?  I've been
pondering it most of the day and haven't really come up with anything
satisfactory.

Cheers,

Bernard

litao cheng wrote:
> Hi, Bernard.
> I think you have some misunderstanding with the included application in
> erlang otp.
> In the OTP Design Principles - Included Application 8.1, the document says:
> "
> The application controller will automatically load any included applications
> when loading a primary application, but not start them. Instead, the top
> supervisor of the included application must be started by a supervisor in
> the including application
> This means that when running, an included application is in fact part of the
> primary application and a process in an included application will consider
> itself belonging to the primary application.
> "
> From the document, we can known the Top supervisor of the included
> application must be started by the primary application.
> 
> Now, Let's see what happen when we call application:get_application/0 in
> included application, it will call
> application_controller:get_application(group_leader()) (in application.erl
> ), the group_leader() must be same as the primary application, because they
> run in the same supervisor tree.  If you don't agree with this conclusion,
> let's continue! In application_controller.erl, get_application/1 call
> ets:match/2 from the ac_table:ets:match(ac_tab, {{application_master, '$1'},
> Master}), the item with the element is application_master is only inserted
> by started application, the included application insert item to ac_tab with
> 'loaded' identify.
> 
> I hope you can understand my mean. :)
> 
> BS
> 
> 
> 2009/1/12 Bernard Duggan <bernie@REDACTED>
> 
>> Hi all,
>>    I'm working on a set of applications in a "primary
>> application/included applications" type arrangement as described in the
>> OTP Design Principles document.  I'm curious if there is a programmatic
>> way to tell which of the apps a process is considered to be running in.
>> application:get_application/0 appears to always return the primary
>> application, even when called from an included application.  Is this
>> intentional?  Is it a bug?  Am I misunderstanding something about the
>> nature of included applications, such as them only being "applications"
>> in some senses but not others (and if so, what senses are those...if you
>> follow me)?
>>
>> Cheers,
>>
>> Bernard
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>