[GitHub] camel pull request #2309: CAMEL-12455 - add DELIVERY_MODE to headers

[WillemJiang]

Github user WillemJiang closed the pull request at:

https://github.com/apache/camel/pull/2309


---

Re: [DISUSS] - Apache Camel 2.21.1 Release

[Gregor Zurowski]

+1 for Camel 2.21.1

And yes, I will try to cut the release over the weekend.

Thanks,
Gregor


On Thu, Apr 26, 2018, 4:31 PM Claus Ibsen  wrote:

> Hi
>
> I think its soon time for us to get the first patch release out for
> the new 2.21.x branch.
> We have 49 JIRAs resolved.
>
> There are 3 outstanding but they can easily be moved to 2.21.2 release
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.21.1%20AND%20statusCategory%20%3D%20new
>
> So frankly I think the branch is good to cut a RC anytime.
>
> Gregor Z. are you around and would you be willing yet again to work on
> a new release?
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

[GitHub] camel pull request #2309: CAMEL-12455 - add DELIVERY_MODE to headers

[onderson]

GitHub user onderson opened a pull request:

https://github.com/apache/camel/pull/2309

CAMEL-12455 - add DELIVERY_MODE to headers



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/onderson/camel CAMEL-12455

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2309.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2309


commit 7221f82da2d2d9a0706d82a7f22a2242abe410ce
Author: Sezgin 
Date:   2018-04-26T17:23:03Z

CAMEL-12455 - add DELIVERY_MODE to headers




---

[DISUSS] - Apache Camel 2.21.1 Release

[Claus Ibsen]

Hi

I think its soon time for us to get the first patch release out for
the new 2.21.x branch.
We have 49 JIRAs resolved.

There are 3 outstanding but they can easily be moved to 2.21.2 release
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20fixVersion%20%3D%202.21.1%20AND%20statusCategory%20%3D%20new

So frankly I think the branch is good to cut a RC anytime.

Gregor Z. are you around and would you be willing yet again to work on
a new release?



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

[GitHub] camel pull request #2307: CAMEL-12460 Fix camel actuator endpoints to get it...

[davsclaus]

Github user davsclaus closed the pull request at:

https://github.com/apache/camel/pull/2307


---

[GitHub] camel pull request #2306: Fixed the Defect manual commit not working

[davsclaus]

Github user davsclaus closed the pull request at:

https://github.com/apache/camel/pull/2306


---

[GitHub] camel pull request #2308: CAMEL-12442:rest-dsl - Rest producer should use Re...

[davsclaus]

Github user davsclaus closed the pull request at:

https://github.com/apache/camel/pull/2308


---

Re: [REVIEW] - Optimised toD for HTTP components

[Claus Ibsen]

Hi

Thanks for the review and comments.

Okay squashed and merged on master branch. Lets do optimisations for
other components.





On Mon, Apr 23, 2018 at 12:50 PM, Claus Ibsen  wrote:
> Hi
>
> We have ticket
> https://issues.apache.org/jira/browse/CAMEL-12462
>
> Its an idea I had though about in the past, even before we had toD.
> However I do think that the simplification toD gives Camel end users,
> can warrant that we attempted to look at this again.
>
> In particular when you have HTTP endpoints that are dynamic (different
> query parameters, context-path, etc) but calling to the same HTTP
> server, then toD should ideally be optimised to deal with this
> out-of-the-box. Today you end up with unique Camel endpoints per
> unique combo computed from toD.
>
> So CAMEL-12462 optimised and resolved this. However it does this with
> a little bit of complexity of parsing the computed endpoint uri to
> resolve it into 3 parts
>
> - static base uri
> - dynamic context-path
> - dynamic query parameters
>
> Then it will use the static base url, as the Camel endpoint, and
> therefore resolve into a single endpoint and Camel http producer. And
> the dynamic parts are automatic provided in Camel headers that the
> HTTP producer supports (HTTP_PATH and HTTP_QUERY).
>
> Anyway the PR has some docs and examples and more details in the
> updated adoc file for toD, so take a look at that file.
>
> I implemented this with a way for components to support this by
> providing a service locator file in the send-dynamic folder of
> META-INF, eg same way we discover components. This way other
> components can provide their own optimisation implementation in the
> future. For example to other kinds of components like JMS, Kafka and
> others.
>
> I wanted to give the community and other Camel committers a chance to
> provide feedback, review, improve, etc - before we merged this into
> the master branch.
>
> There is a GitHub PR that makes it easier to browse the code changes
> https://github.com/apache/camel/pull/2302
>
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



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

[GitHub] camel pull request #2302: CAMEL-12462

[davsclaus]

