From OpenTTCN DocZone

Jump to: navigation, search

  OpenTTCN DocZone

  Home | Developer's corner | Knowledge base | Working documents | Documentation | Tutorials | Training | How do I | Frequently asked questions | Technical support

Article's permanent URL

Last modified December 19, 2007

Frequently asked questions


Contents

OpenTTCN SDK for Java

I get java.lang.UnsatisfiedLinkError: no OTSDK error

Q: I get the following error when I try to run the adapter compiled using OpenTTCN SDK for Java: 

Exception in thread "main" java.lang.UnsatisfiedLinkError: no OTSDK in java.library.path

A: Since OpenTTCN SDK for Java uses Java Native Interface (JNI) internally, it comes with a Windows DLL as a part of the bundle. This DLL is used by the OpenTTCN SDK for Java JAR library through JNI. Therefore, you need to make this DLL visible in your DLL library search path. This can be done using java.library.path command-line property of Sun's java.exe.

If for example you have installed OpenTTCN SDK for Java to the following location: 

C:\Program Files (x86)\OpenTTCN\JavaSDK

then the adapter can be launched from the command line like this: 

java.exe -classpath "C:\Program Files (x86)\OpenTTCN\JavaSDK\OTSDK.jar;classes" -Djava.library.path="C:\Program Files (x86)\OpenTTCN\JavaSDK" com.example.Adapter

Note the use of java.library.path in the above script.

I get java.lang.UnsatisfiedLinkError: failed to start error

Q: I get the following error when I try to run the adapter compiled using OpenTTCN SDK for Java: 

Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Program Files (x86)\OpenTTCN\JavaSDK\OTSDK.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem

A: Please donwload and install the latest version of OpenTTCN SDK for Java. This issue is fixed in the most recent version. Please write us to sales@openttcn.fi to find out more about availability of the software.

I get java.lang.UnsupportedClassVersionError

A: Please make sure that you compile and run the adapter with JDK 1.5 or later. Please also make sure that you do not run the adapter with the JRE version that is older than the version of the Java compiler you have used to compile the adapter code.

TCI-CD interface

When a decoding hypothesis is provided and when it is not?

Accurate and reliable decoding hypothesis is provided when you are decoding parameters and return value of a signature in procedure-based communication. Decoding hypothesis is not provided by default if you are decoding a message in message-based communication or an exception. You can change this by setting the following flags in the initialization part of your adapter code:

  • OT_CD_FLAG_EXCEPTIONS_WITH_HYPOTHESIS
  • OT_CD_FLAG_MESSAGES_WITH_HYPOTHESIS

Please see the documentation for these two flags in include/tci/tci_ext.h for more details.

TCI-TM interface

I load a new test case using 'importer3 load' after otTMSelectSession(), but tciStartTestCase() gives error

Q: I have the following sequence of calls in my system:

  • importer3 load MySession MyModule1.ttcn
  • otInitAdapter(0)
  • otTMSelectSession(MySession)
  • tciStartTestCase(TestCaseInMyModule1)

This works fine. But then I do the following:

  • importer3 load MySession MyModule2.ttcn
  • tciStartTestCase(TestCaseInMyModule2)

And the test execution gives a test case error telling that test case 'TestCaseInMyModule2' is undefined. It seems that a test case list does not get updated properly. What went wrong and how do I fix this?

A: After you load a new TTCN-3 module or reload an old one, reselect the session again in your TCI-TM adapter using the following command (example in C): 

otTMSelectSession(MySession);

This should enforce reallocation of the MTC and invalidation of internal system buffers it maintains, so that the test case list gets updated properly.

OpenTTCN Tester

Test log gives error message: 'create' operation failed

A: This indicates that creation of a parallel test component did not succeed. If you observe this behaviour, check the following:

  • if you run under Linux, are you running out of memory on a Linux host?
  • are you creating too many parallel test components so that memory runs low?
  • do you have firewall settings or anti-virus software installed that suppress communication within the local host?
  • is your component type definition correct? It could be that component instance may not be properly created due to incorrect variable initializer part of component variables, or due to similar reasons

If I change only one module, do I need to recompile all?

A: It depends. In many cases you will need to recompile only the module in question. In some cases you need to recompile also dependent modules.

OpenTTCN uses a conceptual separation of each top-level definition in TTCN-3 source code into declaration part and definition part. Declaration part is also historically called "header part" of a definition, therefore by analogy with C++ each module is conceptually viewed as a logical combination of C++ header file and C++ source file.

The following is a regarded as a "header part" of a top-level definition (TLD):

  • for functions, testcases, altsteps: TLD identifier, list of TLD formal parameters with their types, return type, "runs on" and "system" clauses;
  • for typedefs: the typedef in full;
  • for global constants and module parameters: TLD identifier and its type.

The following is a regarded as a "definition part" of a top-level definition:

  • for functions, testcases, altsteps: statement block;
  • for global constants and module parameters: TLD value.

A general rule of thumb is such that whenever you change the "header part" of a definition, you also need to recompile modules dependent on the changed definition in question in addition to recompiling the changed module itself. If, however, you change only the "definition part", you need to recompile only the changed module itself.

Test system development

I have a requirement to build a complex test system consisting of multiple heterogeneous components

Q: I have a requirement to build a complex test system consisting of multiple heterogeneous and highly independent components. It targets a diverse set of applications under test. It involves multiple types of communication (meaning protocols and bearers), multiple transfer syntaxes (meaning codecs), and maybe even multiple languages used to develop codecs and network interface code. Do you have any hints how I can handle this complexity with your tool?

A: Yes we have. We recommend that in this case you develop each component as a self-contained software project. Each such component technically implements one single adapter process. You can develop multiple adapters that are completely independent of each other and then plug them all into the same test system using our extended adapter registration syntax. Using this syntax each adapter would claim to serve only one dedicated TSI port.

You can develop, say, adapter A that serves protocol X in C language and plug it into the test system as serving TSI port p1 by using the following adapter registration syntax in the adapter code (C language): 

otRegisterAdapter("MySession", "TRI:p1");

Then you can develop, say, adapter B that serves protocol Y in Java language and plug it into the same test system as serving TSI port p2 by using the following adapter registration syntax in the adapter code (Java language): 

com.openttcn.sdk.core.CAPI.instance().
    otRegisterAdapter("MySession", "TRI:p2");

Similar kind of registration is also possible with our SDK for .NET.

In this way you will be able to use all these diverse adapters in the same test suite at the same time.

TTCN-3 language

Why TTCN-3 functions cannot return templates with formal parameter lists?

Q: Why the following snippet of TTCN-3 code is illegal: 

template T t_inst(in template integer arg) := { val := arg }

function MyFunc() return template T
{
    return t_inst;
}

function MyCaller() runs on MyMTC
{
    var template T loc_var := MyFunc();
    p.send(loc_var(5));
}

A: When a function returning a template actually returns, it returns effective value of the template, not template definition. Unlike template definitions, template effective values cannot have formal parameters attached to them. Enabling a function to return template definitions may have deep and undesired impact on the consistency of TTCN-3 operational semantics, and this was obviously the reason why designers of the TTCN-3 language opted not doing so.

Retrieved from "http://wiki.openttcn.com/media/index.php/OpenTTCN/FAQ"
Views
Personal tools