[GitHub] [camel-quarkus] davsclaus commented on issue #2101: [GraalVM 21.0.0] Hazelcast extension : using HazelcastSedaProducer with transferExchange=true

[GitBox <gi...@apache.org>]

davsclaus commented on issue #2101:
URL: https://github.com/apache/camel-quarkus/issues/2101#issuecomment-759451482


   The `transferExchange` is a bad design as it enforces to use Camel on both sides, and gives the impression that you can transfer the current state of the exchange to some cache / storage, and then retrieve it later, and then _continue_ routing it.
   
   Its for historical use we had it, and when Java objects wasn't yet a big big security vulnerability and warning.
   
   Instead what is a more general concept would be to have an API for serializing / de-serializing a Camel message with its body and header (eg user payload) and not to include internal exchange state that may be stored as exchange properties and whatnot. 
   
   Such a API / contract can also be used by EIPs and components to store user payload more easily. And then we can have implementations for common types, such as you refer to with json/xml payloads. And for binary then avro/protobuf/what not
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org