Github user davsclaus closed the pull request at:

https://github.com/apache/camel/pull/2302


---

[GitHub] camel pull request #2305: Remove Metric 3.0.1 related classloader leak warni...

[davsclaus]

Github user davsclaus closed the pull request at:

https://github.com/apache/camel/pull/2305


---

Re: News on front page about new website and documentation

[Willem Jiang]

oh, my bad.
The URL  that I want to share is.

https://github.com/apache/incubator-servicecomb-website


Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
  http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Apr 26, 2018 at 2:33 AM, Claus Ibsen  wrote:

> Hi Willem
>
> Great to hear you got some experience with building a website with
> markdown content.
> We are using ascii doc but it should be similar.
>
> If you wanted to refer to a link in [1] then I dont see that in your email.
>
>
> On Wed, Apr 25, 2018 at 6:45 PM, Willem Jiang 
> wrote:
> > +1 for bring a new website.
> >
> > Normally, there are some building blocks project in the github for the
> > personal website.
> > Last year we built a new website[1] for the ServiceComb project by using
> > markdown as the content.
> > Maybe we can do the same thing for the new camel website.
> >
> > Any thoughts?
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> >   http://jnn.iteye.com  (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Mar 26, 2018 at 5:12 PM, Claus Ibsen 
> wrote:
> >
> >> Hi
> >>
> >> I have created a new draft to post on the Camel front page.
> >>
> >> Any comments and feedback?
> >>
> >>
> >>
> >>
> >> Update on the Apache Camel website and documentation
> >> 
> >>
> >> The current Apache Camel website and documentation is currently
> undergoing
> >> work to be rewamped and updated for a modern website.
> >>
> >> This work has been underway for a longer time. We kicked off the work by
> >> migrating the documentation of every Camel component from the wiki
> system
> >> to the source code as ascii doc files. This allowed us during the build
> >> of the Apache Camel project to automatic keep parts of the documentation
> >> up-to-date with the source code, such as when new options is added to
> >> components.
> >> We then moved on migrate all the data formats, languages, and the EIP
> >> patterns.
> >>
> >> This has been substantional work, as if you were to print all the
> >> Camel documentation
> >> then it would be more than 3000 sheets of papers.
> >>
> >> At this point of time, we are about to draft up a new table of content
> >> (TOC) for the
> >> new Apache Camel documentation and user guide. With the new TOC we
> >> will then re-work
> >> all the user guide documentation to be updated and focus on modern
> >> developer with Camel.
> >> In doing so we will grab the good parts of the existing (older)
> >> documentation, and in
> >> places needed, we will rewrite the documentation.
> >>
> >> The new website and documentation has a new build system that is also
> >> worked. When this
> >> system is ready we will have a new staging URL where we will regularly
> >> publish the content,
> >> so users can follow the progress.
> >>
> >> Because the new documentation will be in the source code and in ascii
> >> doc format, then its
> >> easier for Camel users to contrbute and help - you can simply just
> >> submit patches as GitHub PRs.
> >>
> >> Have patience with us, as it may take a couple of months for us to be
> >> ready to publish the staging URL.
> >>
> >> We anticipate to have a new website and documentation ready after the
> >> summer break of 2018.
> >>
> >> On Tue, Mar 6, 2018 at 10:48 AM, Claus Ibsen 
> >> wrote:
> >> > Hi
> >> >
> >> > I think we should post a news on the Camel front page about the
> >> > situation with the current old website and docs vs the new website and
> >> > docs from the source.
> >> >
> >> > A rough plan for the new website and docs could be
> >> >
> >> > - finish migrating the EIP docs
> >> > - create new TOC for new documentation
> >> > - copy over the good parts of the old docs for the new TOC and
> >> > otherwise write new parts from scratch (will be ongoing through 2018)
> >> > - build a new modern front page
> >> > - use the new Camel logo
> >> > - publish this to a new staging url so anyone can follow the work
> >> >
> >> > A work plan could be that after the 2.21 release we will finish the
> >> > EIP migrations and get started on the TOC and gradually build up the
> >> > new documentation. At the same time folks work on the new website with
> >> > a new build system for publishing that, and get the tech stuff in
> >> > order.
> >> >
> >> > The new front page is likely where many people may have feedback/ideas
> >> > and it can take some time to get right - if there are more proposals
> >> > we could run a vote etc. Also we need new content for:
> >> > - What is Apache Camel
> >> > - How to get started etc
> >> >
> >> > eg content for onboarding new users and getting them to quickly
> >> > understand what Camel is. That information is needed on both the front
> >> > page and some beginner pages.
> >> >
> >> > As we are all busy with other duties 

