[Home]

Summary:ASTERISK-07410: [branch] AEL2 parser doesn't see macros in .conf language files
Reporter:Sherwood McGowan (rushowr)Labels:
Date Opened:2006-07-28 10:05:53Date Closed:2007-08-15 14:20:17
Priority:MinorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The AEL2 parser is apparently not checking existing .conf dialplan files for macros in addition to .ael/.ael2 files, and therefore reports that the macro requested doesn't exist. Example:

File example.conf:

[macro-foo]
exten = s,1,Noop(this macro obviously exists!)

File testing.ael

context testing {
 _X. => {
   Noop(about to call the macro);
   &foo;
 }
}

The code above *should* work since macro-foo exists, but it doesn't. I've thought about naming it foo, but that would make any existing .conf language code break since Asterisk requires that macros have 'macro-' prepend macro names .
Comments:By: Steve Murphy (murf) 2006-07-28 12:26:51

Good point, rushowr!! As soon as I finish 7598, I'll add some code to parse the existing dialplan for macro definitions; and perhaps also other contexts for goto targets. I thought upon this occasionally while writing the checking code, but hadn't worked around to implementing it.

By: Steve Murphy (murf) 2006-07-28 12:28:06

Also, I think that you'll get syntax errors if it's not &foo();
By: Sherwood McGowan (rushowr) 2006-07-28 12:44:04

oops, that's a mistake in my report ;-) Thanks for the kudos on my report by the way!
By: Steve Murphy (murf) 2006-08-01 15:45:57

Until this bug is closed, any work associated with it will be in
teams/murf/bug_7605
By: Steve Murphy (murf) 2006-08-01 20:41:50

The hard part about this one is that I can either access asterisk to fetch
extension/priority info, or I can parse the extensions.conf file myself, and
fetch it. This requires building an extensions.conf parser; fetching such info
directly from asterisk would work only if this module is loaded in asterisk, and has access to asterisk's data. But the stand-alone aelparse will have to parse the extensions.conf file. Either do it both ways, or one way...
By: Sherwood McGowan (rushowr) 2006-08-04 10:45:55

Interesting to see that your second method mentioned involves a parser for the extensions.conf (and related files). I guess bug 7638 was a timely request, eh?
By: Serge Vecher (serge-v) 2006-09-06 10:38:30

monthly checkup
By: Steve Murphy (murf) 2006-09-07 14:32:00

Still in the queue. Probably will have more time for this stuff when 1.4 is forked.
By: jmls (jmls) 2006-11-01 06:49:06.000-0600

monthly checkup :)
By: Sherwood McGowan (rushowr) 2007-01-03 04:06:51.000-0600

Just wanted to check in on this bug. Anything new?
By: Steve Murphy (murf) 2007-01-03 07:44:44.000-0600

rushowr! Long time, no hear! I wrote you emails! It's great to hear from you again! I've started work (slowly) on 7638, the big push was to fix bugs for the 1.4.0 release. I'll start in on this one soon; it's far easier. But I'm not well convinced that the steps I took for 7638 were really good ones, but they will hopefully do for the moment.

I still have some cdr related bugs I'd like to close, but after I do, I'll put some time into these two (this & 7638).
By: jmls (jmls) 2007-03-09 04:45:04.000-0600

monthly checkup :)
By: Steve Murphy (murf) 2007-03-09 09:06:15.000-0600

I've been throwing in an hour here, an hour there, and I've got the code written to read in the extensions.conf data, and to look for cont/ext/pri in that info. Right now, I've been spending considerable time moving things around, so as to avoid conflicts, because the exact same routines exist and are used in other modules; because I need them both standalone and used inside asterisk, because I love a challenge, because I'm a coding fool, etc.etc.etc.
So hang tight, guys. I'm almost there.
By: Sherwood McGowan (rushowr) 2007-03-09 09:32:47.000-0600

Hey I just have to say, thanks murf for working on it! I look forward to testing it :)
By: Steve Murphy (murf) 2007-03-22 22:05:01

OK, I'm going to close down the team/murf/bug_7605 branch, because I implemented the fix in aelparse in the team/murf/bug_7638 branch. Both 7638 and 7605 shared a lot of common code, so it became impractical to try to separate these branches to do the work.

I have a standalone .c file, that contains stolen snippets of code from several other files, and mostly implements the capabilities of reading in config files, and also 'compiling' extensions.conf into the internal structures. So, I have the ability to read in a config file into category/variable structures, and then convert from category/variables into the pbx engine's context/exten structs, without being inside asterisk. I then use this code to read in extensions.conf, for check_goto and the macro reference checking code. They will not issue a warning if they find the target of the goto or macro call in the extensions.conf  structures.

I am able to do this inside asterisk, also, but for one small catch: when pbx_ael is called, the pbx_config stuff might not have loaded yet. Ensuring that pbx_config.so loads before pbx_ael.so is not something that kpfleming feels is appropriate for this sort of enhancement, so I just plain won't do the checks within Asterisk.

So, the utils/aelparse in the team/murf/bug_7638 branch is where you can find this work. It's based on trunk, which is the gosub-based code. Please, everyone interested, give it a spin, and let me know of problems, etc.

By: Steve Murphy (murf) 2007-08-15 14:20:16

I merged this code into trunk via 79595.

Some more work still needs to be on the extconfig stuff, to totally separate it from the actual files it was separated from.

This functionality is available ONLY to aelparse, external to asterisk. It is not available to asterisk, because asterisk loads extensions.conf AFTER extensions.ael, usually, and this makes it difficult to implement.