Fix: Enhance JMS Header Handling for Null Values with proper Kafka Header Mapping

[Joel-hanson]

Description

This pull request introduces enhancements and tests to handle JMS message headers, specifically addressing cases where headers may have null values. It ensures that null properties are correctly processed and optionally copied to Kafka headers based on configuration. The changes include updates to both the main implementation and corresponding test cases.

Enhancements to JMS Header Processing:

• src/main/java/com/ibm/eventstreams/connect/mqsource/processor/JmsToKafkaHeaderConverter.java: Updated the convertJmsPropertiesToKafkaHeaders method to handle null JMS properties gracefully by using Objects.toString to convert null to null instead of throwing an exception.

New Test Cases for JMS Header Handling:

• src/integration/java/com/ibm/eventstreams/connect/mqsource/MQSourceTaskIT.java: Added two integration tests:

  • verifyJmsMessageWithNullHeaders: Verifies that JMS message headers with null values are correctly copied to Kafka headers when the copy feature is enabled.
  • verifyJmsMessageNoHeaderCopied_WhenCopyDisabledHavingNullHeader: Ensures no headers are copied to Kafka when the copy feature is disabled, even if some headers have null values.

• src/test/java/com/ibm/eventstreams/connect/mqsource/JmsToKafkaHeaderConverterTest.java: Enhanced the unit test convertJmsPropertiesToKafkaHeaders to include a scenario where one of the JMS properties is null, verifying that it is handled correctly.

Minor Code Improvements:

• src/main/java/com/ibm/eventstreams/connect/mqsource/processor/JmsToKafkaHeaderConverter.java: Added an import for java.util.Objects to support the new null-handling logic.

Fixes #145

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Integration tests

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules