Re: Camel Jbang 4.4.1 not available?

[Tadayoshi Sato]

Ah Claus already did it. Thanks Claus :-)

On Fri, Mar 22, 2024 at 2:29 PM Tadayoshi Sato 
wrote:

> Hi,
>
> The Camel JBang command looks at this file in the default branch.
>
> https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-main/dist/CamelJBang.java#L22-L24
>
> As you see, it still points to 4.4.0. Someone will soon update it to 4.4.1
> and you should be able to use it.
>
> By the way, the latest JBang version allows us to pass additional system
> properties at `jbang app install`, so you can as well now do this to
> install a specific version of Camel JBang command:
>
>   $ jbang app install -Dcamel.jbang.version=4.4.1 camel@apache/camel
>
> Hope it helps,
>
> On Fri, Mar 22, 2024 at 2:10 PM Mikael Koskinen 
> wrote:
>
>> Hi,
>>
>> I'm trying to install Camel Jbang 4.4.1 but the 4.4.0 always gets
>> installed. --Force and --fresh parameters don't help.
>>
>> jbang app install --force --fresh camel@apache/camel
>>
>> I checked the CamelJBang.java and it still seems to refer to 4.4.0, is
>> this
>> something that needs to be changed on the source code side?
>>
>> I'm not actually that familiar with how the versioning with the Camel
>> Jbang
>> works. I assumed that the release of Camel 4.4.1 means that the Camel
>> Jbang
>> is also updated to the same version. But now I noticed that there's no
>> 4.4.1 release for the docker image either, so I assume they have a
>> different release cadence.
>>
>> Specifying the exact version when running a command works, for example:
>>
>> jbang --fresh "-Dcamel.jbang.version=4.4.1" camel@apache/camel --version
>>
>> Best regards,
>> Mikael
>>
>
>
> --
> Tadayoshi Sato
>


-- 
Tadayoshi Sato

Re: Camel Jbang 4.4.1 not available?

[Tadayoshi Sato]

Hi,

The Camel JBang command looks at this file in the default branch.
https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-main/dist/CamelJBang.java#L22-L24

As you see, it still points to 4.4.0. Someone will soon update it to 4.4.1
and you should be able to use it.

By the way, the latest JBang version allows us to pass additional system
properties at `jbang app install`, so you can as well now do this to
install a specific version of Camel JBang command:

  $ jbang app install -Dcamel.jbang.version=4.4.1 camel@apache/camel

Hope it helps,

On Fri, Mar 22, 2024 at 2:10 PM Mikael Koskinen  wrote:

> Hi,
>
> I'm trying to install Camel Jbang 4.4.1 but the 4.4.0 always gets
> installed. --Force and --fresh parameters don't help.
>
> jbang app install --force --fresh camel@apache/camel
>
> I checked the CamelJBang.java and it still seems to refer to 4.4.0, is this
> something that needs to be changed on the source code side?
>
> I'm not actually that familiar with how the versioning with the Camel Jbang
> works. I assumed that the release of Camel 4.4.1 means that the Camel Jbang
> is also updated to the same version. But now I noticed that there's no
> 4.4.1 release for the docker image either, so I assume they have a
> different release cadence.
>
> Specifying the exact version when running a command works, for example:
>
> jbang --fresh "-Dcamel.jbang.version=4.4.1" camel@apache/camel --version
>
> Best regards,
> Mikael
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel Kamelets 3.20.0

[Tadayoshi Sato]

+1 (non-binding)

Thanks!

On Wed, Dec 21, 2022 at 10:26 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a vote for releasing camel-kamelets 3.20.0
>
> The release contains fixes and it's updated to Camel 3.20.0.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/3.20.0
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1510
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v3.20.0
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 3.20.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel K 1.10.3 and Camel K Runtime 1.15.2

[Tadayoshi Sato]

+1
Thanks Andrea!

On Fri, Nov 11, 2022 at 6:31 PM Andrea Cosentino  wrote:

> Hello,
>
> This is a combined vote to release Apache Camel K 1.10.3 and Camel K
> Runtime
> 1.15.2.
>
> We are upgrading to Camel 3.18.3 and Camel-Kamelets 0.9.3, this means
> Camel-Quarkus will be updated to 2.13.1.
>
> Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.15.2/
> Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1495
> Runtime Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-project-1.15.2
>
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.10.3/
> Camel K Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.10.3
>
> Staging container image repository:
> https://hub.docker.com/r/camelk/camel-k/tags
>
> It's possible to install all staging artifacts with a single command:
>
> kamel install --operator-image=camelk/camel-k:1.10.3 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1495
>  --olm=false
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.10.3 and
> Apache Camel K Runtime
> 1.15.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel Kamelets 0.9.3

[Tadayoshi Sato]

+1

Thanks!

On Fri, Nov 4, 2022 at 6:33 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a vote for releasing only camel-kamelets 0.9.3.
>
> The release contains fixes and it's updated to Camel 3.18.3.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.9.3/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1494
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.9.3
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 0.9.3
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: [VOTE] Release Apache Camel Kamelets 0.9.2

[Tadayoshi Sato]

+1

Thanks Andrea!

On Wed, Oct 26, 2022 at 5:24 PM Andrea Cosentino  wrote:

> Hello all:
>
> This is a vote for releasing only camel-kamelets 0.9.2.
>
> The release contains fixes.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/0.9.2/
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1488
> Kamelets Tag:
>
> https://gitbox.apache.org/repos/asf?p=camel-kamelets.git;a=shortlog;h=refs/tags/v0.9.2
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 0.9.2
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 48 hours.
>
> NOTE: The vote for 48 hours is because there are no breaking changes but
> the release is not really urgent.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Tadayoshi Sato

Re: Staging of Camel-K Integrations - Best Practices ?

[Tadayoshi Sato]

Hi Christoph,

On Thu, Aug 18, 2022 at 4:20 PM Christoph Weiss 
wrote:

> Hi Sato,
>
> Thanks for the info!
>
> So from a base it looks like what we want to achieve.
> However our requirement is a little bit different as we need to stage to
> another cluster.


I don't think the current impl covers the use case across clusters.
Please file a feature request so that we can discuss further if/how we can
achieve that.
https://github.com/apache/camel-k/issues


> Thus following questions:
> - Would it in theory work just to stage the Integration and IntegrationKit
> CR ?
> (assumption: image registry is shared, all traits and kamelets are
> available on the target cluster)
> Or would be the correct way - as written  in the linked github issue - to
> just stage the Integration CR and use the container.image trait to ensure
> that the tested image is reused?


Yes, a new Integration is created with pointing to the same image already
built in the registry in the target namespace, and then an IntegrationKit
is replicated by the operator without actually triggering a build. Note
that other resources such as configmap, secret, pvc, etc. are not
automatically copied, so you'd need to provide those required resources in
the target namespace if any before promoting an integration to it.

And also yes, you should be able to achieve the same thing with Camel K
1.9.x by manually staging the Integration with Container trait pointing to
the already built image in the registry. If the registry is external, you
should be able to share the image across clusters.


>
>
> Regards, Christoph
>
> -Original Message-
> From: Tadayoshi Sato 
> Sent: Thursday, 18 August 2022 06:49
> To: users@camel.apache.org
> Subject: [EXTERNAL] Re: Staging of Camel-K Integrations - Best Practices ?
>
> Hi,
>
> In the upcoming Camel K 1.10.0 release we will add a new command `kamel
> promote `, which should be essentially what you are looking
> for.
> It does promote the integration and image build tested in a dev namespace
> to a prod namespace.
> https://github.com/apache/camel-k/pull/3325
>
> The documentation is still to be done.
>
> On Wed, Aug 17, 2022 at 12:21 AM Christoph Weiss <
> christoph.we...@de.ibm.com>
> wrote:
>
> > Hello,
> >
> > I am looking for “best practices” to stage a Camel-K Integration
> > across multiple environment (e.g., Test, PreProd, Prod).
> >
> > My primary goal is to have only one “image build” (and not one per
> stage).
> > My current understanding is that  I would need to stage the
> > Integration and IntegrationKit C (config per stage via configmaps /
> secrets).
> > Is this correct? And most important: would this work? (not sure how
> > the operator behaves).
> >
> > Any other “best practices” that should be followed?
> >
> > Any hints are welcome. Cheers Christoph
> >
>
>
> --
> Tadayoshi Sato
>


-- 
Tadayoshi Sato

Re: Staging of Camel-K Integrations - Best Practices ?

[Tadayoshi Sato]

Hi,

In the upcoming Camel K 1.10.0 release we will add a new command `kamel
promote `, which should be essentially what you are looking
for.
It does promote the integration and image build tested in a dev namespace
to a prod namespace.
https://github.com/apache/camel-k/pull/3325

The documentation is still to be done.

On Wed, Aug 17, 2022 at 12:21 AM Christoph Weiss 
wrote:

> Hello,
>
> I am looking for “best practices” to stage a Camel-K Integration across
> multiple environment (e.g., Test, PreProd, Prod).
>
> My primary goal is to have only one “image build” (and not one per stage).
> My current understanding is that  I would need to stage the Integration
> and IntegrationKit C (config per stage via configmaps / secrets).
> Is this correct? And most important: would this work? (not sure how the
> operator behaves).
>
> Any other “best practices” that should be followed?
>
> Any hints are welcome. Cheers Christoph
>


-- 
Tadayoshi Sato

Re: Download of latest relase JAR of hawt.io

[Tadayoshi Sato]

Hi,

While it might be a bit hard to find, there is a link to the latest jar
here in README:
https://github.com/hawtio/hawtio#running-an-executable-jar

On Tue, Jun 7, 2022 at 11:55 PM Chirag  wrote:

> Bert,
>
> Hawt.io documentation could also use some help for sure.
> It does have its own group for discussion if you want to share feedback
> there.
> https://groups.google.com/g/hawtio
>
>  ચિરાગ/चिराग/Chirag
> --
> Sent from My Gmail Account
>
> On Tue, Jun 7, 2022 at 4:26 AM Bert Speckels 
> wrote:
> >
> > Hello there
> >
> > I know  this is not really a Camel question but it is related to
> > Camel since hawt.io is a widely used tool for Apache Camel, isn't it?!
> >
> > I have always had difficulties finding the latest hawt.io JAR file for
> download.
> > All that I can see on the hawt.io homepage is the source code. Do I
> > miss something or is the release of a JAR file still pending?
> > Even the available JAR file for 2.14.5 is hard to find.
> >
> > WIth kind regards
> > Bert Speckels
>


-- 
Tadayoshi Sato

Re: kamel install --global vs kamel get -n

[Tadayoshi Sato]

Hi,

It's just a false alarm. You can ignore it for the global operator.
I think kamel cli should be changed to also look for an operator globally,
not only within its namespace.

On Thu, Mar 17, 2022 at 5:05 AM Roberto Camelk 
wrote:

