Re: Counterintuitive behavior in S3 producer and consumer
By the way I'll have another look. I don't remember this behavior, at least
not with bucket2 explicit in the URI
Il ven 14 lug 2023, 23:42 Andrea Cosentino ha scritto:
> This is a known behavior.
>
> You need to override the header explicitly.
>
> Il ven 14 lug 2023, 23:05 Anthony Wu ha scritto:
>
>> Hi folks,
>>
>> I noticed something odd in Camel 3.14.x where, if you have a
>> from("aws2-s3://bucket1") and a to("aws2-s3://bucket2") - basically a
>> download, some processing in the middle, and an upload of a different file
>> and a different bucket (where the KEY header is set to tell Camel which
>> file to use), bucket1 is apparently sticky and only overriding the
>> BUCKET_NAME header before processing the upload works.
>>
>> Is this known behavior with the way Camel processes message bodies/headers
>> for the S3 component in particular? I would have expected the explicit
>> bucket name in the Camel URI to override the settings, but apparently it
>> doesn't take. I'm wondering if this qualifies as a bug or perhaps
>> something
>> to point out in documentation.
>>
>> Happy to attach a test if folks are having trouble reproducing.
>>
>> Anthony
>>
>
Re: Counterintuitive behavior in S3 producer and consumer
This is a known behavior.
You need to override the header explicitly.
Il ven 14 lug 2023, 23:05 Anthony Wu ha scritto:
> Hi folks,
>
> I noticed something odd in Camel 3.14.x where, if you have a
> from("aws2-s3://bucket1") and a to("aws2-s3://bucket2") - basically a
> download, some processing in the middle, and an upload of a different file
> and a different bucket (where the KEY header is set to tell Camel which
> file to use), bucket1 is apparently sticky and only overriding the
> BUCKET_NAME header before processing the upload works.
>
> Is this known behavior with the way Camel processes message bodies/headers
> for the S3 component in particular? I would have expected the explicit
> bucket name in the Camel URI to override the settings, but apparently it
> doesn't take. I'm wondering if this qualifies as a bug or perhaps something
> to point out in documentation.
>
> Happy to attach a test if folks are having trouble reproducing.
>
> Anthony
>
Counterintuitive behavior in S3 producer and consumer
Hi folks,
I noticed something odd in Camel 3.14.x where, if you have a
from("aws2-s3://bucket1") and a to("aws2-s3://bucket2") - basically a
download, some processing in the middle, and an upload of a different file
and a different bucket (where the KEY header is set to tell Camel which
file to use), bucket1 is apparently sticky and only overriding the
BUCKET_NAME header before processing the upload works.
Is this known behavior with the way Camel processes message bodies/headers
for the S3 component in particular? I would have expected the explicit
bucket name in the Camel URI to override the settings, but apparently it
doesn't take. I'm wondering if this qualifies as a bug or perhaps something
to point out in documentation.
Happy to attach a test if folks are having trouble reproducing.
Anthony
Re: Spring RabbitMQ Component
thanks but I forgot to mention we do not use spring-boot so there is no
auto-wiring or annotation magic and we also do not use the xml declaration
of routes.
We do everything programmatically so I was targeting something like the
following
return CachingConnectionFactory().apply {
...
this.setPublisherConfirmType(CachingConnectionFactory.ConfirmType.SIMPLE)
}
and simply adding the connection factory to the registry to make it
available to the routes.
You mentioned an AmqpAdmin which I am not privy to. I will have to read
more on the subject
On Fri, Jul 14, 2023 at 1:18 PM Federico Mariani <
federico.mariani.1...@gmail.com> wrote:
> IRONSCALES couldn't recognize this email as this is the first time you
> received an email from this sender federico.mariani.1990 @ gmail.com
>
> Hello,
>
> You can leverage spring-boot autoconfiguration using
> spring.rabbitmq.publisher-confirm-type
> and spring.rabbitmq.publisher-returns properties and camel will autowire
> the CCF and the AmqpAdmin.
>
> Il giorno ven 14 lug 2023 alle ore 12:55 Santiago Acosta <
> santiago.aco...@intermodaltelematics.com> ha scritto:
>
> > I have seen that there is a way to configure Publisher Confirms in the
> old
> > RabbitMQ component but I have not found an equivalent in the Spring
> version
> > of the component.
> >
> > I understand that Spring provides 3 publisher confirm modes when using
> > CachingConnectionFactory: NONE, SIMPLE, CORRELATED.
> >
> > Is configuring the CCF directly the intended way to configure Publisher
> > Confirms in Camel?
> >
> > --
> > Best regards,
> >
> > *Santiago Acosta Arreaza*
> >
>
--
Best regards,
*Santiago Acosta Arreaza*
Re: Spring RabbitMQ Component
Hello, You can leverage spring-boot autoconfiguration using spring.rabbitmq.publisher-confirm-type and spring.rabbitmq.publisher-returns properties and camel will autowire the CCF and the AmqpAdmin. Il giorno ven 14 lug 2023 alle ore 12:55 Santiago Acosta < santiago.aco...@intermodaltelematics.com> ha scritto: > I have seen that there is a way to configure Publisher Confirms in the old > RabbitMQ component but I have not found an equivalent in the Spring version > of the component. > > I understand that Spring provides 3 publisher confirm modes when using > CachingConnectionFactory: NONE, SIMPLE, CORRELATED. > > Is configuring the CCF directly the intended way to configure Publisher > Confirms in Camel? > > -- > Best regards, > > *Santiago Acosta Arreaza* >
Spring RabbitMQ Component
I have seen that there is a way to configure Publisher Confirms in the old RabbitMQ component but I have not found an equivalent in the Spring version of the component. I understand that Spring provides 3 publisher confirm modes when using CachingConnectionFactory: NONE, SIMPLE, CORRELATED. Is configuring the CCF directly the intended way to configure Publisher Confirms in Camel? -- Best regards, *Santiago Acosta Arreaza*
