Summary:	ASTERISK-10618: avoid nonexistent context warnings when loading AEL
Reporter:	Dmitry Andrianov (dimas)	Labels:
Date Opened:	2007-10-25 11:25:30	Date Closed:	2007-10-30 23:21:15
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_ael
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When AEL loads its configuration, it produces alot of warnings like [Oct 25 19:59:26] WARNING[2457] pbx.c: Context 'FOO' tries includes nonexistent context 'BAR' This happens because BAR context is defined later than FOO context. When you have really many context, they are most likely spread across multiple files and it is not always possible to organize files in a way that included context are always loaded before including ones. ****** ADDITIONAL INFORMATION ****** It would be best if Asterisk when it encounters 'include' just remember <including context, included context, file/line info> and only when it finished parsing all the files it verifies that all context from the list are defined producing warnings if not.
Comments:	By: Steve Murphy (murf) 2007-10-25 17:15:16 This cannot be. The code for the includes check runs after the whole fileset has been read in, and it searches thru all the contexts that have been defined. I just wrote up a little test and this works fine. context Foo {        includes        {                bar1;        }        102 => NoOp(b); } context bar1 {        101 => NoOp(a); } Please attach the offending extensions.ael file, and we'll see what the real problem is. My first guess is that you are trying to include an empty context; empty contexts are ignored by AEL. If you really need to get rid of the warning, then put some nonsense extension in the empty context. Another guess is that the context you are including is in extensions.conf; this will generate a warning, because at load time, AEL is usually loaded first, and the data will not be available to check. By: Dmitry Andrianov (dimas) 2007-10-25 17:32:18 You are right. AEL perfectly handles contexts in any order they defined. The problem is caused as you are saying by presence of empty contexts. Which will probably lead me to filling another issue depending on IRC conversation :) Sorry for confusion. By: Digium Subversion (svnbot) 2007-10-26 11:33:02 Repository: asterisk Revision: 87168 U   branches/1.4/include/asterisk/ael_structs.h U   branches/1.4/pbx/ael/ael-test/ref.ael-test16 U   branches/1.4/pbx/ael/ael-test/ref.ael-test19 U   branches/1.4/pbx/ael/ael.flex U   branches/1.4/pbx/ael/ael.tab.c U   branches/1.4/pbx/ael/ael.tab.h U   branches/1.4/pbx/ael/ael.y U   branches/1.4/pbx/ael/ael_lex.c U   branches/1.4/pbx/pbx_ael.c U   branches/1.4/utils/ael_main.c ------------------------------------------------------------------------ r87168 | murf | 2007-10-26 11:33:00 -0500 (Fri, 26 Oct 2007) | 1 line closes issue ASTERISK-10618 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config, ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-10-26 12:38:53 Repository: asterisk Revision: 87187 _U  trunk/ U   trunk/include/asterisk/pval.h U   trunk/pbx/ael/ael-test/ref.ael-test16 U   trunk/pbx/ael/ael-test/ref.ael-test19 U   trunk/pbx/pbx_ael.c U   trunk/res/ael/ael.flex U   trunk/res/ael/ael.tab.c U   trunk/res/ael/ael.tab.h U   trunk/res/ael/ael.y U   trunk/res/ael/ael_lex.c U   trunk/res/ael/pval.c U   trunk/utils/ael_main.c U   trunk/utils/conf2ael.c ------------------------------------------------------------------------ r87187 | murf | 2007-10-26 12:38:52 -0500 (Fri, 26 Oct 2007) | 9 lines Merged revisions 87168 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line closes issue ASTERISK-10618 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config, ........ ------------------------------------------------------------------------ By: Dmitry Andrianov (dimas) 2007-10-28 19:21:28 Your patch got rid of most of WARNINGs I had during 'ael reload' but there are still some. While "inside" AEL everything is fine now, it still has problem working with context "external" to AEL, that is created by other modules. Problem 1: The specific problem I have is with context I use as registration context for SIP/IAX devices. That is the one specified as global regcontext in iax.conf/sip.conf. Although the context is created by chan_iax2, 'ael reload' still warns me that context is nonexistent. I believe this happens because AEL only check included contexts against list of contexts defined withing AEL itself. Problem 2: I tried a workaround and defined 'registrations' context within extensions.ael. This made things even worse because AEL's context_find_or_create also looks only within the list of contexts defined within AEL itself so obviously it did not find the context and created new so I ended up having two 'registrations' - one created by IAX and another one created by pbx_ael. I'm not sure about the best way to solve these problems. For #1 probably easiest way is to check agains "public" contexts already defined by the moment AEL loads (that is defined by other modules) in addition to AEL-local contexts. Regarding #2 - probably some kind of real context merging (when contexts with the same name but different registrars) are merged into one may help. However this can lead to lots problems in other areas... By: Steve Murphy (murf) 2007-10-29 18:07:32 Sorry about the mixup. References to contexts formed in other parts of asterisk will probably always be a problem. First, AEL is usually loaded before other modules, so it cannot search the contexts for the name used. Next, I suggested that AEL get loaded near the end, but this idea was rejected, as it would require a bit of work, and it was not believed the benefit big enough to justify it. So, these are just warnings. Suggestions of things to be careful about. Yes, I could make a list of known popular contexts generated by asterisk apps and other modules, but it will probably never be completely up to date. So, for now, you can ignore these warnings and be OK. To try to suppress them by  creating these contexts in AEL is not necessary-- looks harmful in fact. Hmmm. maybe I can expand the message a little and explain a little more so users are not unnecessarily worried about it. By: Steve Murphy (murf) 2007-10-30 23:21:14 Included some explanation in the check_includes function, so that users may better react to the information of the warning. see 87775 in 1.4, and 87776 in trunk.