> I recently installed the camel-k 1.8.2. During the process I passed
> the arg --global to enable camel-k-operator to manage all namespaces.
>
> Now, when I query the integrations running in a specific namespace via
> "kamel get -n my-namespace" I got this output:
>
> > No IntegrationPlatform resource in my-space namespace
> > NAME PHASE KIT
> > metrics Running default/kit-c8p3npidnv2c738t0erg
>
> The CLI is working as expected, listing my running integrations, but
> this message "No IntegrationPlatform resource in my-space namespace".
>
> Do I need to worry about it? How can I fix it? What means it?
>


-- 
Tadayoshi Sato

Re: Apache Camel and hawt.io debugging: Body/Header not visible at breakpoint

[Tadayoshi Sato]

Hi Bert,

It's likely that the problem is in Hawtio. Hawtio is not yet updated with
the latest Camel versions.
Feel free to file your issue at
https://github.com/hawtio/hawtio-integration/issues

Thanks,
Tadayoshi

On Mon, Mar 14, 2022 at 3:20 AM Bert Speckels 
wrote:

> Hi
>
> I am quite new with Apache Camel and assigned to this mailing list
> just a few minutes ago.
> So please be kind to me :-D
>
> ---
>
> Until now I was very successful with using Camel. It is exactly what
> we need for our project.
> But I wouldn't write here if I didn't have a problem ...
>
> I'm currently working with Apache Camel and hawt.io for monitoring and
> debugging my Camel routes.
> This works wonderfully, even if some important information is somewhat
> hidden in the documentation. For example, it took me a bit to turn on
> debugging.
>
> However, if I set a breakpoint in debugging mode then the message
> processing stops at that point in the route.
> My problem is that I can't see any "body" or "headers" of the Camel
> Exchange at that point.
>
> I've tried all sorts of settings:
> - tracing / backlog tracing enabled on CamelContext
> - tracing / backlog tracing enabled on route
> - Adjusted settings on MBean "BacklogDebugger" and "BacklogTracer".
>
> On the other side tracing works: If I activate tracing in the "Trace"
> tab, I can see the flow of my messages through all nodes of the route.
> Only in "Debugging" tab there is no body nor header when  the route
> stopped at the breakpoint.
>
> Here is some information:
>
> - I don't use any special framework: Plain old Java with a Main method
> in which I start Camel-Main.
> - Apache Camel: 3.14.1
> - Jolokai Agent: 1.7.1
> - hawt.io: 2.14.5
> - Exchange body type: DOMSource
>
> Maybe anyone has an idea what I can try to get the exchange content
> while debugging via jmx/hawt.io
>
> This is my route:
>
> getCamelContext().setBacklogTracing(true);
>
> --
> from(rabbitMqFactory.queueConnect("tso11", "tso11-to-nms", "username"))
>   .routeGroup("Workflow")
>   .routeId("Workflow-to-NMS|Map-TSO11-to-NMS42")
>   .routeDescription("Mapping of TSO11 Message to NMS42")
>   .convertBodyTo(DOMSource.class)
>   .log("Message for '$simple{header:tenant}' received")
>   .process(tso11ToNmsMappingProcessor)
>   .to("xslt:xslt/tso11-to-nms42.xslt")
>   .to("direct:send");
> --
>
> ANd these are current properties:
>
> ------
> camel.main.name=TSO11
> camel.main.jmxEnabled=true
> camel.main.debugging=true
> camel.main.backlogTracing=true
> camel.main.lightweight=false
> camel.main.tracing=false
> camel.main.useBreadcrumb=true
> --
>
> Thanks for reading
> With kind regards
>


-- 
Tadayoshi Sato

Re: Use of lombok in camel codebase?

[Tadayoshi Sato]

Yes, Lombok should be best for using with a Camel application, but not
necessary so for the framework/library code of Camel itself.
Code simplicity is great but sometimes being explicit wins over magical
simplicity.
As an object-oriented programmer, if we need getters/setters in the code I
think it's already somewhat losing. Ideally we should be able to live
without getters/setters, but if it's unavoidable then in my opinionated
view it's less important whether it's implicit or not.

On Wed, Nov 3, 2021 at 7:36 AM Vyacheslav Boyko  wrote:

> Lombok have advantages and disadvantages both.
> With bringing reducing of annoying boilerplate it brings its "magic" of
> underlying code generation which could be understood only by having some
> level of practice using Lobmok. For example, deserialization troubles
> when a constructor have more than one parameter with the same type (it
> needs to be annotated with @Creator or @ConstructorProperties). I guess,
> the maintainers of Camel don't want to be involved into such issues.
>
> On 11/3/21 00:35, Steve973 wrote:
> > You see no advantage in getting boilerplate code for free, and keeping
> your
> > beans, etc, free from accessors/mutators, no arg constructors, all arg
> > constructors, getting a builder for free, and lots of other stuff?  I can
> > see avoiding it in a project for particular reasons, but most of the
> > "favorite" frameworks reduce a lot of boilerplate code, and Camel is
> > included in that.  I'm not arguing, but I really am curious why you see
> no
> > advantage.  That is, of course, if it's appropriate to have this
> > conversation here, on this list.
> >
> > On Tue, Nov 2, 2021 at 5:31 PM Andrea Cosentino 
> wrote:
> >
> >> There is no problem with license. Personally i never find any advantage
> in
> >> using Lombok.
> >>
> >> Il mar 2 nov 2021, 21:23 Steve973  ha scritto:
> >>
> >>> Hello.  I normally use lombok to take care of boiler plate code in
> >> projects
> >>> that I work on.  I have noticed that lombok is not used in the camel
> code
> >>> base.  Is there something about it (licensing or something else) that
> >> makes
> >>> it unsuitable for camel?  I am working on something in camel-core, and
> it
> >>> would be great to be able to use it to keep things cleaner.  But I
> would
> >>> think that if it was acceptable in an apache project, people would
> >> already
> >>> be using it.  Does anyone have the details on this?
> >>>
> >>> Thanks,
> >>> Steve
> >>>
>


-- 
Tadayoshi Sato

Re: [discuss] find a better name for KameletBinding

[Tadayoshi Sato]

"Binding" sounds good to me, too.

On Fri, Aug 20, 2021 at 7:07 PM Claus Ibsen  wrote:

> Hi
>
> Yeah one of the hardest problem is naming, and after that renaming as
> a lot of old stuff "expects" the old name.
>
> I am also leading to Binding, as we have other concepts in Camel K
> that are neutral named (no Camel or product in the name) like
> Integration, IntegrationKit.
> And they are all in the same namespace, so there are no clash on
> kubernetes.
>
> +1 for Binding
>
>
>
> On Fri, Aug 20, 2021 at 10:59 AM John Poth  wrote:
> >
> > +1 for Binding
> >
> > Dropping the Kamelet part makes it clearer that you can bind more
> > than just Kamelets.
> >
> > Keeping it as "Binding" gives Kubernetes users a pretty good idea of what
> > it's going to do without reading the documentation.
> >
> > On Mon, Aug 16, 2021 at 2:04 PM Antonin Stefanutti
> >  wrote:
> >
> > > Hi Luca, all,
> > >
> > > +1 for Binding.
> > >
> > > Users in the Kubernetes ecosystem may already be familiar with the
> term,
> > > as it seems it's the choice made by projects like Knative and Service
> > > Binding,
> > > to convey the general concept of "integrating" in their respective
> domain.
> > >
> > > I find projecting that concept into the integration domain to be a good
> > > fit, which
> > > Would materialises in Kubernetes as bindings.camel.apache.org<
> > > http://bindings.camel.apache.org> resources.
> > >
> > > On 16 Aug 2021, at 10:27, Luca Burgazzoli   > > lburgazz...@gmail.com>> wrote:
> > >
> > > Hello,
> > >
> > > When the KameletBinding concept was introduced in camel-k, if was
> meant to
> > > bind two Kamelets and nothing more, but over time we have added more
> > > capabilities, like:
> > >
> > > - support for processing steps to transform exchanges/messages
> > > - support to address/source from different systems so the source/sink
> does
> > > not need be a kamelet anymore
> > >
> > > So I think the term KameletBinding is not more appropriate and to
> reduce
> > > confusion, we should try to find a better name.
> > >
> > > On top of my mind, I'd see the following names as a possible
> replacement:
> > > - Binding so leave Kamelet out of the game as Kamelets are one of the
> > > option but not the exclusive on
> > > - Connector as in essence, a KameletBinding describe how to connect A
> to B
> > >
> > > Any opinion ?
> > >
> > > ---
> > > Luca Burgazzoli
> > >
> > >
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Tadayoshi Sato

Re: SFTP component possible bug with URL parameter including char sequence “)&”

[Tadayoshi Sato]

