[
https://issues.apache.org/jira/browse/NIFI-12478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794440#comment-17794440
]
ASF subversion and git services commented on NIFI-12478:
--------------------------------------------------------
Commit f73888e7dd4b0df37f5845bc318a7ad85f22d75d in nifi's branch
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=f73888e7dd ]
NIFI-12478 Return Message Type as body for JMS Object Messages (#8131)
> Return Message Type as body for JMS Object Messages
> ---------------------------------------------------
>
> Key: NIFI-12478
> URL: https://issues.apache.org/jira/browse/NIFI-12478
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: David Handermann
> Assignee: David Handermann
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ConsumeJMS Processor supports receiving multiple types of JMS messages
> and implements different serialization strategies for each type of message.
> The JMS ObjectMessage Type provides a generic wrapper around an opaque Java
> Object without any further information. The ConsumeJMS Processor currently
> writes the bytes of an Object using Java Object serialization, which presents
> several issues. Java Object serialization is not compatible with services
> outside of Java, it writes the exact version of the Java Object, and it can
> reference classes that may not be present on the receiving system. This can
> lead to unexpected errors when receiving JMS messages in the context of a
> NiFi Processor. Instead of reporting the message as an error, the message
> metadata could still be useful in some flows. Using the Message Type of
> {{ObjectMessage}} as the output bytes enables this edge case scenario,
> although any system designed to interoperate with NiFi should use other types
> of JMS messages to enable subsequent handling in other Processors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
