Home
Categories
Dictionary
Glossary
Download
Project Details
Changes Log
What Links Here
FAQ
License

Module instances



Module instances are Java modules which are instances of autodescripted modules. They don't have any implementation because they instanciate their associated autodescripted module.

Specifying that a module is an instance

There are two ways to specify in the applications configuration that a module is an instance:
  • Declaring a module with a name but without any implementation. In that case the framework will look for an autodescripted module to instanciate. In that case the instance name will be generated automatically
  • Declaring an instance with a name for the autodescripted module and an instance for the instance name


Note that:
  • If there is only one autodescripted module in the library for the application, the framework will assume that this is this one, regardless of the module name
  • If there are more than one autodescripted module in the library, you will need to specify the exact name of the module
  • By default if you don't specify the interfaces of the instance, you will use the interfaces defined for the autodescripted module
In this example, the framework detects that module1 is an instance because there is no implementation specification:
      <application name="theAppli">
         <deployment>
            <lib url="myModule.jar" />
         </deployment>
         <modules>
            <module name="module1"/>
         </modules>
      </application>
In this example, the fact that myInstance is an instance is explicit:
      <application name="theAppli">
         <deployment>
            <lib url="myModule.jar" />
         </deployment>
         <modules>
            <instance name="module1" instance="myInstance" />
         </modules>
      </application>

Basic usage

In the most basic usage, you only specify the module name without an implementation. The framework will assume that it is an instance of one of the modules defined in the library.

Examples

Autodescripted modules

Suppose that we have two autodescripted modules:

In the firstModule.jar jar file:
      <application name="autoDesc1">
          <modules>
             <module name="firstModule" >
                <implementation path="org.da.MyModule1" >
                   <initEntryPoint method="init" />
                </implementation>
                <interfaces>
                   <eventSend service="theEvent3"/>
                   <eventReceived service="theEvent4"/>
                </interfaces>
             </module>
          </modules>
      </application>
In the secondModule.jar jar file:
      <application name="autoDesc2">
          <modules>
             <module name="secondModule" >
                <implementation path="org.da.MyModule2" >
                   <initEntryPoint method="init" />
                </implementation>
                <interfaces>
                   <eventSend service="theEvent2"/>
                   <eventReceived service="theEvent1"/>
                </interfaces>
             </module>
          </modules>
      </application>

Module instances

In the following example, there is only one module in the application library, the following configuration uses the firstModule module defined in the first jar file. The name of the instance will be firstModule$1:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <modules>
            <module name="module1" />
         </modules>
      </application>
In this example, there is a specification where we have two modules in the library. We need to specify the correct module name. The name of the instance will be secondModule$1:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
            <lib url="secondModule.jar" />
         </deployment>
         <modules>
            <module name="secondModule" />
         </modules>
      </application>
In this example, we have two modules in the library, and we instanciate one twice. The name of the first instance will be secondModule$1, the name of the second instance will be secondModule$2:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
            <lib url="secondModule.jar" />
         </deployment>
         <modules>
            <module name="secondModule" />
            <module name="secondModule" />
         </modules>
      </application>

Using explicit instances

In this case, you specify explictly that the module is an instance using the instance element.

Examples

The autodescripted modules are the same as those defined in the basic usage example.

In this example, there is a specification where we define the instance name explictly. The name of the instance will be myModule:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
            <lib url="secondModule.jar" />
         </deployment>
         <modules>
            <instance name="secondModule" instance="myModule" />
         </modules>
      </application>

Setting the module instance interfaces


If you define an interface element for the instance, by default you will not use the interfaces defined for the autodescripted module, but those defined specifically for the instance. However it is also possible to keep the autodescripted module.

Example

In the following example, we don't use the interfaces defined for the autodescripted module, but our own:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <modules>
            <module name="firstModule" >
                <interfaces>
                   <eventReceived service="theInstanceEvent"/>
                </interfaces>
            </module>
         </modules>
      </application>

Modules naming

The names of modules which are defined implicitly (by the module element) is derived from the name of the autodescripted module: autodescripted_module_name$instance_index (in the order of declaration).

For example, here the name of the instance will be firstModule$1:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <modules>
            <module name="firstModule" />
         </modules>
      </application>
In this other case, the name of the first instance will be firstModule$1, the second firstModule$2:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <modules>
            <module name="firstModule" />
            <module name="firstModule" />
         </modules>
      </application>
The names of modules which are defined explicitly (by the instance element) is the value of the instance attribute for the instance. For example here the name of the instance will be myInstance:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <modules>
            <instance name="firstModule" instance="myInstance" />
         </modules>
      </application>

Omitting the module declaration

If you define a module instance in an application with only this module, you can omit the modules and module declarations.

For example here this declaration:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <modules>
            <module name="firstModule" >
                <interfaces>
                   <eventReceived service="theInstanceEvent"/>
                </interfaces>
            </module>
         </modules>
      </application>
is equivalent to:
      <application name="theAppli">
         <deployment>
            <lib url="firstModule.jar" />
         </deployment>
         <interfaces>
            <eventReceived service="theInstanceEvent"/>
         </interfaces>
      </application>

Usage in properties and network

The module instances must be named by the name of their instance in the properties configuration and network configuration.

Alternative ways to define properties and network configuration

If there is only one autodescripted module in the application library, it is also possible to define the instance by the name of the application. The framework will associate each instance with the associated property of network configuration, in the order of their definition.

Properties usage example

Suppose the following example: we have one InertialNAV.jar jar file containing an autodescripted module definition specifying the InertialNavSystem module with one Position published interface:
autodescriptedgeneric
and one application which uses this library in two instances:
autodescriptedinstance1
We have the following configuration:
      <application name="aircraft">
         <deployment>
            <lib url="inertialNAV.jar" />
         </deployment>
         <modules>
            <module name="InertialNAVSystem" />
            <module name="InertialNAVSystem" />
         </modules>
      </application>
We can define the properties configuration with:
      <properties>
         <application name="aircraft" >
            <module name="InertialNAVSystem$1" >
               ...
            </module>
            <module name="InertialNAVSystem$2" >
               ...
            </module>
         </application>
      </properties>
or with:
      <properties>
         <application name="aircraft" >
            <module name="InertialNAVSystem" >
               ...
            </module>
            <module name="InertialNAVSystem" >
               ...
            </module>
         </application>
      </properties>

Example

Suppose that we have one InertialNAV.jar jar file containing an autodescripted module definition specifying the InertialNavSystem module with onePosition published interface:
autodescriptedgeneric
Now we define one application which uses this library in two instances:
autodescriptedinstance1
This configuration will be instanciated as:
autodescriptedinstance2

See also


Categories: concepts | development

Copyright 2017-2020 Dassault Aviation. All Rights Reserved. Documentation and source under the LGPL v3 licence