h
> >> Refresh(AbstractApplicationContext.java:943)
> >> ~[spring-context-5.3.2.jar:5.3.2]
> >> at
> >> org.springframework.context.support.AbstractApplicationContext.refres
> >> h(AbstractApplicationContext.java:591)
> >> ~[spring-context-5.3.2.jar:5.3.2]
> >> at
> >> org.springframework.boot.web.servlet.context.ServletWebServerApplicat
> >> ionContext.refresh(ServletWebServerApplicationContext.java:144)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> org.springframework.boot.SpringApplication.refresh(SpringApplication.
> >> java:767)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> org.springframework.boot.SpringApplication.refresh(SpringApplication.
> >> java:759)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> org.springframework.boot.SpringApplication.refreshContext(SpringAppli
> >> cation.java:426)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> org.springframework.boot.SpringApplication.run(SpringApplication.java
> >> :326)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> org.springframework.boot.SpringApplication.run(SpringApplication.java
> >> :1309)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> org.springframework.boot.SpringApplication.run(SpringApplication.java
> >> :1298)
> >> ~[spring-boot-2.4.1.jar:2.4.1]
> >> at
> >> com.spar_ics.eai.apps.routes.idm_scim_service.IdmScimServiceApplicati
> >> on.main(IdmScimServiceApplication.java:13)
> >> ~[classes/:na]
> >> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to
> >> resolve endpoint:
> >> sftp://testserver/../testdir/?fail%29==xx
> >> due to: Failed to resolve endpoint:
> >> sftp://testserver/../testdir/?fail%29==xx due to: There
> >> are 1 parameters that couldn't be set on the endpoint. Check the uri
> >> if the parameters are spelt correctly and that they are properties of
> >> the endpoint. Unknown parameters=[{fail)=}]
> >> at
> >> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(Abstr
> >> actCamelContext.java:962) ~[camel-base-engine-3.10.0.jar:3.10.0]
> >> at
> >> org.apache.camel.impl.engine.AbstractCamelContext.getEndpoint(Abstrac
> >> tCamelContext.java:844) ~[camel-base-engine-3.10.0.jar:3.10.0]
> >> at
> >> org.apache.camel.support.CamelContextHelper.getMandatoryEndpoint(Came
> >> lContextHelper.java:58)
> >> ~[camel-support-3.10.0.jar:3.10.0]
> >>     at
> >> org.apache.camel.reifier.AbstractReifier.resolveEndpoint(AbstractReif
> >> ier.java:177) ~[camel-core-reifier-3.10.0.jar:3.10.0]
> >> at
> >> org.apache.camel.reifier.RouteReifier.doCreateRoute(RouteReifier.java
> >> :94) ~[camel-core-reifier-3.10.0.jar:3.10.0]
> >> at
> >> org.apache.camel.reifier.RouteReifier.createRoute(RouteReifier.java:7
> >> 4) ~[camel-core-reifier-3.10.0.jar:3.10.0]
> >> ... 26 common frames omitted Caused by:
> >> org.apache.camel.ResolveEndpointFailedException: Failed to resolve
> >> endpoint: sftp://testserver/../testdir/?fail%29==xx
> >> due to: There are 1 parameters that couldn't be set on the endpoint.
> >> Check the uri if the parameters are spelt correctly and that they are
> >> properties of the endpoint. Unknown parameters=[{fail)=}]
> >> at
> >> org.apache.camel.support.DefaultComponent.validateParameters(DefaultC
> >> omponent.java:299)
> >> ~[camel-support-3.10.0.jar:3.10.0]
> >> at
> >> org.apache.camel.support.DefaultComponent.createEndpoint(DefaultCompo
> >> nent.java:192)
> >> ~[camel-support-3.10.0.jar:3.10.0]
> >> at
> >> org.apache.camel.impl.engine.AbstractCamelContext.doGetEndpoint(Abstr
> >> actCamelContext.java:928) ~[camel-base-engine-3.10.0.jar:3.10.0]
> >> ... 31 common frames omitted
> >>
> >>
> >>
> >> Thx and regards,
> >> Flo
> >> Sollten Sie diese E-Mail unbeabsichtigt bzw. irrtümlich erhalten
> >> haben, so weisen wir Sie darauf hin, dass gemäß § 93 Abs 4 TKG der
> >> Inhalt sowie die Tatsache des Empfangs dieser E-Mail weder
> >> aufgezeichnet noch verwertet oder Unbefugten mitgeteilt werden
> >> dürfen. Wir ersuchen Sie, die Nachricht von Ihrem System zu löschen
> >> und sich mit uns in Verbindung zu setzen. If you have received this
> >> email accidentally or in error, we point out that, in accordance with
> >> § 93 para. 4 TKG (Telecommunications Act), the contents of this email
> >> and the fact of its receipt must not be recorded, exploited or
> >> communicated to unauthorized persons. We ask you to delete the message
> from your system and to contact us.
> >>
> >
>


-- 
Tadayoshi Sato

Re: Future of Camel

[Tadayoshi Sato]

On Sun, Jan 17, 2021 at 6:28 PM ski n  wrote:

> Hi all,
>
> In 2020 there was a clear roadmap towards 3.7.0. This roadmap focussed on
> modularization and performance, especially useful in microservices and
> cloud functions.
>
> Now I wonder what the roadmap of 2021 will be and what the future of Camel
> brings.
>
> I made 12 questions on the Camel ecosystem to think about this topic:
>
>
> 1) Management DSL
>
> Camel has always had the Java DSL. One of the last additions of this DSL is
> the EndpointDSL. Not everything can be done with the DSL yet. Will there
> also a Management DSL where you can configure and manage context and route?
>
> 2) Ease of use
>
> One of the strongest points of Camel is it ease of use. Are there ideas to
> make it even more high level, towards citizens integrators?
>
> 3) Performance
>
> 3.x focussed on the memory footprint and performance of core Camel. Will
> this focus shift towards components. For example
> the 10 most used componets (file, ftp, sjms, kafka for example). Maybe
> based on Maven statistics.
>
> 4) GraalVM
>
> Will GraalVM native images with ahead of time compilation will be
> supported.
>
> 5) Java 17
>
> In september 2021 the new LTS for Java comes out. Will the team especially
> target this release or will it first support Java 15?
>
> 6) DSL Export
>
> With DumpToXML it's possible to export a route in XML format. Will there
> also a DumpToDSL?
>
> 7) jOOr I
>
> Will Csimple eventually replace simple?
>
> 8) jOOr II
>
> The jOOR language allows using Java code in a Camel expression. From an end
> user perspective, why don't just use .java() like .groovy()?
>
> 9) jOOr III
>
> Is it/will it be also possible to run a complete Camel route written as
> Java DSL through jOOr? (loading from a file with contains the Java DSL for
> example)
>
> 10) ServiceMix is end-of-life. Will it get a replacement project (Syndesis
> for example)? Will Syndesis be part of the Camel ecosystem like CamelK or
> KafkaConnector?
>
> 11) CamelK and Syndesis?
>
> Will it be possible to run CamelK code within Syndesis? Seems like a great
> combination?
>
> 12) CamelK
>
> Will it be possible to call CamelK programmatically from Java (instead of
> use client written in Go)?
>

Yes, what kamel really does is creating a quarkus java app that uses
camel-k-runtime to load the camel-k script on k8s.
See for instance this itest to get an idea of how you can load camel-k
script from a java app with camel-k-runtime:
https://github.com/apache/camel-k-runtime/tree/master/itests/camel-k-itests-loader-js


>
> Final note:
>
> Well these are just question on a sunday morning :)These 12 questions are
> not meant as user questions that need to be answered, but more as
> discussion points for the user community for the future of Camel. Hope to
> read the thoughts from devs and other users on making Camel even faster and
> easier to work with. BTW thanks very much for all the achievements and hard
> word on Camel in the strange year 2020.
>
> Kind regards,
>
> Raymond
>


-- 
Tadayoshi Sato

Re: Help - User mailing list

[Tadayoshi Sato]

Here you can find the info you’re looking for:
https://camel.apache.org/manual/latest/mailing-lists.html

2020年12月26日(土) 15:39 Arundhati Bhende :

> Hi,
>
> A couple of questions about the userlist.
> >   Is it possible to access / post to the list from the web browser?
> >   How do I search the userlist before asking a question?
>
> Thank you
>
>
> --
Tadayoshi Sato

Re: Are you using binary distribution?

[Tadayoshi Sato]

Hi folks,

I don't use binary distributions, either. It makes sense for runtime
projects such as Apache Karaf, Kafka, Artemis, etc. to provide binary
distributions, but it doesn't for library frameworks like Camel Core, Camel
Quarkus, and CKC.

For Camel-K, however, it has a CLI `kamel` so IMO it still makes sense to
keep binary distributions for it.

Thanks,
Tadayoshi

On Mon, Dec 14, 2020 at 10:58 PM Ajmera, Hemang C 
wrote:

> I am relying on maven for binaries and git for sourcecode. IMHO binary
> distribution may not be needed.
> Github has release feature, where we can have binaries can be downloaded
> from there. Many users might be used to that way of downloading binary, so
> if needed, that can be alternate place for download if anyone needs it.
> However CI/CD pipeline might need updates for github release to work.
>
>
> Thanks and Regards,
> Hemang Ajmera
>
>
> -Original Message-
> From: Zoran Regvart 
> Sent: 14 December 2020 19:08
> To: Dev ; users@camel.apache.org
> Subject: Are you using binary distribution?
>
>
> EXTERNAL SENDER:   Do not click any links or open any attachments unless
> you trust the sender and know the content is safe.
> EXPÉDITEUR EXTERNE:Ne cliquez sur aucun lien et n’ouvrez aucune pièce
> jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous
> ayez l'assurance que le contenu provient d'une source sûre.
>
> Hi Cameleers,
> we're discussing binary distribution on two issues[1][2]. The binary
> distribution is the tar.gz/ZIP file linked from the Camel website. By ASF
> policy we only ship source code, and the binary distribution is optional.
>
> Back in the dark days, before using build tools that knew about dependency
> management (Maven, Gradle...) folk used to use the binary distribution.
>
> I've found some statistics on downloads/per day, for us[3]/eu[4] and
> created these charts:
>
>
> https://urldefense.com/v3/__https://s.apache.org/camel-dl-us__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiSwKzT18$
>
> https://urldefense.com/v3/__https://s.apache.org/camel-dl-eu__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDic4MBCm6$
>
> The data is over 2 and 1/4 years, we've had 19.7+-8.8 via US, and
> 20.24+-8.43 in via EU per day. So not that much IMHO.
>
> I'm wondering if anyone is still relying on these, and if so what would a
> binary distribution look like for sub projects? Should we do the same as we
> do for the Camel core?
>
> Please reply on this thread or chime in on those issues for sub-project
> specific concerns.
>
> Thanks :)
>
> zoran
>
> [1]
> https://urldefense.com/v3/__https://github.com/apache/camel-quarkus/issues/2045__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiZ80_jXD$
> [2]
> https://urldefense.com/v3/__https://github.com/apache/camel-kafka-connector/issues/754__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiVlO1Pqs$
> [3]
> https://urldefense.com/v3/__https://www-us.apache.org/dyn/stats/camel.log__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDiStt2eyy$
> [4]
> https://urldefense.com/v3/__https://www-eu.apache.org/dyn/stats/camel.log__;!!AaIhyw!8ibMqXkFVhQZbXiUiDEZIMhodvHt6ZT0-9hO37pz6vxmkpWyl1rF-cNDicRsFgPE$
> --
> Zoran Regvart
>


-- 
Tadayoshi Sato

Re: [ANNOUNCEMENT] Apache Camel 3.0.0 Released

[Tadayoshi Sato]

Congratulations!  It's an epic release indeed!

Thanks everyone for making it happen!

Best regards,
Tadayoshi

On Thu, Nov 28, 2019 at 11:13 PM Gregor Zurowski 
wrote:

> It's finally here - after four release candidates and three milestone
> releases, the Camel community announces the immediate availability of
> Camel 3.0.0, a new major release with over 1000 new features,
> improvements and fixes.
>
> Please read our migration guide [1] that describes how to upgrade
> Camel 2.x applications to Camel 3.0.
>
> The artifacts are published and ready for you to download [2] either
> from the Apache mirrors or from the Central Maven repository. For more
> details please take a look at the release notes [3, 4].
>
> Many thanks to all who made this release possible.
>
> On behalf of the Camel PMC,
> Gregor Zurowski
>
> [1] https://camel.apache.org/manual/latest/camel-3-migration-guide.html
> [1] http://camel.apache.org/download.html
> [2] https://camel.apache.org/blog/release-3-0-0.html
> [3]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315691=12311211
>


-- 
Tadayoshi Sato

Re: camel restart

[Tadayoshi Sato]

Yes.

On Tue, Nov 26, 2019 at 12:39 PM Bing Lu  wrote:

