is it possible create two "asterisk" instances with "asterisk java"?

Question

i'm working with asterisk test suite and also creating custom test. but i'm trying replace some python script with java.

the problem is i don't know how to create two asterisk instances with custom dial plan for each one using "asterisk java".

Answer 1

Well, the good news is that with the exception of the upper most run-tests.py script, the Asterisk Test Suite is language agnostic. You'll find tests written in python, lua, and even bash. Java would be a new addition. I wouldn't recommend trying to rewrite runtests.py - you won't get a lot of bang for the buck, although I suppose you're welcome to do so.

As far as 'sandboxing' an instance of Asterisk, such that it doesn't collide with other Asterisk instances and you can run any number simultaneously, there are a number of steps you have to take to make that work properly. Luckily, if you take a look at the asterisk.py module (in lib/python/asterisk) - or astlib.lua in asttest/lib/lua - you'll have some working examples of everything that has to be done to make that happen.

At a minimum, you'll need to do the following:

• Create the directory structure that will host your test. By convention, each test that executes runs under /tmp/asterisk-testsuite/[test_directory], where [test_directory] may contain multiple subdirectories and is reflective of that test's location in the test-suite. Note that there's a number of things in the top most script that expects things to be in that relative location in the case that a test fails, so I wouldn't move it from there.
• Create subfolders in your test directory that corresponds to the instances of Asterisk that you're going to run. These are typically named astn, where n is the next available number in that directory. Say, for example, you have two instances of Asterisk that you run during a test. The first time you run your test, you'd have subdirectories ast1 and ast2 made. The next time; ast3 and ast4.
• For each instance of Asterisk you're going to spawn, create an asterisk.conf configuration file that specifies, relative to the location mentioned in the previous two steps, the location of all of the Asterisk configuration directories. You would then 'install' the created asterisk.conf into /tmp/asterisk-testsuite/[test_directory]/ast[n]/etc/asterisk/asterisk.conf.
• Install the remainder of the needed configuration files. What the python/lua libraries do is to hardlink to the configuration files detected on the host system if the tests do not provide a configuration file; otherwise they copy the configuration files into those directories.
• Hardlink to the modules that are installed on the system. If you have custom modules for each test, you can place them in the test run directory.
• When you spawn Asterisk, you specify a different configuration location then the default with the -C option.

As an example, lets take the confbridge python test. It spawns three instances of Asterisk. The first time it runs, it goes out and sees if /tmp/asterisk-testsuite exists. Lets say it doesn't. So we make that directory.

/tmp/asterisk-testsuite/

We then see that the test being run lives in tests/apps/confbridge - so we make our test directory, since we haven't run yet either.

/tmp/asterisk-testsuite/apps/confbridge

Now it gets interesting. We haven't run before, so when we check to see if any astn directories exist in our test directory, we determine that there aren't. So we create three of those directories.

/tmp/asterisk-testsuite/apps/confbridge
                                       /ast1
                                       /ast2
                                       /ast3

Taking only ast1 as an example, we create an asterisk.conf file containing locations to our paths:

[directories](!)
astetcdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/etc/asterisk
astmoddir => /tmp/asterisk-testsuite/apps/confbridge/ast1/usr/lib/asterisk/modules
astvarlibdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astdbdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astkeydir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astdatadir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk
astagidir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/lib/asterisk/agi-bin
astspooldir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/spool/asterisk
astrundir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/run/asterisk
astlogdir => /tmp/asterisk-testsuite/apps/confbridge/ast1/var/log/asterisk

[options]
verbose = 5
debug = 5
defaultlanguage = en           ; Default language
documentation_language = en_US  ; Set the language you want documentation
                ; displayed in. Value is in the same format as
                ; locale names.   
[compat]
pbx_realtime=1.6
res_agi=1.6
app_set=1.6

We now copy our asterisk.conf into our test directory.

/tmp/asterisk-testsuite/apps/confbridge/ast1/etc/asterisk/asterisk.conf

We would then hardlink the necessary installed module shared objects to the /var/lib/asterisk/modules subdirectory, and hardlink the installed configuration files to the /etc/asterisk subdirectory. Alternatively, for /var/lib/asterisk/modules, we could have just let that use the standard installed modules and not done the hardlinking, if you so desire.

Finally, when we spawn Asterisk, we use the following syntax:

asterisk -f -g -q -m -n -C /tmp/asterisk-testsuite/apps/confbridge/ast1/etc/asterisk/asterisk.conf

Addendum to what I wrote above

There's nothing wrong with Java, but there's also a lot of re-inventing of the wheel you're going to have to do if you decide to go with a new language in the Test Suite - and not just in getting Asterisk spawned. We've written a lot of other stuff into the lua/python libraries that makes your life easier in addition to everything I've described here. Things like common test classes for CDR parsing and manipulation, voicemail manipulation, complex state machine interactions with SIPp, tests that harness multiple SIPp instances and orchestrate them in conjunction with the Test Suite - and we've been particularly focusing on the python libraries as of late. You may want to consider just going with Python - but, if you really love Java, by all means feel free to use that.