2.1.2.1. RTI Connext Core Libraries

The following issues affect backward compatibility in the Core Libraries starting in release 7.3.0. Issues in the Core Libraries may affect components that use these libraries, including Infrastructure Services and Tools.

2.1.2.1.1. Logging Changes

2.1.2.1.1.1. SECURITY Syslog facility meaning and name have changed

Starting in release 7.3.0, the security facility has been renamed security_event. Its meaning has changed, too: before 7.3.0, this facility was used for security events logged with the Security Plugins Logging Plugin and for RTI TLS Support log messages related to OpenSSL; starting in 7.3.0, this facility is used only for security events logged with the Security Plugins Logging Plugin.

As a result of this change, keep in mind that, if your application uses a Logger Device and relies on the facility field of LogMessage, some messages that used to have the security facility now have middleware. Those security-related messages that now have the middleware facility can still be identified using the LogMessage::is_security_message boolean.

2.1.2.1.1.2. LogMessage is_security_message meaning has changed

Starting in release 7.3.0, LogMessage::is_security_message will also be true for the following messages:

  • Security Plugins Logging Plugin security events.

  • Any message logged by the Security Plugins.

Previously, only RTI TLS Support log messages related to OpenSSL (for example, SSL handshake failures or certificate validation failures) had this field set to true (they still do).

Keep this change in mind if your application uses a Logger Device and relies on the is_security_message field of LogMessage.

2.1.2.1.1.3. Logging category names changed in Activity Context

The following logging category names changed in the Activity Context:

  • DISC is now Discovery.

  • SEC is now Security.

For example, the following message:

ERROR [CREATE DP|LC:DISC]DDS_DomainParticipantFactory_create_participant_disabledI:ERROR: Inconsistent QoS

is now logged as:

ERROR [CREATE DP|LC:Discovery]DDS_DomainParticipantFactory_create_participant_disabledI:ERROR: Inconsistent QoS

Keep this change in mind if your application uses a Logger Device and parses the Activity Context looking for specific logging categories.

2.1.2.1.2. Configuration Changes

2.1.2.1.2.1. Enhanced validation for FlatData language binding in QoS settings for C++ APIs

Since the debut of the RTI FlatData™ language binding in release 6.0.0, you have been able to specify XCDR as the data representation in Quality of Service (QoS) settings for entities that use FlatData, although the only valid data representation for FlatData types is XCDR2. When XCDR was selected in these scenarios, the system would usually issue a warning and convert the data representation to XCDR2 to maintain functionality. While this process was intended to safeguard against configuration errors, it could lead to confusion about the actual data representation being used and could cause a segmentation fault. Note that the FlatData language binding is only valid for the Traditional C++ and Modern C++ APIs.

To ensure clarity and system integrity, the QoS validation logic has been refined. From this release forward, when specifying the data representation QoS for entities using the FlatData language binding, strict enforcement is applied to require XCDR2. Any attempt to configure an entity with XCDR as the data representation for FlatData types will be blocked, with the entity creation call failing.

Starting in this release, if you use the Traditional C++ and Modern C++ APIs, you should examine your entity QoS configurations to ensure compliance with the new validation rules. Make adjustments to use XCDR2 where the FlatData language binding is in use, to align with the updated and more stringent requirements.

2.1.2.1.2.2. MonitoringLoggingForwardingSettings security_forwarding_level renamed security_event_forwarding_level

Because of the change documented in SECURITY Syslog facility meaning and name have changed, the security_forwarding_level field of MonitoringLoggingForwardingSettings has been renamed security_event_forwarding_level.

2.1.2.1.2.3. properties dds.type_plugin.dheader_in_non_primitive_collections and dds.type_plugin.enum_as_primitive_in_collections have been removed

Starting in Connext 7.3.0, the properties dds.type_plugin.dheader_in_non_primitive_collections and dds.type_plugin.enum_as_primitive_in_collections, and environment variables RTI_XCDR_DHEADER_IN_NON_PRIMITIVE_COLLECTIONS and RTI_XCDR_ENUM_AS_PRIMITIVE_IN_COLLECTIONS, have been removed. See RTI Issue ID CORE-13906 in OMG Specification Compliance, in the Core Libraries Release Notes, for more information.

These methods for configuring Extensible Types specification compliance are now managed though an Extensible Types compliance mask, which configures different aspects of the Extended CDR encoding (XCDR and XCDR2).

  • To enable what previously was enabled with the property dds.type_plugin.dheader_in_non_primitive_collections, set the bit NDDS_CONFIG_XTYPES_DHEADER_IN_NON_PRIMITIVE_COLLECTIONS_BIT in the Extensible Types compliance mask. (This bit’s value is 0x00000001.)

  • To enable what previously was enabled with the property dds.type_plugin.enum_as_primitive_in_collections, set the bit NDDS_CONFIG_XTYPES_ENUM_AS_PRIMITIVE_IN_COLLECTIONS_BIT in the Extensible Types compliance mask. (This bit’s value is 0x00000002.)

For more information, see: Extensible Types Compliance Mask in the Core Libraries Extensible Types Guide.