Summary:	ASTERISK-11664: include block not loaded on asterisk start
Reporter:	Michiel van Baak (mvanbaak)	Labels:
Date Opened:	2008-03-17 11:44:43	Date Closed:	2008-03-18 10:49:15
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_ael
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 12238.patch
Description:	I have several contexts in extenions.ael that do: includes {  other_context; }; Those includes wont show up in 'dialplan show' neither do they work. A simple 'ael reload' will solve this issue.
Comments:	By: Steve Murphy (murf) 2008-03-17 11:54:12 OK, I think I fixed it. Apply the attached patch and give it a spin. By: Michiel van Baak (mvanbaak) 2008-03-17 11:59:59 You fixed it. Thank you. By: Digium Subversion (svnbot) 2008-03-17 12:43:27 Repository: asterisk Revision: 109169 U   trunk/include/asterisk/pbx.h U   trunk/main/pbx.c ------------------------------------------------------------------------ r109169 | murf | 2008-03-17 12:43:25 -0500 (Mon, 17 Mar 2008) | 20 lines (closes issue ASTERISK-11664) Reported by: mvanbaak Tested by: murf, mvanbaak Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the includes, ignorepats, and switches. I added code to do this immediately after the context is created. This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully, this is pretty rare thing. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=109169 By: Digium Subversion (svnbot) 2008-03-18 10:49:15 Repository: asterisk Revision: 109455 _U  branches/1.6.0/ ------------------------------------------------------------------------ r109455 | russell | 2008-03-18 10:49:14 -0500 (Tue, 18 Mar 2008) | 27 lines Blocked revisions 109169 via svnmerge ........ r109169 | murf | 2008-03-17 12:47:36 -0500 (Mon, 17 Mar 2008) | 20 lines (closes issue ASTERISK-11664) Reported by: mvanbaak Tested by: murf, mvanbaak Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the includes, ignorepats, and switches. I added code to do this immediately after the context is created. This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully, this is pretty rare thing. ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=109455