Re: Splitter does not anymore support attachments?

2023-07-29 Thread Claus Ibsen
Hi

There is a ticket related to this
https://issues.apache.org/jira/browse/CAMEL-19675

On Fri, May 5, 2023 at 1:49 PM Kessler, Joerg 
wrote:

>
> Hi all,
> We are migrating from Camel 2 to Camel 3. I know that the attachment
> handling has changed here. We were able to adjust most of the code. But now
> I am somehow stuck. We support a format that is a compound message and we
> use the splitter to split such a message in single messages using the
> POJO/Bean approach provided by the splitter. The splitter Bean returns a
> list of Camel messages. The problem I have now is that those messages can
> also have attachments. And now due to the new logic those attachments are
> lost since they are part of the Camel Exchange (and not anymore of the
> message) which is not preserved by the splitter. I think I found the
> corresponding code in org.apache.camel.processor.Splitter:
> public ProcessorExchangePair next() {
> Object part = iterator.next();
> if (part != null) {
> // create a correlated copy as the new exchange to
> be routed in the splitter from the copy
> // and do not share the unit of work
> Exchange newExchange =
> processorExchangeFactory.createCorrelatedCopy(copy, false);
>
> newExchange.adapt(ExtendedExchange.class).setTransacted(original.isTransacted());
> // If the splitter has an aggregation strategy
> // then the StreamCache created by the child
> routes must not be
> // closed by the unit of work of the child route,
> but by the unit of
> // work of the parent route or grand parent route
> or grand grand parent route... (in case of nesting).
> // Therefore, set the unit of work of the parent
> route as stream cache unit of work, if not already set.
> if
> (newExchange.getProperty(ExchangePropertyKey.STREAM_CACHE_UNIT_OF_WORK) ==
> null) {
>
> newExchange.setProperty(ExchangePropertyKey.STREAM_CACHE_UNIT_OF_WORK,
> original.getUnitOfWork());
> }
> // if we share unit of work, we need to prepare
> the child exchange
> if (isShareUnitOfWork()) {
> prepareSharedUnitOfWork(newExchange, copy);
> }
> if (part instanceof Message) {
> newExchange.setIn((Message) part);
> } else {
> Message in = newExchange.getIn();
> in.setBody(part);
> }
> return createProcessorExchangePair(index++,
> processor, newExchange, route);
> } else {
> return null;
> }
> My proposal would be to also add the attachments here to the new Exchange.
> Alternatively newExchange.setIn()  could also set the attachments. Any
> other solution proposal is of course also welcome.
>
> Regards,
>
> Jörg
>


-- 
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2


Splitter does not anymore support attachments?

2023-05-05 Thread Kessler, Joerg

Hi all,
We are migrating from Camel 2 to Camel 3. I know that the attachment handling 
has changed here. We were able to adjust most of the code. But now I am somehow 
stuck. We support a format that is a compound message and we use the splitter 
to split such a message in single messages using the POJO/Bean approach 
provided by the splitter. The splitter Bean returns a list of Camel messages. 
The problem I have now is that those messages can also have attachments. And 
now due to the new logic those attachments are lost since they are part of the 
Camel Exchange (and not anymore of the message) which is not preserved by the 
splitter. I think I found the corresponding code in 
org.apache.camel.processor.Splitter:
public ProcessorExchangePair next() {
Object part = iterator.next();
if (part != null) {
// create a correlated copy as the new exchange to be 
routed in the splitter from the copy
// and do not share the unit of work
Exchange newExchange = 
processorExchangeFactory.createCorrelatedCopy(copy, false);

newExchange.adapt(ExtendedExchange.class).setTransacted(original.isTransacted());
// If the splitter has an aggregation strategy
// then the StreamCache created by the child routes 
must not be
// closed by the unit of work of the child route, but 
by the unit of
// work of the parent route or grand parent route or 
grand grand parent route... (in case of nesting).
// Therefore, set the unit of work of the parent route 
as stream cache unit of work, if not already set.
if 
(newExchange.getProperty(ExchangePropertyKey.STREAM_CACHE_UNIT_OF_WORK) == 
null) {

newExchange.setProperty(ExchangePropertyKey.STREAM_CACHE_UNIT_OF_WORK, 
original.getUnitOfWork());
}
// if we share unit of work, we need to prepare the 
child exchange
if (isShareUnitOfWork()) {
prepareSharedUnitOfWork(newExchange, copy);
}
if (part instanceof Message) {
newExchange.setIn((Message) part);
} else {
Message in = newExchange.getIn();
in.setBody(part);
}
return createProcessorExchangePair(index++, processor, 
newExchange, route);
} else {
return null;
}
My proposal would be to also add the attachments here to the new Exchange. 
Alternatively newExchange.setIn()  could also set the attachments. Any other 
solution proposal is of course also welcome.

Regards,

Jörg