>  So i can do sth like the following,assuming the JmsException stops the
> route? thanks
>
> onException("JmsException.class").to("controlbus:route?routeId=id1=start");
>
> On Monday, November 25, 2019, 10:08:56 PM EST, Tadayoshi Sato <
> sato.tadayo...@gmail.com> wrote:
>
>  You may use Control Bus EIP to start/stop routes from another route.
> https://camel.apache.org/components/latest/controlbus-component.html
> You may also use JMX to manually start/stop routes. With Hawtio
> https://hawt.io this would be easier.
> https://camel.apache.org/manual/latest/jmx.html
>
> On Tue, Nov 26, 2019 at 9:37 AM Bing Lu  wrote:
>
> >  Hi, is there a way to restart the app in case a route was stopped for
> > some reason? thanks
>
>
>
> --
> Tadayoshi Sato
>



-- 
Tadayoshi Sato

Re: camel restart

[Tadayoshi Sato]

You may use Control Bus EIP to start/stop routes from another route.
https://camel.apache.org/components/latest/controlbus-component.html
You may also use JMX to manually start/stop routes. With Hawtio
https://hawt.io this would be easier.
https://camel.apache.org/manual/latest/jmx.html

On Tue, Nov 26, 2019 at 9:37 AM Bing Lu  wrote:

>  Hi, is there a way to restart the app in case a route was stopped for
> some reason? thanks



-- 
Tadayoshi Sato

Re: Documentation for SupervisingRouteController

[Tadayoshi Sato]

Hi,

It's not documentation but there is an example that tells how to use
Supervising Route Controller. You might find it helpful:
https://github.com/apache/camel/tree/camel-3.0.0-RC3/examples/camel-example-spring-boot-supervising-route-controller

On Tue, Nov 19, 2019 at 10:28 PM Claus Ibsen  wrote:

> Hi
>
> If you use camel-main then there is a JIRA about making configuring
> this out of the box better
> https://issues.apache.org/jira/browse/CAMEL-13535
>
> For spring-boot there is already an example you can look at.
>
> But yeah we should get this done for camel main, so keep an eye on
> that JIRA ticket
>
> On Tue, Nov 19, 2019 at 1:53 PM Imran Raza Khan 
> wrote:
> >
> > I have MQTT route like below
> >
> > from("paho:mytopic?brokerUrl=tcp://0.0.0.0:1883=ipc)
> > .routeId("myroute")
> > .to("log:my?showAll=true=true");
> >
> > it starts only if broker is available and after that if it lost
> > connectivity with broker it handle it very well and resume.
> >
> > But my concern is how i can start first time if broker is not available?
> >
> > I searched on google and got to know  "SupervisingRouteController" might
> > help in this regard, But no document is available how i can use it.
> > By some hit and trial i reach this point but what further i can do as no
> > document available
> >
> > final Main main = new Main();
> > main.addRouteBuilder(new MyMqttRoute());
> > SupervisingRouteController controller =
> >
> main.getCamelContexts().get(0).getRouteController().unwrap(SupervisingRouteController.class);
> > main.run();
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Tadayoshi Sato

Re: [ANNOUNCEMENT] Brand new Apache Camel website

[Tadayoshi Sato]

Congratulations, and well done to all who have been involved in the website
renewal!!!

On Tue, Aug 20, 2019 at 10:03 PM Zoran Regvart  wrote:

> Hi Cameleers!
> I'm delighted to announce that the new Apache Camel website is live
> now. This has been a work that many of you contributed to either
> directly by modifying the site content working on the design or
> functionality or indirectly by providing feedback.
>
> Have a look at the new website at:
>
> https://camel.apache.org/
>
> Please feel free to share feedback we're always looking for ways to
> improve, we already have some issues that we're working on[1].
>
> If you find any issues with the website you can either create a an
> JIRA issue and set the component to 'website', or you can use the new
> functionality 'Edit this Page' to suggest improvements yourself!
>
> zoran
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20component%20%3D%20website
> --
> Zoran Regvart
>

Re: Camel Documentation

[Tadayoshi Sato]

The github repository is the definitive source of the latest documentation.
And we are working on compiling them to the new website (still wip though):
https://camel.apache.org/staging/
which is planned to launch along with Camel 3 GA release.

On Wed, Apr 24, 2019 at 11:18 AM Darius Cooper 
wrote:

> Or maybe it is meant to start here:
> https://github.com/apache/camel/tree/master/docs/user-manual/en
>
> On Tue, Apr 23, 2019 at 10:13 PM Darius Cooper 
> wrote:
>
> > What does the Camel think of as the most current and definitive
> > documentation for the project. is it whatever is in github? In other
> words,
> > this README, and everything that it is connected to ?
> > Or will the new documentation be elsewhere.
> >
> > I'm wondering what is the best place to contribute to the documentation.
> >
>

Re: Question about Camel Connector

[Tadayoshi Sato]

Could anyone answer this question?  I was also surprised to find Camel
Connector discontinued in 3.x and would like to get explanation from
someone knowledgeable on the topic.

I can only find this JIRA other than Claus' commits that deprecated
connectors, but the JIRA doesn't refer to any background discussions.
https://issues.apache.org/jira/browse/CAMEL-13052


On Thu, Mar 7, 2019 at 12:02 PM Willem Jiang  wrote:

> Hi，
>
> I think Camel Connector[1] is quit useful if we have some
> configuration need to be done on the component or endpoint level.
> I just found the codes of CamelConnector were removed in the camel
> 3.x.  But there is not much discussion about it. May I know the reason
> why do we deprecate these connectors and remove them in Camel 3.x?
>
> Thanks,
>
> [1]https://issues.apache.org/jira/browse/CAMEL-10721
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>

Re: [DISCUSS] - Apache Camel 3 - A new tagline

[Tadayoshi Sato]

Hi folks,

* Apache Camel 3 - A full-stack integration framework for building
> cloud-native micro integrations


To be honest, I love the *lightweight-ness* of Apache Camel but the word
"full-stack" sounds like a rather heavier, opinionated framework that
enforces developers how an app should be programmed.

I don't have a talent to come up with catchy taglines, so let me just point
to some known ones:
https://github.com/apache/camel/blob/master/docs/user-manual/en/faq/why-the-name-camel.adoc

   -

   You can go a long way with Camel!
   -

   Don’t get the hump get Camel!
   -

   No where to evolve to? Get Camel!
   -

   One hump or two?
   -

   Don’t get lost in a desert of XML config files, get Camel!
   -

   It’s not a mirage, it’s a Camel!



On Wed, Feb 20, 2019 at 12:52 AM Claus Ibsen  wrote:

> Hi
>
> As part of Apache Camel 3, we are working on a new modern website
> (yeah its long overdue, but work are in progress).
>
> As part of that, we should get a new front-page with a new short
> summary what Apache Camel is (eg a tagline).
>
> It would be good to get some ideas rolling what such a tagline could
> be and for users of Camel to come up with suggestions.
>
> As Apache Camel has been around for so long, and that it covers so
> many different use-cases, then its maybe harder to come up with a
> single tag-line that spans all use-cases.
>
> However with the new modern world of containers I came up with:
>
> * Apache Camel 3 - A full-stack integration framework for building
> cloud-native micro integrations
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Camel 2.21.1 and Hawtio

[Tadayoshi Sato]

Hello Christian,

If you are using Camel 2.21.1, Spring Boot must be 1.x. Then you can refer
to this example:
https://github.com/hawtio/hawtio/tree/master/examples/springboot
It also contains a simple Camel route which you can view from the Hawtio
console.

The key part for the sample is you need to set endpoints.jolokia.sensitive
= false in application.properties. This should be applicable to the cases
where you want hawtio-app.jar to connect to a remote Jolokia endpoint.

Hope this helps.

Best regards,
Tadayoshi

On Wed, Oct 24, 2018 at 6:26 PM Ribeaud, Christian (Ext) <
christian.ribe...@novartis.com> wrote:

> Hi Tadayoshi,
>
> Spring Boot. I've tried this strategy, basically following the
> instructions given here:
>
> >
> http://peter-on-java.blogspot.com/2014/05/using-hawito-to-monitor-apache-camel.html
>
> The agent is indeed discovered. But nothing more happens...
> Do I miss something here?
> Regards,
>
> christian
>
> -Original Message-
> From: Tadayoshi Sato 
> Sent: Mittwoch, 24. Oktober 2018 11:16
> To: users@camel.apache.org
> Subject: Re: Camel 2.21.1 and Hawtio
>
> Hell Christian,
>
> What is the runtime your Camel app is running on?  Spring Boot, Karaf, or
> anything else?  Basically you can just find out the Jolokia endpoint and
> connect hawtio-app.jar via Connect tab to that endpoint.
>
> Best regards,
> Tadayoshi
>
> On Wed, Oct 24, 2018 at 6:12 PM Ribeaud, Christian (Ext) <
> christian.ribe...@novartis.com> wrote:
>
> > Hi,
> >
> > I am desperately trying to connect hawtio to my Camel workflow. Or is
> > there a better solution to visualize my Camel workflow?
> > I've read following links:
> >
> > >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__peter-2Don-2Djava.
> > blogspot.com_2014_05_using-2Dhawito-2Dto-2Dmonitor-2Dapache-2Dcamel.ht
> > ml=DwIBaQ=ZbgFmJjg4pdtrnL2HUJUDw=MS-8N6QwQqjzb8iBrPi691rQrebnovN
> > -5Sk5-OHOxKQ=2S2O1NnAvN3ozz_TdyvwMwVXrbtfA0363Y4F9tzvU5Q=1AZBerdnb
> > hulnRgqW8d7otrbJZnTHtvEsxYDVJ2M4YU=
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__hawt.io_docs_plu
> > > gins_=DwIBaQ=ZbgFmJjg4pdtrnL2HUJUDw=MS-8N6QwQqjzb8iBrPi691rQre
> > > bnovN-5Sk5-OHOxKQ=2S2O1NnAvN3ozz_TdyvwMwVXrbtfA0363Y4F9tzvU5Q=Ss
> > > T7TacUXxC-iXfeshNLMf3XVeSYcZH5PptYDZULGe8=
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__vimeo.com_14191
> > > 7680=DwIBaQ=ZbgFmJjg4pdtrnL2HUJUDw=MS-8N6QwQqjzb8iBrPi691rQreb
> > > novN-5Sk5-OHOxKQ=2S2O1NnAvN3ozz_TdyvwMwVXrbtfA0363Y4F9tzvU5Q=HEz
> > > W675rEsxXUK4xH6sWvsBFPXvVtM0wNZq6Mwxvr5E=
> >
> > None of them helped me. All seem quite outdated. My understanding is
> > the
> > following:
> >
> > 1/ My Camel workflow is running and sending some JMX messages 2/ These
> > messages are then caught by hawtio running, for instance, in another
> > JVM with 'java -jar hawtio-app-2.1.0.jar'.
> >
> > If I have to install the Camel plugin for hawtio, how should I proceed?
> > Should I really follow the instructions given here?
> >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hawt
> > > io_hawtio-2Dintegration=DwIBaQ=ZbgFmJjg4pdtrnL2HUJUDw=MS-8N6Qw
> > > Qqjzb8iBrPi691rQrebnovN-5Sk5-OHOxKQ=2S2O1NnAvN3ozz_TdyvwMwVXrbtfA0
> > > 363Y4F9tzvU5Q=HaQQbg_sizsXobbPfWygm-I42RV_BHsqPwm-6uuryYo=
> >
> > Is that so complicate? No release to download and to somehow plug to
> > the hawtio standalone app?
> > Or even better, an all-in-one jar?
> >
> > Many thanks and cheers,
> >
> > christian
> >
> >
> >
>

Re: Camel 2.21.1 and Hawtio

[Tadayoshi Sato]

Hell Christian,

What is the runtime your Camel app is running on?  Spring Boot, Karaf, or
anything else?  Basically you can just find out the Jolokia endpoint and
connect hawtio-app.jar via Connect tab to that endpoint.

Best regards,
Tadayoshi

On Wed, Oct 24, 2018 at 6:12 PM Ribeaud, Christian (Ext) <
christian.ribe...@novartis.com> wrote:

> Hi,
>
> I am desperately trying to connect hawtio to my Camel workflow. Or is
> there a better solution to visualize my Camel workflow?
> I've read following links:
>
> >
> http://peter-on-java.blogspot.com/2014/05/using-hawito-to-monitor-apache-camel.html
> > http://hawt.io/docs/plugins/
> > https://vimeo.com/141917680
>
> None of them helped me. All seem quite outdated. My understanding is the
> following:
>
> 1/ My Camel workflow is running and sending some JMX messages
> 2/ These messages are then caught by hawtio running, for instance, in
> another JVM with 'java -jar hawtio-app-2.1.0.jar'.
>
> If I have to install the Camel plugin for hawtio, how should I proceed?
> Should I really follow the instructions given here?
>
> > https://github.com/hawtio/hawtio-integration
>
> Is that so complicate? No release to download and to somehow plug to the
> hawtio standalone app?
> Or even better, an all-in-one jar?
>
> Many thanks and cheers,
>
> christian
>
>
>

Re: log plugin for hawtio and camel

[Tadayoshi Sato]

Yes, you can see the console log with hawtio-log but at this moment the
plugin is activated out of the box only on Karaf container.

On Mon, Aug 13, 2018 at 2:33 PM Michael Joyner 
wrote:

> @Tadayoshi Sato
>
> I am looking to have the console logging from Spring and especially Camel
> go to Hawt. Mainly so I don't need to flip screens and if I not in the CLI.
> Would Hawtio-Log do all that?
> Thank you!
> > Rest assured, hawtio-log is not deprecated. The repository is just
> > deprecated but the code is now merged into hawtio-jmx repository and
> > maintained there.
> >
> > Regards,
> > Tadayoshi
> >
> > On Sun, Aug 12, 2018 at 3:19 AM Michael Joyner  >
> > wrote:
> >
> > > Hi,
> > > I went on hawt.io to search the loggin plugin to see my camel logs and
> > > it's deprecated.
> > > Is there a replacement ?
> > > Thanks!
> >
> >
>
>

Re: log plugin for hawtio and camel

[Tadayoshi Sato]

Rest assured, hawtio-log is not deprecated. The repository is just
deprecated but the code is now merged into hawtio-jmx repository and
maintained there.

Regards,
Tadayoshi

On Sun, Aug 12, 2018 at 3:19 AM Michael Joyner 
wrote:

> Hi,
>
> I went on hawt.io to search the loggin plugin to see my camel logs and
> it's deprecated.
> Is there a replacement ?
> Thanks!

Re: "Gave up waiting for BlueprintContainer" when using camel-test-blueprint

[Tadayoshi Sato]

Hi,

Typically it happens on CamelBlueprintTestSupport when you omit some OSGi
dependencies in pom.xml: It's not just Maven dependencies but also OSGi
bundle imports/exports. Typically a successful camel blueprint test has a
felix maven-bundle-plugin configuration and the import/export packages
declarations like these:
https://github.com/apache/camel/blob/master/parent/pom.xml#L5287-L5334
https://github.com/apache/camel/blob/master/examples/camel-example-servlet-rest-blueprint/pom.xml#L40-L45

Hope this helps.

On Tue, Feb 13, 2018 at 9:41 AM, Harrison Tarr 
wrote:

> Hi,
>
> I just heard about "camel-test-blueprint" today and I started using it. I
> was able to get a feel for it by using a contrived Camel route in a
> blueprint.xml and everything worked as expected. I'm now trying to test
> "real" camel routes in my products blueprint.xml, but I'm getting a
> RuntimeException: "Gave up waiting for BlueprintContainer". Any ideas what
> causes that? I'm at a loss, even after Google.
>
> Best Regards,
>
> Harrison Tarr
>

Re: Question about using Splitter

[Tadayoshi Sato]

Hi,

The point is that to split object message body using Splitter DSL it needs
to be either Collection, Iterator, or array. ImageCollection is a custom
class so there's no way for Camel to know how to split it.

You should be able to convert your ImageCollection into List
by simply doing something like:

from("activemq:requestQueue")
.convertBodyTo(ImageCollection.class)
.setBody(simple("${body.images}"))
.log("${body}")
.split(body())
.log("${body}")
.to("bean:downloadImageQueue")
.marshal().json(JsonLibrary.Jackson)
.to("activemq:ftpQueue");



On Wed, Dec 20, 2017 at 5:07 PM, Charles Berger <
charlesb.yesm...@googlemail.com> wrote:

> Hi,
>
> Thanks for replying.
>
> > Instead of splitting ImageCollection as the body, I think you just need
> to
> > split List as the body.
>
> Are you suggesting that the ImageCollection class is actually
> superfluous and I should use the List as the output
> from the bean uploadRequestQueue instead?
>
> Or is there a way in the route that I can call the method
> ImageCollection.getImages() method to pass into the split?
>
> Thanks,
>
> Charles.
>

Re: Question about using Splitter

[Tadayoshi Sato]

Hi,

Instead of splitting ImageCollection as the body, I think you just need to
split List as the body.

On Wed, Dec 20, 2017 at 7:50 AM, Charles Berger <
charlesb.yesm...@googlemail.com> wrote:

> Hi,
>
> I'm building my first application using Camel and have a question
> about how to use a splitter.
>
> My route receives a serialized Java class which contains a private
> ArrayList of a POJO and getter and setter methods for the list.
>
> I convert the serialized class into a its Java representation and then
> apply it to a splitter.  What I want to get out of the Splitter is
> each individual instance of the POJOs in the List but what I get
> instead is the complete list.
>
> Here is some code to show what I mean
>
> public class ImageCollection {
>
> private List images = new ArrayList();
>
> public void setImages(List) { ... }
>
> public List getImages() { }
>
> }
>
> public class SingleImageModel {
>
> members ...
>
> getters & setters
>
> }
>
> Routes:
>
> The first route accepts a POST from a servlet, validates the incoming
> payload and converts it into an instance of ImageCollection, which is
> dispatched to the requestQueue, then returns a response to the client.
>
> from("servlet:uploadUrl")
> .log("Request: ${body}")
> .to("bean:uploadRequestQueue")
> .log("${body}")
> .marshal().json(JsonLibrary.Jackson)
> .wireTap("activemq:requestQueue")
> .to("bean:formatResponse")
> .end()
>
>
> The second route is supposed to take the ImageCollection and split it
> into the SingleImageModel instances
>
>
> from("activemq:requestQueue")
> .convertBodyTo(ImageCollection.class)
> .log("${body}")
> .split(bodyAs(ImageCollection.class))
> .log("${body}")
> .to("bean:downloadImageQueue")
> .marshal().json(JsonLibrary.Jackson)
> .to("activemq:ftpQueue");
>
> I think I need to use an Aggregator to return the individual instances
> of the SingleImageModel class from the list inside ImageCollection,
> but I can't work out what that should do.
>
> Instead, what is happening is that the bean registered for the
> downloadImageQueue is receiving an instance of ImageCollection when it
> expects an instance of SingleImageModel and the type conversion in
> that bean is failing.
>
> Any guidance much appreciated.
>
> Thanks,
>
> Charles.
>

Re: Stopping one route from another

[Tadayoshi Sato]

Hi,

You can use ControlBus EIP to manage a camel route from another. It should
be what you are really looking for.
http://camel.apache.org/controlbus.html

On Thu, Sep 14, 2017 at 8:03 AM, Deepak Rajagopal <
deepak.rajago...@standard.com> wrote:

> For various reasons we would like to stop the main route from a secondary
> route based on time and then restart it at a later point in time.
> The camel page on this topic http://camel.apache.org/how-
> can-i-stop-a-route-from-a-route.html seems to indicate that we should use
> a thread to achieve this.
> Is this still a valid thing to do? Our static security scans flag the use
> of unmanaged threads .
> It is also not clear from this page whether the use of a latch alone might
> achieve the same ends?
> Thanks
>

Re: fabric-hawtio-swagger swagger version

[Tadayoshi Sato]

Hi,

hawtio-swagger-ui is used only in Red Hat JBoss Fuse products, so you
should ask Red Hat Support or the JBoss Fuse Forum below:
https://developer.jboss.org/en/products/fuse

I suspect that hawtio-swagger-ui might not work with swagger-java though
(which should work well with the scala version of swagger 1.x).


On Fri, Aug 4, 2017 at 2:47 AM, renalexster  wrote:

> I'm using Jboss Fuse 6.3 and having problem to use hawtio-swagger. Only
> works
> with version of swagger spec 1.2 (DefaultCamelSwaggerServlet), but when
> using camel-swagger-java:2.17.0.redhat-630187 doesn't work.
>
> Using DefaulCamelSwaggerServlet (camel-swagger)
>
>  interface="javax.servlet.http.HttpServlet" ref="swaggerServlet">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>  class="org.apache.camel.component.swagger.DefaultCamelSwaggerServlet"/>
>
> Using camel-swagger-java:
>
> restConfiguration().contextPath("/ati-nta/rest").component("servlet").
> dataFormatProperty("prettyPrint",
> "true")
> .host("0.0.0.0").port(8181).apiContextPath("/api-docs")
> .apiProperty("init.base.path", "ati-nta/rest")
> .apiProperty("init.api.path", "/api-docs")
> .apiProperty("init.api.description", "Serviços de consulta NAJ -
> www.gestaonaj.pe.gov.br")
> .apiProperty("api.title", "NAJ REST service")
> .apiProperty("api.version", "1.0.0")
> .apiProperty("cors", "true");
>
>
> The hawtio-swagger works in first case, but not in second.
>
> 1. camel-swagger
> 
>
> 2. camel-swagger-java
>
> 
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/fabric-hawtio-swagger-swagger-version-tp5809544.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: Downloading RedHat Version Of Camel

[Tadayoshi Sato]

AFAIK Red Hat products don't use 2.19 versions of Camel. JBoss FIS should
use 2.18 but no idea where they are. So atm you can find 2.17 or 2.20
(unstable).

FYI this repo (note it's 'origin-' repository) provides slightly newer
(development) versions than 'repository':
https://origin-repository.jboss.org/nexus/content/groups/ea/org/apache/camel/apache-camel/

On Wed, Aug 2, 2017 at 12:30 AM, Zoran Regvart  wrote:

> Hi Kevin,
> you can find JBoss repositories listed here:
>
> https://access.redhat.com/maven-repository
>
> I think you want the early access repository. There is also JBoss Fuse
> forum at:
>
> https://developer.jboss.org/en/products/fuse
>
> that you can ask this questions and get a qualified answer,
>
> zoran
>
> On Tue, Aug 1, 2017 at 3:35 PM, Urciolo, Kevin J [US] (MS)
>  wrote:
> > Is there a place where one can download recent version of a pre-built
> RedHat (productized) version of Apache Camel?  My organization does not
> have a support license, but would like to use the open source nature of the
> productized version.
> >
> > I can see that a recent version of 2.17 is available at the following
> link.
> >
> > https://repository.jboss.org/nexus/content/groups/ea/org/
> apache/camel/apache-camel/
> >
> > I am just wondering if there are newer version available, say 2.18 or
> 2.19.
>
>
>
> --
> Zoran Regvart
>

Re: Bug in onException with onRedelivery

[Tadayoshi Sato]

Hi,

I would first check if AnotherException is really thrown from MyProcessor.

On Thu, May 4, 2017 at 1:35 AM, Ryan T  wrote:

> Can someone verify that this is a bug or not?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Bug-in-onException-with-onRedelivery-tp5798549p5798619.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: Exception not thrown on connect failed in Dynamic Routes

[Tadayoshi Sato]

Hi,

> Camel Version used: 2.10.1
> JDK: 6

It's actually quite old. Try the latest Camel 2.18.3 and JDK 8 and see the
issue is still persistent. Many bugs have been fixed since 2.10.1.

On Mon, Mar 27, 2017 at 6:01 PM, Shankar, Shivaranjini <
shivaranjini.shan...@blackrock.com> wrote:

> Hi team
>
> We are facing the following issue. Whenever the camel route is unable to
> connect to an endpoint(from a list of endpoints dynamically generated using
> "@DynamicRouter"), it stops sftp-ing the files to all endpoints after the
> failed endpoint and also it does not throw an error when the said endpoint
> fails.
> Is there a way to resolve this issue, because an exception doesn't seem to
> be thrown. (I have added the onException clause to the camel route to
> handle any exception thrown)
>
> Camel Version used: 2.10.1
>
> JDK: 6
>
>
>
> JiRA raised for this issue: https://issues.apache.org/
> jira/browse/CAMEL-11071
>
> Thiis was a similar question raised on stack overflow.
>
> http://stackoverflow.com/questions/40966290/apache-
> camel-dynamic-route-continue-when-exception-occurs
>
>
> Thanks and Regards
> Shivaranjini Shankar
> Analyst | BlackRock
> Phone: +91-124-678-0805 | Mobile: +91 92-05-184684
>
>
> This message may contain information that is confidential or privileged.
> If you are not the intended recipient, please advise the sender immediately
> and delete this message. See http://www.blackrock.com/
> corporate/en-us/compliance/email-disclaimers for further information.
> Please refer to http://www.blackrock.com/corporate/en-us/compliance/
> privacy-policy for more information about BlackRock’s Privacy Policy.
> For a list of BlackRock's office addresses worldwide, see
> http://www.blackrock.com/corporate/en-us/about-us/contacts-locations.
>
> © 2017 BlackRock, Inc. All rights reserved.
>

Re: Fatal error in the JVM with weblogic and apache camel

[Tadayoshi Sato]

Hi,

Not sure if it helps, but there are two things to note.

1. You are not using Java 7 really according to the log attached. What
would happen if you change it to Java 7?
2. Your Java 8 is not the latest version: 1.8.0_71-b15  Try update it to
latest as it might have fixed a relevant JDK bug.

If all those don't help, I'd suggest cutting down your camel app to minimal
and see what element in the camel app is really contributing to the issue.

On Sun, Mar 12, 2017 at 8:54 PM, omblanco  wrote:

> I am developing a soap service with apache camel in weblogic 12.1.3. My
> problem is the version I have to use.
>
> With versions 2.15.x it works perfectly (exactly version 2.15.6), but I
> want
> to upgrade to the latest compatible version for java 1.7, which is 2.17.5
> and an error occurs which stops the server.
>
> The application's java code works correctly, and the error occurs when the
> response is returned.
>
> The server stops and generates a log file with the process pid. This is the
> error using the -verbose: class option:
>
>
> And the full log:
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Fatal-error-in-the-JVM-with-weblogic-and-apache-camel-tp5795309.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: Camel Netty could not process on heavy load

[Tadayoshi Sato]

Hello,

Why can't you use 'workerCount' option?  It overrides the default number of
threads for Netty.
http://camel.apache.org/netty.html

Best regards,
Tadayoshi

On Sat, Sep 24, 2016 at 3:58 PM, jayashankar  wrote:

> Using camel netty component redhat version 2.12.X version to consume TCP
> requests
>
> System configuration: 8 Core CPU
>
> As per my understanding
> Boss thread poll will accept the request and ask worker threads poll to
> process it.
> For each port, 1 Boss Thread and 16 worker threads are available.
>
> Limitations:
>If all worker threads are busy, boss threads will not hand over requests
> to process and it will still be waiting for worker thread to be available.
>This is impacting our performance, we have to use TCP Protocol and JBoss
> Fuse 6.1 but serve more 30 - 50 request per second
>
> Finding possible solutions by below proxy server:
>   1. HAProxy
>   2. Nginx
>
> With these, I am able to accept TCP requests but could not forward HTTP
> post
> - (Using Camel Jetty Consumer)
>
> is there any way to over come this problem, please let me know.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Camel-Netty-could-not-process-on-heavy-load-tp5787988.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: How to test Camel-http outbound calls

[Tadayoshi Sato]

Hello,

Whether or not it's a standard practice, I don't think there is any other
good approach than either mocking the component and checking the headers,
or using an embedded Jetty server inside the test case. Also, such kind of
integration test should be more reliable if you want to repeatedly check
missing runtime dependencies.

Best regards,
Tadayoshi

On Sat, Sep 24, 2016 at 4:24 PM, Goyal, Arpit  wrote:

> We have to validate whether the authentication and encryption aspect of
> HTTP outbound calls are working properly. On searching most of the testing
> pointers are to mock the component and verify the values being sent to HTTP
> endpoint. But based on the link [1] there is a comment at the end which
> talks about using Jetty consumer to verify whether http calls are
> successful making it more of an integration test rather than unit test.
>
> Is such kind of integration test standard practice with camel HTTP (or
> SOAP) outbound calls?
>
> Also, we regularly update our camel version to pick the latest version.
> Sometimes jars could be missed and such test helps in through unresolved
> runtime-dependencies. So thinking of having such integration tests.
>
> Regards,
> Arpit.
>
>
> [1] - http://stackoverflow.com/questions/37290910/camel-
> junit-test-http-component-with-bean-component
>

Re: camel-sql IN query number of parameters mismatch

[Tadayoshi Sato]

Hi,

Looks like the same issue was discussed in this ML a month ago :-)
http://camel.465427.n5.nabble.com/camel-sql-SQL-IN-Query-issue-2-17-1-td5783264.html

Isn't it the same as yours?  For convenience, Claus suggested the following
solution in that thread:

> I wonder if its the Oracle JDBC driver issue, that it does not return
> correct value for number of parameters in the prepared statement.
>
> There is an option parametersCount you can use to set a fixed value if
> the JDBC driver cannot return correct data. See its documentation
> http://camel.apache.org/sql-component.html
>
> However that value is fixed, and if you use a dynamic IN list then you
> would need to use  to make the uri dynamic. (less good but
> possible). But at least maybe try to set that value = 1000 as you use
> in your example, and see if that at least work.

On Wed, Jul 13, 2016 at 1:29 AM, juliaaano  wrote:

> I'm running Camel 2.17.2.
>
> I've been experiencing a problem when using IN query in a SQL statement
> where there is more than one parameter, besides the one declared within the
> IN clause. For example:
>
> .to("SELECT * FROM projects WHERE license = :#${body} AND project IN
> (:#in:names)")
>
> Caused by: java.sql.SQLException: Number of parameters mismatch. Expected:
> 3, was: 2
> at
>
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.populateStatement(DefaultSqlPrepareStatementStrategy.java:153)
> at
>
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:146)
> at
>
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:116)
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:629)
> ... 54 more
>
> I've noticed someone already mentioned this in another recent thread, but I
> don't find this specific issue being considered there.
>
> I forked Camel, created a test case that reproduces the problem and pushed
> in a branch here:
>
> https://github.com/juliaaano/camel/tree/sql-in-multiple-params
>
> Do you guys consider this to be a bug? I'd be happy to report and submit a
> pull request with the fix.
>
> I suspect the problem is around
>
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.NamedQueryParser
> in the next() method.
>
> Please let me know how I can help. I'd love to contribute.
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/camel-sql-IN-query-number-of-parameters-mismatch-tp5785054.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Re: Exchange.HTTP_QUERY and Exchange.HTTP_RAW_QUERY

[Tadayoshi Sato]

Hi,

You can look at this:
https://issues.apache.org/jira/browse/CAMEL-7138

So essentially the difference corresponds to the difference between
java.net.URI's getQuery() and getRawQuery():
https://docs.oracle.com/javase/8/docs/api/java/net/URI.html

If you have a query like 'x=%26%26%26', Exchange.HTTP_QUERY should return
'x=&&&', whereas Exchange.HTTP_RAW_QUERY should return 'x=%26%26%26'.

On Fri, Jul 8, 2016 at 4:32 PM, Debraj Manna 
wrote:

> Hi
>
> Can someone please explain me the difference between Exchange.HTTP_QUERY
> and Exchange.HTTP_RAW_QUERY?
>
> I am not able to find the difference in the http doc
> .
>

Re: Error occurred during starting Camel because of cannot look up a processor from registry

[Tadayoshi Sato]

Hmm, this just works for me. Note "productHelper" also has the cyclic
dependency.

On Wed, Jul 6, 2016 at 5:56 PM, Debraj Manna <subharaj.ma...@gmail.com>
wrote:

> No it is not working.
>
> I think the issue is not because of the separate xml files. It is because
> jsonRPCProcessor is using myTemplate and myTemplate is defined in
> camelContext and camelContext is using jsonRPCProcessor in routes.
>
> On Wed, Jul 6, 2016 at 2:16 PM, Tadayoshi Sato <sato.tadayo...@gmail.com>
> wrote:
>
> > No, in the same camelContext.xml file but outside of .
> > Doesn't that work for you?
> >
> > On Wed, Jul 6, 2016 at 5:34 PM, Debraj Manna <subharaj.ma...@gmail.com>
> > wrote:
> >
> > > Are you saying  to define jsonRPCProcessor inside camelContext.
> Something
> > > like below:-
> > >
> > > http://camel.apache.org/schema/blueprint;
> > > useMDCLogging="true">
> > > 
> > > * > >
> > >
> >
> class="com.j1.orchestratorservice.basecomponent.processor.JSONRPCProcessor">*
> > > *...*
> > > **
> > >
> > > 
> > > http://0.0.0.0:/orchestratorservice;
> />
> > >     
> > > 
> > > 
> > >  > > uri="jetty:
> > > http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true; />
> > > 
> > > 
> > > ...
> > > 
> > >
> > > On Wed, Jul 6, 2016 at 7:00 AM, Tadayoshi Sato <
> sato.tadayo...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Debraj,
> > > >
> > > > Then why can you not define jsonRPCProcessor in camelContext.xml
> > instead
> > > of
> > > > blueprint.xml?  If this processor depends on a specific producer
> > template
> > > > ("myTemplate") == Camel context, then I see no reasons this producer
> > can
> > > be
> > > > shared across multiple Camel contexts.
> > > >
> > > > On Tue, Jul 5, 2016 at 8:01 PM, Debraj Manna <
> subharaj.ma...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Yeah Tadayoshi. jsonRPCProcessor is using myTemplate as shown
> below:-
> > > > >
> > > > >  > > > >
> > > > >
> > > >
> > >
> >
> class="com.j1.orchestratorservice.basecomponent.processor.JSONRPCProcessor">
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  > > > > value-ref="createProductsWFInfo" />
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > >
> > > > > whereas myTemplate is defined in camelContext which in turn is
> using
> > > > > jsonRPCProcessor as shown below:-
> > > > >
> > > > > http://camel.apache.org/schema/blueprint;
> > > > > useMDCLogging="true">
> > > > > 
> > > > > 
> > > > > http://0.0.0.0:/orchestratorservice
> > "
> > > />
> > > > > 
> > > > > 
> > > > > 
> > > > >  > > > >
> > > > > uri="jetty:
> > > > > http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true;
> > > > > />
> > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > >
> > > > >
> > > > > I have tried to set the producer in my custom jsonRPCProcessor as
> > > > mentioned
> > > > > in this link
> > > > > <
> > > > >
> > > >
> > >
> >
> http://camel.apache.org/how-do-i-write-a-custom-processor-which-sends-multiple-messages.html
> > > > > >.
> > > > > Can someone suggest me some other way of setting the producer in my
> > > > custom
> > > > > jsonRPCProcessor so that it does not lead to any circular
> dependency?
> > > > >
> > > > > On Tue, Jul 5, 2016 at 8:21 AM, Tadayos

Re: Is it possible to make a message header or property immutable?

[Tadayoshi Sato]

Hi,

It's just an idea off the top of my head, but what about providing a parity
check header in company with the header you want to be immutable. I.e.

YOUR_HEADER = "Do not change!"
YOUR_HEADER_MD5 = "fef4de21954d4b9f1b3e61ed153799da"

or

YOUR_HEADER_HASH = "md5:fef4de21954d4b9f1b3e61ed153799da"

When making use of this header, you can always validate if it's not changed
in the routes.

On Wed, Jul 6, 2016 at 6:03 AM, Matt Sicker  wrote:

> Let me give a more specific use case. Path parameters from rest-dsl are
> passed in as message headers. I don't want any route to accidentally
> overwrite or modify those headers as they're useful for the entire
> lifecycle of that message.
>
> On 5 July 2016 at 16:00, Matt Sicker  wrote:
>
> > The exact use case is preventing developers from [inadvertently]
> modifying
> > headers or properties that are used before and after a particular
> subroute.
> >
> > On 5 July 2016 at 15:57, souciance 
> > wrote:
> >
> >> I guess the question is, why would different routes split over different
> >> bundles want to write over the same header/property? What's the case
> here?
> >> Surely it cannot be just to prevent accidents by developers because what
> >> would be their reason to write over that header?
> >>
> >> I think it is better to agree on a naming and some sort of other
> >> convention
> >> and stick to that because I don't think there is a way to to make a
> header
> >> immutable. I guess an ugly solution would be to save the header in a map
> >> and give the key name something very unique.
> >>
> >> On Tue, Jul 5, 2016 at 10:48 PM, Matt Sicker [via Camel] <
> >> ml-node+s465427n578481...@n5.nabble.com> wrote:
> >>
> >> > Please let me know if you think of anything!
> >> >
> >> > On 5 July 2016 at 15:16, Brad Johnson <[hidden email]
> >> > > wrote:
> >> >
> >> > > I certainly understand the impulse and think it is spot on but can't
> >> > think
> >> > > of how to do it with headers.  Claim checks might work but they are
> >> > really
> >> > > for reducing overhead of data and not for locking like that but that
> >> > might
> >> > > be a viable solution depending on the exact problem.
> >> > >
> >> > > Thanks Matt, this is going to be stuck in my head now.  I'll
> probably
> >> > dream
> >> > > of an answer of some sort tonight.
> >> > >
> >> > > Brad
> >> > >
> >> > > On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker <[hidden email]
> >> > > wrote:
> >> > >
> >> > > > My use case is basically to help prevent bugs where a header or
> >> > exchange
> >> > > > property gets modified. Some of my routes in question branch out
> >> into
> >> > > > several different bundles, and it is difficult to enforce
> contracts
> >> > that
> >> > > > way amongst several developers with varying levels of Camel
> >> expertise.
> >> > > > Similar to how one might use final variables to prevent people
> from
> >> > > > reassigning them, this could be a final header that prevents
> people
> >> > from
> >> > > > reusing them for things.
> >> > > >
> >> > > > On 5 July 2016 at 14:22, Brad Johnson <[hidden email]
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > That's what I figured.  I'd have to look at the Map
> implementation
> >> > of
> >> > > the
> >> > > > > exchange but as far as I know there isn't a way to make it a
> write
> >> > once
> >> > > > > only operation.  It's just a map of some sort.  There might be a
> >> way
> >> > to
> >> > > > do
> >> > > > > it with transactions but I'm not an expert there.  I generally
> use
> >> > > > headers
> >> > > > > but in reality should probably be using exchange properties more
> >> > often.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
> >> > > > >
> >> > > > > Almost any mechanism I can think of off the top of my head could
> >> be
> >> > > > > subverted by someone who wanted to or who didn't understand that
> >> the
> >> > > > value
> >> > > > > associated with the bean shouldn't be modified.  For example,
> you
> >> > could
> >> > > > > create a bean that you associate with your header that stores
> data
> >> > but
> >> > > > also
> >> > > > > returns a UUID.  That UUID could be stored in another header and
> >> > > sometime
> >> > > > > later in the routes you could verify that the bean stored under
> >> your
> >> > > key
> >> > > > > returns the same UUID as the header indicates.  But that
> wouldn't
> >> > stop
> >> > > > > someone from changing the bean stored to the key and it wouldn't
> >> > > prevent
> >> > > > > them from updating the UUID to a new bean they might create.
> >> > > > >
> >> > > > > On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker <[hidden email]
> >> > 

Re: Error occurred during starting Camel because of cannot look up a processor from registry

[Tadayoshi Sato]

No, in the same camelContext.xml file but outside of .
Doesn't that work for you?

On Wed, Jul 6, 2016 at 5:34 PM, Debraj Manna <subharaj.ma...@gmail.com>
wrote:

> Are you saying  to define jsonRPCProcessor inside camelContext. Something
> like below:-
>
> http://camel.apache.org/schema/blueprint;
> useMDCLogging="true">
> 
> *
> class="com.j1.orchestratorservice.basecomponent.processor.JSONRPCProcessor">*
> *...*
> **
>
> 
> http://0.0.0.0:/orchestratorservice; />
> 
> 
> 
>  uri="jetty:
> http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true; />
> 
> 
> ...
> 
>
> On Wed, Jul 6, 2016 at 7:00 AM, Tadayoshi Sato <sato.tadayo...@gmail.com>
> wrote:
>
> > Hi Debraj,
> >
> > Then why can you not define jsonRPCProcessor in camelContext.xml instead
> of
> > blueprint.xml?  If this processor depends on a specific producer template
> > ("myTemplate") == Camel context, then I see no reasons this producer can
> be
> > shared across multiple Camel contexts.
> >
> > On Tue, Jul 5, 2016 at 8:01 PM, Debraj Manna <subharaj.ma...@gmail.com>
> > wrote:
> >
> > > Yeah Tadayoshi. jsonRPCProcessor is using myTemplate as shown below:-
> > >
> > >  > >
> > >
> >
> class="com.j1.orchestratorservice.basecomponent.processor.JSONRPCProcessor">
> > > 
> > > 
> > > 
> > > 
> > >  > > value-ref="createProductsWFInfo" />
> > > 
> > > 
> > > 
> > > 
> > >
> > >
> > > whereas myTemplate is defined in camelContext which in turn is using
> > > jsonRPCProcessor as shown below:-
> > >
> > > http://camel.apache.org/schema/blueprint;
> > > useMDCLogging="true">
> > > 
> > > 
> > > http://0.0.0.0:/orchestratorservice;
> />
> > > 
> > > 
> > > 
> > >  > >
> > > uri="jetty:
> > > http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true;
> > > />
> > > 
> > > 
> > > ...
> > > 
> > >
> > >
> > > I have tried to set the producer in my custom jsonRPCProcessor as
> > mentioned
> > > in this link
> > > <
> > >
> >
> http://camel.apache.org/how-do-i-write-a-custom-processor-which-sends-multiple-messages.html
> > > >.
> > > Can someone suggest me some other way of setting the producer in my
> > custom
> > > jsonRPCProcessor so that it does not lead to any circular dependency?
> > >
> > > On Tue, Jul 5, 2016 at 8:21 AM, Tadayoshi Sato <
> sato.tadayo...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > It looks like 'myTemplate' is defined in camelContext.xml, but the
> > Camel
> > > > context then refers to 'jsonRPCProcessor' in blueprint.xml, which in
> > > turns
> > > > refers to 'myTemplate'. That should be the cyclic dependency in
> > question.
> > > >
> > > > Hope this helps,
> > > >
> > > > Tadayoshi
> > > >
> > > > On Mon, Jul 4, 2016 at 10:27 PM, Debraj Manna <
> > subharaj.ma...@gmail.com>
> > > > wrote:
> > > >
> > > > > It seems the error is getting triggered because of some cyclic
> > > > dependency.
> > > > > But I am not able to figure out from the trace what is causing the
> > > cyclic
> > > > > dependency.
> > > > >
> > > > > On Jul 4, 2016 4:22 PM, "Debraj Manna" <subharaj.ma...@gmail.com>
> > > wrote:
> > > > >
> > > > > > On placing a bundle (using camel) on Karaf I am seeing the below
> > > > > > exception. The below exception comes only when the bundle is
> > started.
> > > > > After
> > > > > > that everything works fine. The exeception does not seem to
> effect
> > > our
> > > > > > functionality. The issue is coming on both camel 2.16.1 (deployed
> > on
> > > > > servicemix
> > &

Re: Unit test case for XML DSL context and routes

[Tadayoshi Sato]

Hi,

Have you checked CamelSpringTestSupport?
http://camel.apache.org/spring-testing.html

You can specify the Camel context XML under test by simply overriding the
createApplicationContext method:

protected AbstractXmlApplicationContext createApplicationContext() {
return new
ClassPathXmlApplicationContext("META-INF/spring/your-context.xml");
}

If you are using Blueprint XML then you can refer
to CamelBlueprintTestSupport.

On Tue, Jul 5, 2016 at 11:23 PM, Vanshul.Chawla 
wrote:

> Thanks.
>
> I have seen this link.
>
> I had some doubts. I have camelcontext.xml which gets message from MQ and
> transforms and sends to a webservice, gets a response and then transforms
> and send back to another queue.
> I can mock the end points and can assert based on conditions etc.
>
> How to tell my test case class that I am using which camelcontext.xml? ie
> how to bind test case and xml together?
>
> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com]
> Sent: Tuesday, July 05, 2016 9:17 AM
> To: users@camel.apache.org
> Subject: RE: Unit test case for XML DSL context and routes
>
> http://camel.apache.org/testing.html
>
> > -Original Message-
> > From: Vanshul.Chawla [mailto:vanshul.cha...@target.com]
> > Sent: Tuesday, July 05, 2016 10:08 AM
> > To: users@camel.apache.org
> > Subject: Unit test case for XML DSL context and routes
> >
> > Hello All,
> >
> > We have some Camel code which is written in XML DSL. We need to add
> > unit test cases for each context(multiple routes) . Could someone
> > please give a lead to how this can be achieved.
> >
> > Vanshul
>
>

Re: Error occurred during starting Camel because of cannot look up a processor from registry

[Tadayoshi Sato]

Hi Debraj,

Then why can you not define jsonRPCProcessor in camelContext.xml instead of
blueprint.xml?  If this processor depends on a specific producer template
("myTemplate") == Camel context, then I see no reasons this producer can be
shared across multiple Camel contexts.

On Tue, Jul 5, 2016 at 8:01 PM, Debraj Manna <subharaj.ma...@gmail.com>
wrote:

> Yeah Tadayoshi. jsonRPCProcessor is using myTemplate as shown below:-
>
> 
> class="com.j1.orchestratorservice.basecomponent.processor.JSONRPCProcessor">
> 
> 
> 
> 
>  value-ref="createProductsWFInfo" />
> 
> 
> 
> 
>
>
> whereas myTemplate is defined in camelContext which in turn is using
> jsonRPCProcessor as shown below:-
>
> http://camel.apache.org/schema/blueprint;
> useMDCLogging="true">
> 
> 
> http://0.0.0.0:/orchestratorservice; />
> 
> 
> 
> 
> uri="jetty:
> http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true;
> />
> 
> 
> ...
> 
>
>
> I have tried to set the producer in my custom jsonRPCProcessor as mentioned
> in this link
> <
> http://camel.apache.org/how-do-i-write-a-custom-processor-which-sends-multiple-messages.html
> >.
> Can someone suggest me some other way of setting the producer in my custom
> jsonRPCProcessor so that it does not lead to any circular dependency?
>
> On Tue, Jul 5, 2016 at 8:21 AM, Tadayoshi Sato <sato.tadayo...@gmail.com>
> wrote:
>
> > Hi,
> >
> > It looks like 'myTemplate' is defined in camelContext.xml, but the Camel
> > context then refers to 'jsonRPCProcessor' in blueprint.xml, which in
> turns
> > refers to 'myTemplate'. That should be the cyclic dependency in question.
> >
> > Hope this helps,
> >
> > Tadayoshi
> >
> > On Mon, Jul 4, 2016 at 10:27 PM, Debraj Manna <subharaj.ma...@gmail.com>
> > wrote:
> >
> > > It seems the error is getting triggered because of some cyclic
> > dependency.
> > > But I am not able to figure out from the trace what is causing the
> cyclic
> > > dependency.
> > >
> > > On Jul 4, 2016 4:22 PM, "Debraj Manna" <subharaj.ma...@gmail.com>
> wrote:
> > >
> > > > On placing a bundle (using camel) on Karaf I am seeing the below
> > > > exception. The below exception comes only when the bundle is started.
> > > After
> > > > that everything works fine. The exeception does not seem to effect
> our
> > > > functionality. The issue is coming on both camel 2.16.1 (deployed on
> > > servicemix
> > > > 6.1.0) and camel 2.16.3 (deployed on servicemix 7.0.0M2).
> > > >
> > > > My blueprint is split into three files. A simplified version of them
> > are
> > > > shown below:-
> > > >
> > > >
> > > >1. blueprint.xml placed here
> > > ><
> > > https://gist.github.com/debraj-manna/42294561b9da22ce2281e6a9f3b22a34>
> > > >.
> > > >2. productBeans.xml placed here
> > > ><
> > > https://gist.github.com/debraj-manna/5c406f597f8b7248369b206ed1f93842>
> > > >.
> > > >3. camelContext.xml placed here
> > > ><
> > > https://gist.github.com/debraj-manna/4210653d661beaee6beb87900c4f4911>
> > > >.
> > > >
> > > >
> > > > Can some please let me know why is this exception coming during
> bundle
> > > > start?
> > > >
> > > > The exception looks like below:-
> > > >
> > > > 2016-07-04 11:29:37,497 | ERROR | mix-6.1.0/deploy |
> > > BlueprintCamelContext
> > > >| 143 - org.apache.camel.camel-blueprint - 2.16.1 | {{
> > > bundle.id
> > > > ,143}{bundle.name
> > > ,org.apache.camel.camel-blueprint}{bundle.version,2.16.1}}
> > > > | Error occurred during starting Camel: CamelContext(camel-1) due
> > Failed
> > > to
> > > > create route orchestrator-service-route at: >>>
> > > > process[ref:jsonRPCProcessor] <<< in route:
> > > > Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0...
> > because
> > > > of Cannot lookup: jsonRPCProcessor from registry:
> > > > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97

Re: Error occurred during starting Camel because of cannot look up a processor from registry

[Tadayoshi Sato]

Hi,

It looks like 'myTemplate' is defined in camelContext.xml, but the Camel
context then refers to 'jsonRPCProcessor' in blueprint.xml, which in turns
refers to 'myTemplate'. That should be the cyclic dependency in question.

Hope this helps,

Tadayoshi

On Mon, Jul 4, 2016 at 10:27 PM, Debraj Manna 
wrote:

> It seems the error is getting triggered because of some cyclic dependency.
> But I am not able to figure out from the trace what is causing the cyclic
> dependency.
>
> On Jul 4, 2016 4:22 PM, "Debraj Manna"  wrote:
>
> > On placing a bundle (using camel) on Karaf I am seeing the below
> > exception. The below exception comes only when the bundle is started.
> After
> > that everything works fine. The exeception does not seem to effect our
> > functionality. The issue is coming on both camel 2.16.1 (deployed on
> servicemix
> > 6.1.0) and camel 2.16.3 (deployed on servicemix 7.0.0M2).
> >
> > My blueprint is split into three files. A simplified version of them are
> > shown below:-
> >
> >
> >1. blueprint.xml placed here
> ><
> https://gist.github.com/debraj-manna/42294561b9da22ce2281e6a9f3b22a34>
> >.
> >2. productBeans.xml placed here
> ><
> https://gist.github.com/debraj-manna/5c406f597f8b7248369b206ed1f93842>
> >.
> >3. camelContext.xml placed here
> ><
> https://gist.github.com/debraj-manna/4210653d661beaee6beb87900c4f4911>
> >.
> >
> >
> > Can some please let me know why is this exception coming during bundle
> > start?
> >
> > The exception looks like below:-
> >
> > 2016-07-04 11:29:37,497 | ERROR | mix-6.1.0/deploy |
> BlueprintCamelContext
> >| 143 - org.apache.camel.camel-blueprint - 2.16.1 | {{
> bundle.id
> > ,143}{bundle.name
> ,org.apache.camel.camel-blueprint}{bundle.version,2.16.1}}
> > | Error occurred during starting Camel: CamelContext(camel-1) due Failed
> to
> > create route orchestrator-service-route at: >>>
> > process[ref:jsonRPCProcessor] <<< in route:
> > Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0... because
> > of Cannot lookup: jsonRPCProcessor from registry:
> > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97 with
> > expected type: interface org.apache.camel.Processor due:
> > [BeanRecipe[name='myTemplate'],
> > BeanRecipe[name='.camelBlueprint.bean.factory.myTemplate'],
> > BeanRecipe[name='camel-1'], BeanRecipe[name='myTemplate']]
> > org.apache.camel.FailedToCreateRouteException: Failed to create route
> > orchestrator-service-route at: >>> process[ref:jsonRPCProcessor] <<< in
> > route: Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0...
> > because of Cannot lookup: jsonRPCProcessor from registry:
> > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97 with
> > expected type: interface org.apache.camel.Processor due:
> > [BeanRecipe[name='myTemplate'],
> > BeanRecipe[name='.camelBlueprint.bean.factory.myTemplate'],
> > BeanRecipe[name='camel-1'], BeanRecipe[name='myTemplate']]
> > at
> >
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1072)
> > at
> >
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:196)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:947)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3258)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2981)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2812)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2808)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2831)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2808)
> > at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> > at
> >
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2777)
> > at
> >
> org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:180)[143:org.apache.camel.camel-blueprint:2.16.1]
> > at
> >
> org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:212)[143:org.apache.camel.camel-blueprint:2.16.1]
> > at
> >
> org.apache.camel.blueprint.BlueprintCamelContext.serviceChanged(BlueprintCamelContext.java:150)[143:org.apache.camel.camel-blueprint:2.16.1]
> > at
> >
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)[org.apache.felix.framework-4.2.1.jar:]
> > at
> >
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)[org.apache.felix.framework-4.2.1.jar:]
> > at
> >
>