Spectra CX is a model driven development tool that helps to simplify the process of developing Software Communications Architecture (SCA) products. New releases of Spectra CX are made available on a regular basis. This page lists the known issues in Specta CX
Known Issues in Spectra CX V3.6.4
1. Generated tests may fail on Linux hosts when using a separate target system
The generated tests and TargetLoader rely on two way communication between host and target systems. When the host and target are separate systems the ORB on the host and target must bind to an IP address which is network accessible in order for the tests to run successfully. By default many Linux systems ship with a network configuration which causes the host side ORB (JacORB) to bind to localhost preventing communication from the remote target to the host system.
This problem can be resolved in two ways:
- Modify the host systems /etc/hosts file to ensure the hostname is listed against a network accessible IP and not localhost. This solution is a permanent fix but requires the machine to have a static IP address allocated to it.
- When running a JUnit test suite append the following VM argument to the launch: -DOAIAddr=<host ip>
2. Test Generation
Test generation is not supported for simple sequence, struct sequence and struct properties.
3. XML import connector ID to external port is failing validation
After importing the XML for a model, if it contains connections to an external port, validation will fail. To resolve this issue, open the connectors SCA properties and set the ID to a valid unique DCE ID.
4. Unable to save model from Project Explorer
Sometimes the Save and Save All menu do not work. The workaround to avoid losing work is to open a diagram, which will re-enable these menu entries. You can also exit Spectra CX and you will be prompted to save the model.
5. Missing validation constraints
When working with CPPDataTypes, which represent external defined types, it is possible to create an association from the CPPDataType to other classes. This is not supported and will cause generation issues.
It is possible to draw an association from a primitive type to a class, which has no meaning and should be disallowed.
Validation constraints to flag these will be added in a future release.
6. Un-setting a build configuration
Currently, build configurations cannot be unset from the build configuration context menu. To unset a build configuration, select the build_config under the implementation in the model tree browser an then select Delete from model from the context menu. You can find more information in the build configuration section of the Spectra CX user guide.
7. Error indications not always cleared after the error has been fixed
Sometimes error messages in the error view are not automatically cleared when the error is fixed. Regenerating the code will clear error indication.
8. DCD validation error on interNode connection
A non-standard feature of SCX is the support for inter-node connections. The DCD generated will fail validation on import or if the user selects the dcd.xml and validates it. To use inter-node connections, the user’s CF must support this.
9. Product updates need to be installed as root on Linux and by an Admin user on Windows
Failure to do so can result in the update not being installed properly.
10. SCA XML import limitations
The following constructs are not currently supported by the SCA XML import facility:
- softpkg/implref
- hostcollocation import
- structsequence import
- Device Packager Descriptor import
- XML import does not assign a port type to a FSP (free standing ports) or an external port during XML
import. As a result, a model with connectors from components to FSP and external ports will not properly
validate until the user sets the port types after import.
11. Model element names should not contain spaces.
- Model element names should not contain spaces. Spectra CX allows model element names to contain spaces. This can result in incorrect code being generated. Model developers should avoid using spaces in model element names. In the future, this restriction will be enforced by the tool.
- Workspace paths should not contain spaces for code generation. If a space exists in a workspace path operating environment specific code will not be copied into the generated source directory. This will cause compilation to fail.
12. Changes to imported model libraries
Any changes made to imported model libraries are not saved. These libraries are read only.
13. Generated code conforms to minimum CORBA specification
All generated code conforms to the minimum CORBA specification with the exception of the entry point code for all components where the ORB shutdown operation is used. All supported ORBs support this operation so this is not believed to be an issue.
14. IDL operation length exceeds 80 characters
If an operation raises a large number of exceptions during IDL generation, it is possible that the line length can exceed 80 characters. If lines exceed 80 characters, IDL generation will fail.
15. Line break required in IDL file
If the last line of the IDL file terminates with a comment, you will receive a parser error. To work around this, ensure a line break is included at the end of the last line.
16. NamingService and ResourceFactory-ref collision
Only the NamingService or the ResourceFactory-ref can be generated. If both of these properties are defined, the ResourceFactory-ref takes precedence and only it will be generated.
17. Support for SCA 2.2
Spectra CX 3.4 onwards by default supports SCA 2.2.2.
18. IDL Generation does not work
If multiple IDLFile elements are selected in the Project Explorer, the user can run the CX Generate > Generate IDL action. However, it only generates one of the selected IDL files and any IDL files it depends on. The user needs to select one IDLFile at a time and generate. This will be addressed in a future release.
19. Save model changes before importing IDL.
If you have unsaved model changes when you start an IDL import, you will either have to lose the model changes or abandon the IDL import. Prior to performing an IDL import, save the model you are working on.
20. Build fails with make versions earlier than 3.81
When building CX generated code, GNU make 3.81 or later is required. The version of make shipped with RTOS’s, such as LynxOS and VxWorks, may be earlier than 3.8.1 and won’t work in the CX build environment.
This requirement is due to a known bug in make 3.80 which affects our Makefiles. When $(eval) evaluates a line that is over 193 characters, make crashes with a “Virtual Memory Exhausted” error. This bug was fixed in make 3.81.
OnWindows systems CX is bundled with MinGW make version 3.81 which is automatically used when building from within CX.
On Linux systems users may find that the host operating system comes with make 3.81 or greater. If this is the case users should use the host operating systems make instead of the version shipped with the RTOS. This can be achieved by ensuring the host operating systems make is first on the path. If the host operating system does not come with a compatible version of make users should download and install GNU make version 3.81 or later.
21. Cannot create an application with 2 or more components
When using Spectra CX generated devices for the PrismTech Spectra Operating Environment, add an execparam to the DomainManager with name and id set to THREADPOOL_NO_POOL, with a value of 1. This instructs the ApplicationFactory not to use a thread pool for its operations. Without this option applications with more than one component will fail to be created.
<simple id=”THREADPOOL_NO_POOL” type=”long” name=”THREADPOOL_NO_POOL” mode=”readwrite”>
<value>1</value>
<kind kindtype=”execparam”/>
</simple>
22. Test generation fails when referencing external IDL files
The ant build scripts currently generated by the test generator do not currently support the referencing of external IDL files. If tests are generated in such a case the generated test code will likely fail due to the referenced IDL not being compiled.
As a workaround users may modify the build.xml file to include the relevant IDL when invoking the IDL compiler.
This can be achieved by adding extra <arg value=”-i”> and <fileset> sections.
Note: This build.xml file will be overwritten each time test code is regenerated.
23. Application fails to create on VxWorks
When a Spectra CX Generated LoadableDevice loads a file on a target it copies the file from the SCA filesystem to its local filesystem. This can take some time on some targets. Since the default monitor timeout is set to 60000 (60 seconds), it could timeout before the application components are loaded and executed. This will cause the monitor to report an Application Creation error. The workaround is to increase the timeout so the applications components have time to be loaded and executed.
24. Free Standing Ports and External Ports (FSP) are not created where they are dropped
When creating a FSP or an external port on a application or platform structure diagram, the port does not appear where it is dropped but will be created on the far left side fo the diagram. In the case of FSP, it will also be moved to the top left corner. If the port is not visible, the user will need to scroll to the left and can then re-position the port by dragging it.
25. Online help responds slowly
The RSA online help system sometimes responds very slowly. An alternative is to download the HTML based help and use a web browser on that directly. Instructions for downloading the HTML help can be found in the installation section in the Spectra manuals.
26. SCA Validation action opens all models in workspace
When user uses Text to set naming service property on a Node then on SCA Validation action all the models in workspace shall be opened alternatively if user does not want this behaviour then reference should be used to set the same.
27. Error undoing DTLTCR port
When creating a DTLTCR port on a SCA Application using palette, undo action can result in a exception alternatively user can use spectra cx context menu to create the same and undo action shall function as expected.
28. Problems with IDL comments
IDL parser and editor don’t recognize certain idl comments, which may be valid otherwise an example is.
module TestModule
{
interface blah
{
void op1( in long x // comment not recognized);
};
};
29. Problem with Generation of JUnit tests with external allocation properties
Now that the logic for allocation/deallocation/query/usagestate of external allocation properties has been deferred to the user worker code and the outcome for those actions is no longer predictable, as users can manipulate those properties as they please, the generation of these test cases id not yet supported property test cases may fail.
30. SpectraCX does not Support IDL defines
SpectraCX parser or editor do not support IDL defines.
31. Runtime Monitor
Runtime monitor property view only displays simple property types.
32. Migration
Migrating a 3.2.0 model to 3.6.x is not supported.
33 Dependency File Names
Do not name IDL file as <module>_<interface> as it can result in name conflict with port dependency file resulting in build failure.
34 Constraint Overridden Property Duplicate ID Type and Name
Constraint might show errors even after correcting previously marked errors. Re validating will remove error markers from project explorer and messages from problems view.
35. Mounting File System Using Run Time Monitor
Mounting a file system using runtime monitor causes null pointer exception.
