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 nowDiscovery
.SEC
is nowSecurity
.
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 bitNDDS_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 bitNDDS_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.