Re: [REVIEW] - Optimised toD for HTTP components

[Claus Ibsen]

On Wed, Apr 25, 2018 at 7:29 PM, Alex Dettinger  wrote:
> +1
>
> Great feature, it reminds me an issue years ago where I found a management
> context with tons of file endpoint mbeans.

The file component provides the fileName uri option using simple
expression today that is evaluated per exchange.
So the optimisation does not apply as much here. But it may be a bit
how you use the file component and how the file endpoint is defined.

For many JMX mbeans then Camel should only register mbeans for "static
endpoints" that are defined in routes during startup.
However you can configure Camel to always register, and therefore also
endpoints created dynamically later on.
Many many years ago it would create mbeans always.

But the starting directory is not a simple expression so if you have

from file:foo
   to file:bar

Then its 2 different endpoints.


> It makes me wonder if the file component would be a good candidate for this
> optimisation ?
>

Not as much. Also sometimes you may want to have more endpoints you
can see in JMX and others, eg

  to file:bar?fileName=backup/${}
  to file:bar?fileName=important/${}

Would be 2 different endpoints. But if the optimisation is done, then
it would be

  setHeader name=backup/${}
  to file:bar

  setHeader name=important/${}
  to file:bar

And there would be 1 endpoint  file:bar and you would not have
separated stats between the backup vs important endpoint.

The optimisation makes the most sense when its producer take up
resources such as a HTTP client / database connection / JMS connection
etc.
For light-weight java.io.File APIs then there is less gained.

But since its explicit only in use with toD then its a deliberate
choice by the Camel developer and it can make sense to have as many
optimisations as possible.

But for starters we should log a parent JIRA about optimisations for
other components. And then create sub JIRAs for each component we
would work on.


> Alex
>
> On Tue, Apr 24, 2018 at 12:30 PM, Claus Ibsen  wrote:
>
>> On Tue, Apr 24, 2018 at 11:43 AM, Bilgin Ibryam  wrote:
>> > + 1 for this improvement from me.
>> >
>> > toD is very commonly used expression, and while it is an improvement
>> > over recipientList, it has a serious drawback - creating new endpoints
>> > for every changed option...
>> >
>> > Only last week I had to use toD for querying Cassandra, and it quickly
>> > became obvious it is not practical as it was creating a new endpoint
>> > and a new connection to a Cassandra cluster of 5 even for a small
>> > query parameter change. You change would allow to reuse the connection
>> > (I understand this has to be added to Cassandra component first as
>> > well)  and dynamically build queries..gr8.
>> >
>>
>> Yes it would needed to be added specially per component that can
>> support such kind of optimisation.
>> For cassandra that would mean having a way of providing the dynamic
>> queries in headers.
>>
>>
>> > Bilgin
>> >
>> >
>> > On Mon, Apr 23, 2018 at 11:50 AM, Claus Ibsen 
>> wrote:
>> >> Hi
>> >>
>> >> We have ticket
>> >> https://issues.apache.org/jira/browse/CAMEL-12462
>> >>
>> >> Its an idea I had though about in the past, even before we had toD.
>> >> However I do think that the simplification toD gives Camel end users,
>> >> can warrant that we attempted to look at this again.
>> >>
>> >> In particular when you have HTTP endpoints that are dynamic (different
>> >> query parameters, context-path, etc) but calling to the same HTTP
>> >> server, then toD should ideally be optimised to deal with this
>> >> out-of-the-box. Today you end up with unique Camel endpoints per
>> >> unique combo computed from toD.
>> >>
>> >> So CAMEL-12462 optimised and resolved this. However it does this with
>> >> a little bit of complexity of parsing the computed endpoint uri to
>> >> resolve it into 3 parts
>> >>
>> >> - static base uri
>> >> - dynamic context-path
>> >> - dynamic query parameters
>> >>
>> >> Then it will use the static base url, as the Camel endpoint, and
>> >> therefore resolve into a single endpoint and Camel http producer. And
>> >> the dynamic parts are automatic provided in Camel headers that the
>> >> HTTP producer supports (HTTP_PATH and HTTP_QUERY).
>> >>
>> >> Anyway the PR has some docs and examples and more details in the
>> >> updated adoc file for toD, so take a look at that file.
>> >>
>> >> I implemented this with a way for components to support this by
>> >> providing a service locator file in the send-dynamic folder of
>> >> META-INF, eg same way we discover components. This way other
>> >> components can provide their own optimisation implementation in the
>> >> future. For example to other kinds of components like JMS, Kafka and
>> >> others.
>> >>
>> >> I wanted to give the community and other Camel committers a chance to
>> >> provide feedback, review, improve, etc - before we merged this into
>> >> the