aggregate EIP: wrong correlation key set for aggregate exchanges

[Dinu Pavithran]

I am seeing wrong correlation key is set for the first exchange emitted from 
aggregate EIP. 

In the log below, 
Exchange[7F40FFF506AA26C-000D] is aggregating with correlation key: 
batch-1, but when this exchange is emitted, the property 
CamelAggregatedCorrelationKey is set as batch-4

I saw the same result with Camel v 4.2.0 run using camel-jbang and Camel v 
3.18.4 using camel-main started from Groovy or Java
I also saw the same result when using different aggregation strategies.

Is there something wrong with the way I have configured the EIP?


--- zip-files-2.yaml ---

- route:
    id: zip-files
    from:
      uri: file:{{indir}}
      parameters:
        sort-by: reverse:file:modified #last modified will be the first 
        pre-sort: true
        recursive: true
        max-depth: 3
        min-depth: 3
        antInclude: batches/**
        antExclude: '*/processing-*/*'
        include-ext: csv
        repeatCount: 1
        synchronous: true      
      steps:
      - setHeader:
          name: Batch
          simple: 
${header.CamelFileParent.replaceFirst('{{inDir}}/batches/','')}

      - aggregate: 
          correlation-expression: 
            header: Batch
          aggregation-strategy: 
'#class:org.apache.camel.processor.aggregate.zipfile.ZipAggregationStrategy'
          completion-from-batch-consumer: true
          eager-check-completion: true

      #simplified
      - setHeader:   
          name: LatestBatch
          constant: batch-4
      - setHeader:   
          name: RunID
          constant: 20231120063433118 


      - setHeader:
          name: Batch
          exchangeProperty: CamelAggregatedCorrelationKey

      - log: 
          loggingLevel: debug
          message: Processing batch ${headers.Batch} from exchange ${exchangeId}

      - filter:
          simple: ${headers.LatestBatch} == ${headers.Batch}
          steps:
            # for tracing
            - to: 
file:{{indir}}/{{sentDir}}?file-name=Processing-${header.RunID}-${header.Batch}.zip
            - log: Wrote ${headers.Batch} to ${header.CamelFileNameProduced}
        
            - log: Send ${headers.Batch}

--- tree {{indir}}/batches -- 
in
├── batches
│   ├── batch-1
│   │   ├── events.csv
│   │   └── users.csv
│   ├── batch-2
│   │   ├── events.csv
│   │   └── users.csv
│   ├── batch-3
│   │   ├── events.csv
│   │   └── users.csv
│   ├── batch-4
│   │   ├── events.csv
│   │   └── users.csv
│   └── processing-batch-5
│       ├── events.csv
│       └── users.csv

-- log ---
06:34:29.845  INFO [      main] mel.main.MainSupport : Apache Camel (JBang) 
4.2.0 is starting
06:34:30.061  INFO [      main] mel.main.MainSupport : Using Java 17.0.8.1 with 
PID 481790. Started by vscode in /home/vscode/camel
06:34:30.956  INFO [      main] main.BaseMainSupport : Auto-configuration 
summary
06:34:30.956  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.main.durationMaxIdleSeconds=1
06:34:30.956  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.main.shutdownTimeout=5
06:34:30.957  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.server.enabled=false
06:34:30.957  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.server.healthCheckEnabled=true
06:34:30.957  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.server.devConsoleEnabled=true
06:34:30.958  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.health.enabled=false
06:34:30.958  INFO [      main] main.BaseMainSupport :     
[application.properties]       camel.health.exposureLevel=full
06:34:31.364  INFO [      main] or.LocalCliConnector : Camel CLI enabled (local)
06:34:31.744  INFO [      main] AbstractCamelContext : Apache Camel 4.2.0 
(zip-files-2) is starting
06:34:31.915  INFO [      main] e.AggregateProcessor : Defaulting to 
MemoryAggregationRepository
06:34:32.058  INFO [      main] main.BaseMainSupport : Property-placeholders 
summary
06:34:32.058  INFO [      main] main.BaseMainSupport :     
[application.properties]       indir=in
06:34:32.059  INFO [      main] main.BaseMainSupport :     
[application.properties]       batchDir=in/batches
06:34:32.059  INFO [      main] main.BaseMainSupport :     
[application.properties]       sentDir=send
06:34:32.060  INFO [      main] main.BaseMainSupport :     
[application.properties]       skippedDir=skipped
06:34:32.096  INFO [      main] AbstractCamelContext : Routes startup 
(started:1)
06:34:32.097  INFO [      main] AbstractCamelContext :     Started zip-files 
(file://in)
06:34:32.097  INFO [      main] AbstractCamelContext : Apache Camel 4.2.0 
(zip-files-2) started in 352ms (build:0ms init:0ms start:352ms)
06:34:32.100  INFO [      main] mel.main.MainSupport : Waiting until complete: 
Duration idle 1 seconds
06:34:33.140 DEBUG [ file://in]  zip-files-2.yaml:62 : File 

Re: Jetty Component how to add additional steps after send http response back to the client

[ski n]

Or take a look at the wire tap pattern:

https://camel.apache.org/components/4.0.x/eips/wireTap-eip.html

Raymond

On Sun, Nov 19, 2023 at 2:05 PM Claus Ibsen  wrote:

> Hi
>
> You can also look at using onCompletion
> https://camel.apache.org/manual/oncompletion.html
>
> On Sat, Nov 18, 2023 at 8:36 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > I would also add that HTTP servers like Tomcat, Jetty, JBoss etc have an
> > access log that logs how long time each request takes. And they often
> have
> > a API / plugin you can use to have your custom code triggered by the HTTP
> > server
> > so you can do any kind of "how long time it takes" you need.
> >
> >
> > On Sat, Nov 18, 2023 at 8:34 PM Claus Ibsen 
> wrote:
> >
> >> Hi
> >>
> >> Camel will send back the response at the end of the route in the
> >> consumer, so what you do in that route example will not work.
> >> However if you want to do some kind of custom logging of how long it
> >> takes, then Camel Jetty has send back the response to the client, when
> the
> >> UnitOfWork is done.
> >> So you can use Camel's UoW done to do any custom code for "backend
> >> response timestamp ...".
> >>
> >> See the docs for UnitOfWork or its also covered in the CiA2 book.
> >>
> >>
> >>
> >> On Tue, Nov 14, 2023 at 5:11 AM Han Yainsun 
> wrote:
> >>
> >>> Dear Camel Community and Camel users,
> >>>
> >>> Greetings to you!
> >>>
> >>> Camel version: 3.20.4
> >>> Spring Boot version: 2.7.11
> >>> JDK: Amazon Corretto 17
> >>> Platform: Windows server 2019
> >>> IDE: IntelliJ IDEA 2021.3.2 (Community Edition)
> >>>
> >>> I have an requirement that need calculate each message process time,
> >>> incould total process time and backend process time. the route likes
> below,
> >>> it seems that the jetty managed the http session and send the response
> >>> back to client automatically at the end of route.
> >>>
> >>> Is it possible to explicitly inform jetty send the resonse at specific
> >>> point?
> >>>
> >>> Thansk in advance.
> >>>
> >>> from("jetty:http://0.0.0.0:8080/test;)
> >>> .process(exchange -> exchange.setProperty("inbound timestamp",
> >>> System.currentTimeMillis()))
> >>> .to("http://localhost/mockbackend;)
> >>> .process(exchange -> exchange.setProperty("backend respond timestamp",
> >>> System.currentTimeMillis()))
> >>> .setBody(constant("hello"))
> >>> // I expect jetty send response back to client here.
> >>> .process(exchange -> exchange.setProperty("backend respond timestamp",
> >>> System.currentTimeMillis()));
> >>>
> >>>
> >>
> >> --
> >> Claus Ibsen
> >> -
> >> @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >
> >
> > --
> > Claus Ibsen
> > -
> > @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Steve973]

Claus (and others),

Thank you for sharing your thoughts.  I do not think any of that is harsh,
because it makes perfect logical sense, and it is what I figured.  I
thought I would ask, just in case.  I apologize if my questions were
annoying, and/or a waste of time.  Even though I asked these questions
today, I am perfectly fine with sticking with standard Java and its tools.
Thank you for your patience and good/quick responses.

On Sun, Nov 19, 2023 at 10:36 AM Claus Ibsen  wrote:

> Hi
>
> Okay it may sound harsh when I and other long term Camel core team
> members say No to X or Y.
> However its a very large code base and a project that is ongoing for
> decades, currently 16 and half years old.
> People come and go, and it's important that everything in Camel can be
> picked up and maintained - also components contributed originally be
> someone whom have left.
> For example if you leave and we have to keep maintaining the dynamic router
> component, and we have not spent hours into its code base, and then have
> trouble doing so
> because of bringing in the original author's favourite set of tools.
> And even more now with a lot of focus on CVEs are other scanner tools that
> make people nervous if they report something, and you have to constantly
> chase around and update dependencies.
>
> The code must be easier to maintain and last for decades. And this means
> its standard Java only, and minimal dependencies. And uses Maven only as a
> build system.
> And that it must work with build from Maven (frankly the maven wrapper we
> have in the source).
> The camel builds system is also doing more than just compiling. We have all
> components generate metadata that gets into a camel-catalog, and also into
> generated DSLs (endpoint and component DSLs).
> And we have a route parser library that can scan the source code and
> generate a "visual report" etc that we use for tooling
> (camel-maven-report-plugin) etc.
> All of this makes it harder to maintain if components are not uniform
> around being standard Java only.
>
> The only place we have some non Java code is in the DSLs for groovy, kotlin
> etc.
>
> And also the camel-yaml-dsl unit tests are groovy based. But that is a semi
> mistake and we eventually need to migrate that to plain Java.
> But those tests are 95% focused only on loading some YAML and parse it via
> the yaml-dsl parser, and not a ton of groovy code.
>
> On the other side its is 100% okay to contribute examples that used Kotlin,
> Lombok and have them on your own code repositories,
> but also contribute some of these to Apache Camel in our example repos.
> However the vast majority of those examples should be maintains Java and
> easy to maintain as well.
> But we are fine with having a set of examples that uses what I mentioned
> before.
>
> And as a component developer you will find out - okay I need to add many
> unit tests to cover all its features and help ensure higher QE and ... yes
> that means something you
> need to write more unit tests code in standard Java with JUnit. And yes we
> use docker test containers for integration tests, and there is the
> "camel-test-infra" that can make this easier.
>
>
>
>
> On Sun, Nov 19, 2023 at 2:12 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > No lombok is not allowed - we have as minimal dependency as possible.
> >
> >
> >
> > On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
> >
> >> Hello.  I completely understand the perspective of limiting the addition
> >> of
> >> libraries for various reasons, and especially when the library is
> included
> >> in the distribution.  I know that I have asked about Lombok before, but
> it
> >> is great for eliminating a lot of boilerplate code, especially when a
> >> class
> >> cannot be created as a Java 17 record.  Also, Lombok is a compile-only
> >> dependency that uses annotation processing to generate the
> aforementioned
> >> boilerplate.  The license also seems compatible.  Is this something that
> >> can be used in the coding of a component?  If not, could somebody please
> >> explain the problem with it?
> >>
> >> Thanks,
> >> Steve
> >>
> >
> >
> > --
> > Claus Ibsen
> > -
> > @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Grzegorz Grzybek]

Big -1 for Lombok from me.

I fully agree with Andrea and Claus about this. Especially #4 - debugging
problems.

Saving few lines in Java code which would take you a minute to write,
comparing to seconds of lombok annotation is nothing comparing to
maintenance pain over years. Been there, done that.

Java's verbosity is its big (huge) advantage. After writing and reading
Java code for over 20 years now, I can firmly say - 90% of my professional
career is reading code, 5% is writing and 5% is for meetings.

I know there are handy Lombok annotations and when company policy allows
it, use it (let your entire team use it). But for libraries/frameworks like
Camel there's not advantage at all.

kind regards
Grzegorz Grzybek

niedz., 19 lis 2023 o 16:36 Claus Ibsen  napisał(a):

> Hi
>
> Okay it may sound harsh when I and other long term Camel core team
> members say No to X or Y.
> However its a very large code base and a project that is ongoing for
> decades, currently 16 and half years old.
> People come and go, and it's important that everything in Camel can be
> picked up and maintained - also components contributed originally be
> someone whom have left.
> For example if you leave and we have to keep maintaining the dynamic router
> component, and we have not spent hours into its code base, and then have
> trouble doing so
> because of bringing in the original author's favourite set of tools.
> And even more now with a lot of focus on CVEs are other scanner tools that
> make people nervous if they report something, and you have to constantly
> chase around and update dependencies.
>
> The code must be easier to maintain and last for decades. And this means
> its standard Java only, and minimal dependencies. And uses Maven only as a
> build system.
> And that it must work with build from Maven (frankly the maven wrapper we
> have in the source).
> The camel builds system is also doing more than just compiling. We have all
> components generate metadata that gets into a camel-catalog, and also into
> generated DSLs (endpoint and component DSLs).
> And we have a route parser library that can scan the source code and
> generate a "visual report" etc that we use for tooling
> (camel-maven-report-plugin) etc.
> All of this makes it harder to maintain if components are not uniform
> around being standard Java only.
>
> The only place we have some non Java code is in the DSLs for groovy, kotlin
> etc.
>
> And also the camel-yaml-dsl unit tests are groovy based. But that is a semi
> mistake and we eventually need to migrate that to plain Java.
> But those tests are 95% focused only on loading some YAML and parse it via
> the yaml-dsl parser, and not a ton of groovy code.
>
> On the other side its is 100% okay to contribute examples that used Kotlin,
> Lombok and have them on your own code repositories,
> but also contribute some of these to Apache Camel in our example repos.
> However the vast majority of those examples should be maintains Java and
> easy to maintain as well.
> But we are fine with having a set of examples that uses what I mentioned
> before.
>
> And as a component developer you will find out - okay I need to add many
> unit tests to cover all its features and help ensure higher QE and ... yes
> that means something you
> need to write more unit tests code in standard Java with JUnit. And yes we
> use docker test containers for integration tests, and there is the
> "camel-test-infra" that can make this easier.
>
>
>
>
> On Sun, Nov 19, 2023 at 2:12 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > No lombok is not allowed - we have as minimal dependency as possible.
> >
> >
> >
> > On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
> >
> >> Hello.  I completely understand the perspective of limiting the addition
> >> of
> >> libraries for various reasons, and especially when the library is
> included
> >> in the distribution.  I know that I have asked about Lombok before, but
> it
> >> is great for eliminating a lot of boilerplate code, especially when a
> >> class
> >> cannot be created as a Java 17 record.  Also, Lombok is a compile-only
> >> dependency that uses annotation processing to generate the
> aforementioned
> >> boilerplate.  The license also seems compatible.  Is this something that
> >> can be used in the coding of a component?  If not, could somebody please
> >> explain the problem with it?
> >>
> >> Thanks,
> >> Steve
> >>
> >
> >
> > --
> > Claus Ibsen
> > -
> > @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Claus Ibsen]

Hi

Okay it may sound harsh when I and other long term Camel core team
members say No to X or Y.
However its a very large code base and a project that is ongoing for
decades, currently 16 and half years old.
People come and go, and it's important that everything in Camel can be
picked up and maintained - also components contributed originally be
someone whom have left.
For example if you leave and we have to keep maintaining the dynamic router
component, and we have not spent hours into its code base, and then have
trouble doing so
because of bringing in the original author's favourite set of tools.
And even more now with a lot of focus on CVEs are other scanner tools that
make people nervous if they report something, and you have to constantly
chase around and update dependencies.

The code must be easier to maintain and last for decades. And this means
its standard Java only, and minimal dependencies. And uses Maven only as a
build system.
And that it must work with build from Maven (frankly the maven wrapper we
have in the source).
The camel builds system is also doing more than just compiling. We have all
components generate metadata that gets into a camel-catalog, and also into
generated DSLs (endpoint and component DSLs).
And we have a route parser library that can scan the source code and
generate a "visual report" etc that we use for tooling
(camel-maven-report-plugin) etc.
All of this makes it harder to maintain if components are not uniform
around being standard Java only.

The only place we have some non Java code is in the DSLs for groovy, kotlin
etc.

And also the camel-yaml-dsl unit tests are groovy based. But that is a semi
mistake and we eventually need to migrate that to plain Java.
But those tests are 95% focused only on loading some YAML and parse it via
the yaml-dsl parser, and not a ton of groovy code.

On the other side its is 100% okay to contribute examples that used Kotlin,
Lombok and have them on your own code repositories,
but also contribute some of these to Apache Camel in our example repos.
However the vast majority of those examples should be maintains Java and
easy to maintain as well.
But we are fine with having a set of examples that uses what I mentioned
before.

And as a component developer you will find out - okay I need to add many
unit tests to cover all its features and help ensure higher QE and ... yes
that means something you
need to write more unit tests code in standard Java with JUnit. And yes we
use docker test containers for integration tests, and there is the
"camel-test-infra" that can make this easier.




On Sun, Nov 19, 2023 at 2:12 PM Claus Ibsen  wrote:

> Hi
>
> No lombok is not allowed - we have as minimal dependency as possible.
>
>
>
> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
>
>> Hello.  I completely understand the perspective of limiting the addition
>> of
>> libraries for various reasons, and especially when the library is included
>> in the distribution.  I know that I have asked about Lombok before, but it
>> is great for eliminating a lot of boilerplate code, especially when a
>> class
>> cannot be created as a Java 17 record.  Also, Lombok is a compile-only
>> dependency that uses annotation processing to generate the aforementioned
>> boilerplate.  The license also seems compatible.  Is this something that
>> can be used in the coding of a component?  If not, could somebody please
>> explain the problem with it?
>>
>> Thanks,
>> Steve
>>
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


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

Re: Question about Lombok use

[Steve973]

If the component codebase is java-only, is it permissible to use test
frameworks that use other JVM languages?  I am talking about things like
Spock or Kotest.

On Sun, Nov 19, 2023 at 9:21 AM Steve973  wrote:

> Oh, regarding my other question, which might have gotten lost among the
> bigger discussion about Lombok: is the camel component codebase java-only,
> or is Kotlin also ok?
>
> On Sun, Nov 19, 2023 at 9:20 AM Steve973  wrote:
>
>> Thanks, Andra, for the informative reply.  I understand and appreciate
>> your assessment, and it seems like the correct decision for Apache
>> Camel, given your reasoning.  That clears a lot of things up for me.  My
>> questions are only out of curiosity, so I hope this discussion is
>> reasonable and welcome for you and Claus.  Making the decision for everyone
>> else -- a considerably large community -- is, perhaps, my favorite point on
>> your list.  I had not considered that, but that's huge!  It is also good to
>> know that delombok might not be reliable, since I have not used it before.
>> I will keep that in mind in the future.  I am going to experiment with
>> that, so that I might know what to expect.
>>
>> For only the sake of this discussion (and not in the hope that the use of
>> lombok might be reconsidered), I would like to offer a couple of points for
>> lombok use *outside of Camel and its related repositories*:
>> 1. Since version 1.12, javadoc is handled quite well, and you can see
>> more here  at the end
>> of the "overview" section (at the top).
>> 2. For me, it is not a matter of laziness; as you said, most of the
>> boilerplate is easily generated by IDEs.  To me, it is a matter of "
>> *boilerplate noise"*.  When I look at source code, and when most of the
>> code that is on my screen is only the business logic, then that makes for a
>> nicely decluttered view.  As a workaround, we could utilize things like
>> editor folding regions for getter/setter methods.  Another workaround, for
>> builders, is to use an IDE plugin to generate them.
>>
>> Thanks again!  I always enjoy the discussion.
>>
>> On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino 
>> wrote:
>>
>>> Last but not least, there are no clear, IMO, advantages is using it,
>>> despite the fact you'll see less boilerplate code. This laziness is
>>> something I don't understand. IDEs will generate setters/getters for you
>>> just with a shortcut on classes with thousands of fields.
>>>
>>> Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino <
>>> anco...@gmail.com>
>>> ha scritto:
>>>
>>> > Hello,
>>> >
>>> > Let me add also add a couple of points:
>>> > 1. It's true that is just a compile dependency but when you decide to
>>> use
>>> > lombok, you also decide that everyone else who deals with your code
>>> will
>>> > have to use lombok. Lombok is special in that it is a build-time
>>> dependency
>>> > and your IDE needs plugins to figure out what is going on. So this is
>>> a big
>>> > drawback in my opinion.
>>> > 2. Going back from Lombok to without Lombok, in big projects is not
>>> easy.
>>> > Delombok is not an answer, because it's not reliable.
>>> > 3. We are using the javadoc on getter and setter for generating
>>> > documentation, with Lombok we need to find a different way and since
>>> the
>>> > code is generated I don't think it would be easy.
>>> > 4. Debugging Lombok is a pain.
>>> >
>>> > and I could go ahead.
>>> >
>>> > Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen <
>>> > claus.ib...@gmail.com> ha scritto:
>>> >
>>> >> Hi
>>> >>
>>> >> No lombok is not allowed - we have as minimal dependency as possible.
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
>>> >>
>>> >> > Hello.  I completely understand the perspective of limiting the
>>> >> addition of
>>> >> > libraries for various reasons, and especially when the library is
>>> >> included
>>> >> > in the distribution.  I know that I have asked about Lombok before,
>>> but
>>> >> it
>>> >> > is great for eliminating a lot of boilerplate code, especially when
>>> a
>>> >> class
>>> >> > cannot be created as a Java 17 record.  Also, Lombok is a
>>> compile-only
>>> >> > dependency that uses annotation processing to generate the
>>> >> aforementioned
>>> >> > boilerplate.  The license also seems compatible.  Is this something
>>> that
>>> >> > can be used in the coding of a component?  If not, could somebody
>>> please
>>> >> > explain the problem with it?
>>> >> >
>>> >> > Thanks,
>>> >> > Steve
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Claus Ibsen
>>> >> -
>>> >> @davsclaus
>>> >> Camel in Action 2: https://www.manning.com/ibsen2
>>> >>
>>> >
>>>
>>

Re: Question about Lombok use

[Steve973]

Oh, regarding my other question, which might have gotten lost among the
bigger discussion about Lombok: is the camel component codebase java-only,
or is Kotlin also ok?

On Sun, Nov 19, 2023 at 9:20 AM Steve973  wrote:

> Thanks, Andra, for the informative reply.  I understand and appreciate
> your assessment, and it seems like the correct decision for Apache
> Camel, given your reasoning.  That clears a lot of things up for me.  My
> questions are only out of curiosity, so I hope this discussion is
> reasonable and welcome for you and Claus.  Making the decision for everyone
> else -- a considerably large community -- is, perhaps, my favorite point on
> your list.  I had not considered that, but that's huge!  It is also good to
> know that delombok might not be reliable, since I have not used it before.
> I will keep that in mind in the future.  I am going to experiment with
> that, so that I might know what to expect.
>
> For only the sake of this discussion (and not in the hope that the use of
> lombok might be reconsidered), I would like to offer a couple of points for
> lombok use *outside of Camel and its related repositories*:
> 1. Since version 1.12, javadoc is handled quite well, and you can see more
> here  at the end of the
> "overview" section (at the top).
> 2. For me, it is not a matter of laziness; as you said, most of the
> boilerplate is easily generated by IDEs.  To me, it is a matter of "
> *boilerplate noise"*.  When I look at source code, and when most of the
> code that is on my screen is only the business logic, then that makes for a
> nicely decluttered view.  As a workaround, we could utilize things like
> editor folding regions for getter/setter methods.  Another workaround, for
> builders, is to use an IDE plugin to generate them.
>
> Thanks again!  I always enjoy the discussion.
>
> On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino 
> wrote:
>
>> Last but not least, there are no clear, IMO, advantages is using it,
>> despite the fact you'll see less boilerplate code. This laziness is
>> something I don't understand. IDEs will generate setters/getters for you
>> just with a shortcut on classes with thousands of fields.
>>
>> Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino <
>> anco...@gmail.com>
>> ha scritto:
>>
>> > Hello,
>> >
>> > Let me add also add a couple of points:
>> > 1. It's true that is just a compile dependency but when you decide to
>> use
>> > lombok, you also decide that everyone else who deals with your code will
>> > have to use lombok. Lombok is special in that it is a build-time
>> dependency
>> > and your IDE needs plugins to figure out what is going on. So this is a
>> big
>> > drawback in my opinion.
>> > 2. Going back from Lombok to without Lombok, in big projects is not
>> easy.
>> > Delombok is not an answer, because it's not reliable.
>> > 3. We are using the javadoc on getter and setter for generating
>> > documentation, with Lombok we need to find a different way and since the
>> > code is generated I don't think it would be easy.
>> > 4. Debugging Lombok is a pain.
>> >
>> > and I could go ahead.
>> >
>> > Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen <
>> > claus.ib...@gmail.com> ha scritto:
>> >
>> >> Hi
>> >>
>> >> No lombok is not allowed - we have as minimal dependency as possible.
>> >>
>> >>
>> >>
>> >> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
>> >>
>> >> > Hello.  I completely understand the perspective of limiting the
>> >> addition of
>> >> > libraries for various reasons, and especially when the library is
>> >> included
>> >> > in the distribution.  I know that I have asked about Lombok before,
>> but
>> >> it
>> >> > is great for eliminating a lot of boilerplate code, especially when a
>> >> class
>> >> > cannot be created as a Java 17 record.  Also, Lombok is a
>> compile-only
>> >> > dependency that uses annotation processing to generate the
>> >> aforementioned
>> >> > boilerplate.  The license also seems compatible.  Is this something
>> that
>> >> > can be used in the coding of a component?  If not, could somebody
>> please
>> >> > explain the problem with it?
>> >> >
>> >> > Thanks,
>> >> > Steve
>> >> >
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -
>> >> @davsclaus
>> >> Camel in Action 2: https://www.manning.com/ibsen2
>> >>
>> >
>>
>

Re: Question about Lombok use

[Steve973]

Thanks, Andra, for the informative reply.  I understand and appreciate your
assessment, and it seems like the correct decision for Apache Camel, given
your reasoning.  That clears a lot of things up for me.  My questions are
only out of curiosity, so I hope this discussion is reasonable and welcome
for you and Claus.  Making the decision for everyone else -- a considerably
large community -- is, perhaps, my favorite point on your list.  I had not
considered that, but that's huge!  It is also good to know that delombok
might not be reliable, since I have not used it before.  I will keep that
in mind in the future.  I am going to experiment with that, so that I might
know what to expect.

For only the sake of this discussion (and not in the hope that the use of
lombok might be reconsidered), I would like to offer a couple of points for
lombok use *outside of Camel and its related repositories*:
1. Since version 1.12, javadoc is handled quite well, and you can see more
here  at the end of the
"overview" section (at the top).
2. For me, it is not a matter of laziness; as you said, most of the
boilerplate is easily generated by IDEs.  To me, it is a matter of "
*boilerplate noise"*.  When I look at source code, and when most of the
code that is on my screen is only the business logic, then that makes for a
nicely decluttered view.  As a workaround, we could utilize things like
editor folding regions for getter/setter methods.  Another workaround, for
builders, is to use an IDE plugin to generate them.

Thanks again!  I always enjoy the discussion.

On Sun, Nov 19, 2023 at 8:51 AM Andrea Cosentino  wrote:

> Last but not least, there are no clear, IMO, advantages is using it,
> despite the fact you'll see less boilerplate code. This laziness is
> something I don't understand. IDEs will generate setters/getters for you
> just with a shortcut on classes with thousands of fields.
>
> Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino <
> anco...@gmail.com>
> ha scritto:
>
> > Hello,
> >
> > Let me add also add a couple of points:
> > 1. It's true that is just a compile dependency but when you decide to use
> > lombok, you also decide that everyone else who deals with your code will
> > have to use lombok. Lombok is special in that it is a build-time
> dependency
> > and your IDE needs plugins to figure out what is going on. So this is a
> big
> > drawback in my opinion.
> > 2. Going back from Lombok to without Lombok, in big projects is not easy.
> > Delombok is not an answer, because it's not reliable.
> > 3. We are using the javadoc on getter and setter for generating
> > documentation, with Lombok we need to find a different way and since the
> > code is generated I don't think it would be easy.
> > 4. Debugging Lombok is a pain.
> >
> > and I could go ahead.
> >
> > Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen <
> > claus.ib...@gmail.com> ha scritto:
> >
> >> Hi
> >>
> >> No lombok is not allowed - we have as minimal dependency as possible.
> >>
> >>
> >>
> >> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
> >>
> >> > Hello.  I completely understand the perspective of limiting the
> >> addition of
> >> > libraries for various reasons, and especially when the library is
> >> included
> >> > in the distribution.  I know that I have asked about Lombok before,
> but
> >> it
> >> > is great for eliminating a lot of boilerplate code, especially when a
> >> class
> >> > cannot be created as a Java 17 record.  Also, Lombok is a compile-only
> >> > dependency that uses annotation processing to generate the
> >> aforementioned
> >> > boilerplate.  The license also seems compatible.  Is this something
> that
> >> > can be used in the coding of a component?  If not, could somebody
> please
> >> > explain the problem with it?
> >> >
> >> > Thanks,
> >> > Steve
> >> >
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -
> >> @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >
>

Re: Question about Lombok use

[Andrea Cosentino]

Last but not least, there are no clear, IMO, advantages is using it,
despite the fact you'll see less boilerplate code. This laziness is
something I don't understand. IDEs will generate setters/getters for you
just with a shortcut on classes with thousands of fields.

Il giorno dom 19 nov 2023 alle ore 14:47 Andrea Cosentino 
ha scritto:

> Hello,
>
> Let me add also add a couple of points:
> 1. It's true that is just a compile dependency but when you decide to use
> lombok, you also decide that everyone else who deals with your code will
> have to use lombok. Lombok is special in that it is a build-time dependency
> and your IDE needs plugins to figure out what is going on. So this is a big
> drawback in my opinion.
> 2. Going back from Lombok to without Lombok, in big projects is not easy.
> Delombok is not an answer, because it's not reliable.
> 3. We are using the javadoc on getter and setter for generating
> documentation, with Lombok we need to find a different way and since the
> code is generated I don't think it would be easy.
> 4. Debugging Lombok is a pain.
>
> and I could go ahead.
>
> Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen <
> claus.ib...@gmail.com> ha scritto:
>
>> Hi
>>
>> No lombok is not allowed - we have as minimal dependency as possible.
>>
>>
>>
>> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
>>
>> > Hello.  I completely understand the perspective of limiting the
>> addition of
>> > libraries for various reasons, and especially when the library is
>> included
>> > in the distribution.  I know that I have asked about Lombok before, but
>> it
>> > is great for eliminating a lot of boilerplate code, especially when a
>> class
>> > cannot be created as a Java 17 record.  Also, Lombok is a compile-only
>> > dependency that uses annotation processing to generate the
>> aforementioned
>> > boilerplate.  The license also seems compatible.  Is this something that
>> > can be used in the coding of a component?  If not, could somebody please
>> > explain the problem with it?
>> >
>> > Thanks,
>> > Steve
>> >
>>
>>
>> --
>> Claus Ibsen
>> -
>> @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>

Re: Question about Lombok use

[Andrea Cosentino]

Hello,

Let me add also add a couple of points:
1. It's true that is just a compile dependency but when you decide to use
lombok, you also decide that everyone else who deals with your code will
have to use lombok. Lombok is special in that it is a build-time dependency
and your IDE needs plugins to figure out what is going on. So this is a big
drawback in my opinion.
2. Going back from Lombok to without Lombok, in big projects is not easy.
Delombok is not an answer, because it's not reliable.
3. We are using the javadoc on getter and setter for generating
documentation, with Lombok we need to find a different way and since the
code is generated I don't think it would be easy.
4. Debugging Lombok is a pain.

and I could go ahead.

Il giorno dom 19 nov 2023 alle ore 14:12 Claus Ibsen 
ha scritto:

> Hi
>
> No lombok is not allowed - we have as minimal dependency as possible.
>
>
>
> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
>
> > Hello.  I completely understand the perspective of limiting the addition
> of
> > libraries for various reasons, and especially when the library is
> included
> > in the distribution.  I know that I have asked about Lombok before, but
> it
> > is great for eliminating a lot of boilerplate code, especially when a
> class
> > cannot be created as a Java 17 record.  Also, Lombok is a compile-only
> > dependency that uses annotation processing to generate the aforementioned
> > boilerplate.  The license also seems compatible.  Is this something that
> > can be used in the coding of a component?  If not, could somebody please
> > explain the problem with it?
> >
> > Thanks,
> > Steve
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Steve973]

Does that preference extend to compile-time only, as well?  The scope of
lombok is always set to "provided", so it is never included at runtime.  I
am also curious if any components can be written in other JVM languages,
such as Kotlin (since camel includes the Kotlin DSL), or if it's java-only.

On Sun, Nov 19, 2023 at 8:12 AM Claus Ibsen  wrote:

> Hi
>
> No lombok is not allowed - we have as minimal dependency as possible.
>
>
>
> On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:
>
> > Hello.  I completely understand the perspective of limiting the addition
> of
> > libraries for various reasons, and especially when the library is
> included
> > in the distribution.  I know that I have asked about Lombok before, but
> it
> > is great for eliminating a lot of boilerplate code, especially when a
> class
> > cannot be created as a Java 17 record.  Also, Lombok is a compile-only
> > dependency that uses annotation processing to generate the aforementioned
> > boilerplate.  The license also seems compatible.  Is this something that
> > can be used in the coding of a component?  If not, could somebody please
> > explain the problem with it?
> >
> > Thanks,
> > Steve
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Question about Lombok use

[Claus Ibsen]

Hi

No lombok is not allowed - we have as minimal dependency as possible.



On Sun, Nov 19, 2023 at 2:06 PM Steve973  wrote:

> Hello.  I completely understand the perspective of limiting the addition of
> libraries for various reasons, and especially when the library is included
> in the distribution.  I know that I have asked about Lombok before, but it
> is great for eliminating a lot of boilerplate code, especially when a class
> cannot be created as a Java 17 record.  Also, Lombok is a compile-only
> dependency that uses annotation processing to generate the aforementioned
> boilerplate.  The license also seems compatible.  Is this something that
> can be used in the coding of a component?  If not, could somebody please
> explain the problem with it?
>
> Thanks,
> Steve
>


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

Question about Lombok use

[Steve973]

Hello.  I completely understand the perspective of limiting the addition of
libraries for various reasons, and especially when the library is included
in the distribution.  I know that I have asked about Lombok before, but it
is great for eliminating a lot of boilerplate code, especially when a class
cannot be created as a Java 17 record.  Also, Lombok is a compile-only
dependency that uses annotation processing to generate the aforementioned
boilerplate.  The license also seems compatible.  Is this something that
can be used in the coding of a component?  If not, could somebody please
explain the problem with it?

Thanks,
Steve

Re: Jetty Component how to add additional steps after send http response back to the client

[Claus Ibsen]

Hi

You can also look at using onCompletion
https://camel.apache.org/manual/oncompletion.html

On Sat, Nov 18, 2023 at 8:36 PM Claus Ibsen  wrote:

> Hi
>
> I would also add that HTTP servers like Tomcat, Jetty, JBoss etc have an
> access log that logs how long time each request takes. And they often have
> a API / plugin you can use to have your custom code triggered by the HTTP
> server
> so you can do any kind of "how long time it takes" you need.
>
>
> On Sat, Nov 18, 2023 at 8:34 PM Claus Ibsen  wrote:
>
>> Hi
>>
>> Camel will send back the response at the end of the route in the
>> consumer, so what you do in that route example will not work.
>> However if you want to do some kind of custom logging of how long it
>> takes, then Camel Jetty has send back the response to the client, when the
>> UnitOfWork is done.
>> So you can use Camel's UoW done to do any custom code for "backend
>> response timestamp ...".
>>
>> See the docs for UnitOfWork or its also covered in the CiA2 book.
>>
>>
>>
>> On Tue, Nov 14, 2023 at 5:11 AM Han Yainsun  wrote:
>>
>>> Dear Camel Community and Camel users,
>>>
>>> Greetings to you!
>>>
>>> Camel version: 3.20.4
>>> Spring Boot version: 2.7.11
>>> JDK: Amazon Corretto 17
>>> Platform: Windows server 2019
>>> IDE: IntelliJ IDEA 2021.3.2 (Community Edition)
>>>
>>> I have an requirement that need calculate each message process time,
>>> incould total process time and backend process time. the route likes below,
>>> it seems that the jetty managed the http session and send the response
>>> back to client automatically at the end of route.
>>>
>>> Is it possible to explicitly inform jetty send the resonse at specific
>>> point?
>>>
>>> Thansk in advance.
>>>
>>> from("jetty:http://0.0.0.0:8080/test;)
>>> .process(exchange -> exchange.setProperty("inbound timestamp",
>>> System.currentTimeMillis()))
>>> .to("http://localhost/mockbackend;)
>>> .process(exchange -> exchange.setProperty("backend respond timestamp",
>>> System.currentTimeMillis()))
>>> .setBody(constant("hello"))
>>> // I expect jetty send response back to client here.
>>> .process(exchange -> exchange.setProperty("backend respond timestamp",
>>> System.currentTimeMillis()));
>>>
>>>
>>
>> --
>> Claus Ibsen
>> -
>> @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


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

Re: How to check if an message on an exchange has attachments?

[Claus Ibsen]

Hi

I am adding a function to simple language so this can be done via simple in
the future
https://issues.apache.org/jira/browse/CAMEL-20127

At first its a bit long in the tooth

${messageAs(org.apache.camel.language.simple.MyAttachmentMessage).hasAttachments}



On Sun, Nov 19, 2023 at 12:55 PM Claus Ibsen  wrote:

> Hi
>
> You can look in the source of camel-attachments and see how they are
> stored and then do it by checking for exchange property
> key CamelAttachmentObjects exists and is not empty
>
> On Tue, Nov 14, 2023 at 9:21 PM ski n  wrote:
>
>> As a workaround, I implemented it as follows:
>>
>> public class MyBean {
>>
>>public boolean hasAttachements(Exchange exchange) {
>>return
>> exchange.getIn(AttachmentMessage.class).hasAttachments();
>>}
>>
>> }
>>
>> And then call it from the Java DSL as:
>>
>> > method="hasAttachements"/>
>>
>> If there are better solution, I like to hear it.
>>
>> Raymond
>>
>>
>> On Tue, Nov 14, 2023 at 8:12 PM ski n  wrote:
>>
>> >
>> > I need to check if a message has an attachment.
>> >
>> > In Camel2 I used the following expression:
>> >
>> > ${exchange.getIn().hasAttachments}
>> >
>> > As attachment was modularized in Camel 3, the hasAttachments method
>> isn't
>> > directly available on the exchange anymore (it now extends Message).
>> >
>> > Based on the documentation:
>> >
>> > https://camel.apache.org/components/3.20.x/others/attachments.html
>> >
>> > I tried:
>> >
>> >
>> ${exchange.getIn(AttachmentMessage.class).hasAttachments}
>> >
>> > Using Java code directly this works, but from the XML DSL this gives:
>> >
>> > org.apache.camel.component.bean.ParameterBindingException: Error during
>> > parameter binding on method: public abstract java.lang.Object
>> > org.apache.camel.Exchange.getIn(java.lang.Class) at parameter #0 with
>> type:
>> > class java.lang.Class with value type: class java.lang.String and value:
>> > AttachmentMessage.class
>> >
>> > The parameter is seen as a String object, instead of AttachmentMessage
>> > object. How to properly pass the type parameter in the XML DSL with a
>> > simple expression? If there is an alternative way to check attachments
>> this
>> > also fine, but I'm trying to avoid using processors or bean invocation
>> > though.
>> >
>> > Raymond
>> >
>> >
>>
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


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

Re: Is URI redirection possible?

[Steve973]

Thanks, Claus.  That is good to know.

On Sun, Nov 19, 2023 at 6:54 AM Claus Ibsen  wrote:

> Hi
>
> We have migration guides so it's fine to add in the docs that end users
> need to migrate.
> Also since its isolated to a single component then most users is not
> affected in any way.
>
>
>
>
>
> On Sun, Nov 19, 2023 at 12:50 PM Steve973  wrote:
>
> > Hello.  In a component, if I want to change the format of a URI, and
> still
> > want to retain compatibility with the previous URI format, is there a way
> > (within the module) to redirect to the new URI after translation?  I want
> > to split some functionality off to another endpoint.  So, rather than
> > deprecate the old code, it would be cleaner if I could redirect, if
> > possible.
> >
> > Thank you!
> > Steve
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: How to check if an message on an exchange has attachments?

[Claus Ibsen]

Hi

You can look in the source of camel-attachments and see how they are
stored and then do it by checking for exchange property
key CamelAttachmentObjects exists and is not empty

On Tue, Nov 14, 2023 at 9:21 PM ski n  wrote:

> As a workaround, I implemented it as follows:
>
> public class MyBean {
>
>public boolean hasAttachements(Exchange exchange) {
>return exchange.getIn(AttachmentMessage.class).hasAttachments();
>}
>
> }
>
> And then call it from the Java DSL as:
>
>  method="hasAttachements"/>
>
> If there are better solution, I like to hear it.
>
> Raymond
>
>
> On Tue, Nov 14, 2023 at 8:12 PM ski n  wrote:
>
> >
> > I need to check if a message has an attachment.
> >
> > In Camel2 I used the following expression:
> >
> > ${exchange.getIn().hasAttachments}
> >
> > As attachment was modularized in Camel 3, the hasAttachments method isn't
> > directly available on the exchange anymore (it now extends Message).
> >
> > Based on the documentation:
> >
> > https://camel.apache.org/components/3.20.x/others/attachments.html
> >
> > I tried:
> >
> >
> ${exchange.getIn(AttachmentMessage.class).hasAttachments}
> >
> > Using Java code directly this works, but from the XML DSL this gives:
> >
> > org.apache.camel.component.bean.ParameterBindingException: Error during
> > parameter binding on method: public abstract java.lang.Object
> > org.apache.camel.Exchange.getIn(java.lang.Class) at parameter #0 with
> type:
> > class java.lang.Class with value type: class java.lang.String and value:
> > AttachmentMessage.class
> >
> > The parameter is seen as a String object, instead of AttachmentMessage
> > object. How to properly pass the type parameter in the XML DSL with a
> > simple expression? If there is an alternative way to check attachments
> this
> > also fine, but I'm trying to avoid using processors or bean invocation
> > though.
> >
> > Raymond
> >
> >
>


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

Re: Is URI redirection possible?

[Claus Ibsen]

Hi

We have migration guides so it's fine to add in the docs that end users
need to migrate.
Also since its isolated to a single component then most users is not
affected in any way.





On Sun, Nov 19, 2023 at 12:50 PM Steve973  wrote:

> Hello.  In a component, if I want to change the format of a URI, and still
> want to retain compatibility with the previous URI format, is there a way
> (within the module) to redirect to the new URI after translation?  I want
> to split some functionality off to another endpoint.  So, rather than
> deprecate the old code, it would be cleaner if I could redirect, if
> possible.
>
> Thank you!
> Steve
>


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

Is URI redirection possible?

[Steve973]

Hello.  In a component, if I want to change the format of a URI, and still
want to retain compatibility with the previous URI format, is there a way
(within the module) to redirect to the new URI after translation?  I want
to split some functionality off to another endpoint.  So, rather than
deprecate the old code, it would be cleaner if I could redirect, if
possible.

Thank you!
Steve