Camel-Gora component

[Ioannis Polyzos]

Hi everyone,

The past few days I have worked towards creating a camel-gora component and
I would like to kindly contribute this work back to the community.

I came across the CAMEL-4817<https://issues.apache.org/jira/browse/CAMEL-4817>
issue which is about such a component and a patch with the source has been
attached in this thread.

For the feature used to deploy in karaf/fabric you can refer to
https://gist.github.com/ipolyzos/6a275c6ead89d1438f9f

Any comments and ideas toward improving the component would be very
appreciated.

P.S : The source also exist in github at
https://github.com/ipolyzos/camel-gora

best regards,

*Ioannis Polyzos**Principal Software Engineer / PhD Candidate*

[image: about.me] <http://about.me/ipolyzos> [image:
LinkedIn]<http://gr.linkedin.com/in/ipolyzos>
 [image: Twitter] <http://twitter.com/ominor>

 *PGP Key* :  4096R/B78DA9F1
*Fingerprint: * BDE3 AC14 43AA 8911 2E5A 7FD2 A970 1945 B78D A9F1

Camel-Kafka Component

[Ioannis Polyzos]

Hello all,

I was recently working on a *camel-kafka* component that I would like to
contribute back to the Apache Camel project.

 The component allows to configure the majority of the kafka client
parameters and to transfer both the body and the exchange.It definitely
need more work and therefore I would like to kindly ask for your feedback
on this early work.

* P.S You could find the source code
at https://github.com/ipolyzos/camel-kafka/
*

thank you and regards,
Ioannis

Re: Camel-Kafka Component

[Ioannis Polyzos]

Hi Claus,

 I would be more than happy to proceed with so.

  I will go through and proceed with the relevant changes in the next days.

thanks


On Sun, Mar 30, 2014 at 7:57 AM, Claus Ibsen  wrote:

> Hi
>
> We recently added a new camel-kafka component which was released in
> Camel 2.13.0.
> https://github.com/apache/camel/tree/master/components/camel-kafka
>
> You are welcome to help improve the existing component.
>
>
> On Sun, Mar 30, 2014 at 1:43 AM, Ioannis Polyzos 
> wrote:
> > Hello all,
> >
> > I was recently working on a *camel-kafka* component that I would like to
> > contribute back to the Apache Camel project.
> >
> >  The component allows to configure the majority of the kafka client
> > parameters and to transfer both the body and the exchange.It definitely
> > need more work and therefore I would like to kindly ask for your feedback
> > on this early work.
> >
> > * P.S You could find the source code
> > at https://github.com/ipolyzos/camel-kafka/
> > <https://github.com/ipolyzos/camel-kafka/>*
> >
> > thank you and regards,
> > Ioannis
>
>
>
> --
> Claus Ibsen
> -
> Red Hat, Inc.
> Email: cib...@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> Make your Camel applications look hawt, try: http://hawt.io
>

Re: Camel-Kafka Component

[Ioannis Polyzos]

Hi Richard,

 Thanks for your kind response, I will proceed adding documentation as for
CAMEL-7288 as well.

Thanks


On Sun, Mar 30, 2014 at 9:18 AM, Richard Kettelerij <
richardkettele...@gmail.com> wrote:

> As Claus mentioned it would be great if you could improve the recently
> added camel-kafka component (wherever possible).
>
> The new Kafka component also missing documentation (see
> https://issues.apache.org/jira/browse/CAMEL-7288), that would be also be
> much appreciated.
>
> Regards,
> Richard
> http://richardlog.com
>
>
> On Sun, Mar 30, 2014 at 1:43 AM, Ioannis Polyzos  >wrote:
>
> > Hello all,
> >
> > I was recently working on a *camel-kafka* component that I would like to
> > contribute back to the Apache Camel project.
> >
> >  The component allows to configure the majority of the kafka client
> > parameters and to transfer both the body and the exchange.It definitely
> > need more work and therefore I would like to kindly ask for your feedback
> > on this early work.
> >
> > * P.S You could find the source code
> > at https://github.com/ipolyzos/camel-kafka/
> > <https://github.com/ipolyzos/camel-kafka/>*
> >
> > thank you and regards,
> > Ioannis
> >
>

Re: Camel-Kafka Component

[Ioannis Polyzos]

Hi all,

 Based on our earlier discussion I have gone through and submitted a patch
for the camel-kafka component.

 The patch has been submitted in CAMEL-7339 (
https://issues.apache.org/jira/browse/CAMEL-7339) and I would like to
kindly ask your feedback on this.

 Among the the changes the patch introduce is in the syntax pattern of
kafka component. The current component implementation syntax is :

*   kafka:?topic=*

while in the proposed implementation is

kafka:




On Sun, Mar 30, 2014 at 10:05 AM, Ioannis Polyzos wrote:

> Hi Richard,
>
>  Thanks for your kind response, I will proceed adding documentation as for
> CAMEL-7288 as well.
>
> Thanks
>
>
> On Sun, Mar 30, 2014 at 9:18 AM, Richard Kettelerij <
> richardkettele...@gmail.com> wrote:
>
>> As Claus mentioned it would be great if you could improve the recently
>> added camel-kafka component (wherever possible).
>>
>> The new Kafka component also missing documentation (see
>> https://issues.apache.org/jira/browse/CAMEL-7288), that would be also be
>> much appreciated.
>>
>> Regards,
>> Richard
>> http://richardlog.com
>>
>>
>> On Sun, Mar 30, 2014 at 1:43 AM, Ioannis Polyzos > >wrote:
>>
>> > Hello all,
>> >
>> > I was recently working on a *camel-kafka* component that I would like to
>> > contribute back to the Apache Camel project.
>> >
>> >  The component allows to configure the majority of the kafka client
>> > parameters and to transfer both the body and the exchange.It definitely
>> > need more work and therefore I would like to kindly ask for your
>> feedback
>> > on this early work.
>> >
>> > * P.S You could find the source code
>> > at https://github.com/ipolyzos/camel-kafka/
>> > <https://github.com/ipolyzos/camel-kafka/>*
>> >
>> > thank you and regards,
>> > Ioannis
>> >
>>
>
>

Re: Camel-Kafka Component

[Ioannis Polyzos]

Hi all,

 Based on our earlier discussion I have gone through and submitted a patch
for the camel-kafka component.

 The patch has been submitted in CAMEL-7339 (
https://issues.apache.org/jira/browse/CAMEL-7339) and I would like to
kindly ask your feedback on this.

 Among the the changes the patch introduce is in the syntax pattern of
kafka component. The current component implementation syntax is :

*   kafka:?topic=*

while in the proposed implementation is

*kafka:  *


Another change is that by default data are not in the form of Strings*(i.e
KeyedMessage) *but in the form of byte arrays *(i.e
KeyedMessage)*. And finally allow for the transfer of the whole exchange by
using the *DefaultExchangeHolder*.

Cheers,
Ioannis


On Sun, Mar 30, 2014 at 10:05 AM, Ioannis Polyzos wrote:

> Hi Richard,
>
>  Thanks for your kind response, I will proceed adding documentation as for
> CAMEL-7288 as well.
>
> Thanks
>
>
> On Sun, Mar 30, 2014 at 9:18 AM, Richard Kettelerij <
> richardkettele...@gmail.com> wrote:
>
>> As Claus mentioned it would be great if you could improve the recently
>> added camel-kafka component (wherever possible).
>>
>> The new Kafka component also missing documentation (see
>> https://issues.apache.org/jira/browse/CAMEL-7288), that would be also be
>> much appreciated.
>>
>> Regards,
>> Richard
>> http://richardlog.com
>>
>>
>> On Sun, Mar 30, 2014 at 1:43 AM, Ioannis Polyzos > >wrote:
>>
>> > Hello all,
>> >
>> > I was recently working on a *camel-kafka* component that I would like to
>> > contribute back to the Apache Camel project.
>> >
>> >  The component allows to configure the majority of the kafka client
>> > parameters and to transfer both the body and the exchange.It definitely
>> > need more work and therefore I would like to kindly ask for your
>> feedback
>> > on this early work.
>> >
>> > * P.S You could find the source code
>> > at https://github.com/ipolyzos/camel-kafka/
>> > <https://github.com/ipolyzos/camel-kafka/>*
>> >
>> > thank you and regards,
>> > Ioannis
>> >
>>
>
>

Re: [VOTE] Release Apache Camel 3.4.0 with Spring Boot and Karaf Support Projects

[Ioannis Polyzos]

+1

On Tue, 16 Jun 2020, 09:12 Luca Burgazzoli,  wrote:

> +1 (binding)
>
> ---
> Luca Burgazzoli
>
>
> On Tue, Jun 16, 2020 at 7:10 AM Onder SEZGIN  wrote:
>
> > +1
> >
> > On Mon, 15 Jun 2020, 23:13 Federico Valeri, 
> wrote:
> >
> > > +1
> > >
> > > On Mon, Jun 15, 2020, 2:38 PM Michael Joyner  >
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Mon, Jun 15, 2020 at 4:53 AM Jean-Baptiste Onofre <
> j...@nanthrax.net>
> > > > wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > > Le 15 juin 2020 à 09:14, Gregor Zurowski <
> gre...@list.zurowski.org
> > >
> > > a
> > > > > écrit :
> > > > > >
> > > > > > Hi Everyone:
> > > > > >
> > > > > > This is a vote to release Apache Camel 3.4.0 (with Apache Camel
> > > Spring
> > > > > > Boot and Apache Camel Karaf), a new minor release with 118
> > > > > > improvements and fixes.
> > > > > >
> > > > > > Release notes:
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348216&projectId=12311220
> > > > > >
> > > > > > == Apache Camel 3.4.0 ==
> > > > > >
> > > > > > Staging repository:
> > > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1220/
> > > > > >
> > > > > > Tarballs:
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecamel-1220/org/apache/camel/apache-camel/3.4.0/
> > > > > >
> > > > > > Tag:
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel.git;a=tag;h=refs/tags/camel-3.4.0
> > > > > >
> > > > > > == Apache Camel Spring Boot 3.4.0 ==
> > > > > >
> > > > > > Staging repository:
> > > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1221/
> > > > > >
> > > > > > Tag:
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-spring-boot.git;a=tag;h=refs/tags/camel-spring-boot-3.4.0
> > > > > >
> > > > > > == Apache Camel Karaf 3.4.0 ==
> > > > > >
> > > > > > Staging repository:
> > > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1222/
> > > > > >
> > > > > > Tag:
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-karaf.git;a=tag;h=refs/tags/camel-karaf-3.4.0
> > > > > >
> > > > > > Please test this release candidate and cast your vote.
> > > > > > [ ] +1 Release the binary as Apache Camel, Camel Spring Boot and
> > > Camel
> > > > > > Karaf 3.4.0
> > > > > > [ ] -1 Veto the release (provide specific comments)
> > > > > >
> > > > > > The vote is open for at least 72 hours.
> > > > > >
> > > > > > Thanks,
> > > > > > Gregor
> > > > >
> > > > >
> > > >
> > > > --
> > > > --
> > > > Michael Joyner
> > > > Solutions Architect
> > > > SugarCRM
> > > >
> > > > mobile: (206)-288-3937
> > > > email: michaelwjoy...@gmail.com
> > > > ..
> > > >
> > >
> >
>

Re: [VOTE] Release Apache Camel-kafka-connector 0.3.0

[Ioannis Polyzos]

+1

On Wed, 17 Jun 2020, 13:40 Otavio Rodolfo Piske, 
wrote:

> +1
>
> On Wed, Jun 17, 2020 at 2:37 PM Andrea Cosentino 
> wrote:
>
> > +1 (binding)
> >
> > I don't think it is a problem to have a 0.3.0 release.
> >
> > We'll release a 0.4.0 based on 3.4.0 soon.
> >
> > Il giorno mer 17 giu 2020 alle ore 14:33 Andrea  ha
> > scritto:
> >
> > > Hello Omar,
> > >
> > > I think the intention is to have a 3.4.0 based release soon but it will
> > > take a little bit more time since 3.4.0 is a LTS release of camel so we
> > > need to be sure we have all it is needed in there.
> > >
> > > The effort is already been largely done for this release since all is
> > > staged it is just a matter of waiting for the vote to close and hit
> > publish
> > > on the apache nexus staging repo...
> > >
> > > On Wed, Jun 17, 2020, at 14:11, Omar Al-Safi wrote:
> > > > Hi Andrea,
> > > >
> > > > +1 (binding).
> > > >
> > > > However I have a question, would it make sense to hold on to the
> > release
> > > > few days and upgrade to Camel 3.4 on the same effort since the vote
> is
> > > > about to be over?
> > > >
> > > > Regards,
> > > > Omar
> > > >
> > > > On Wed, Jun 17, 2020 at 2:04 PM Andrea  wrote:
> > > >
> > > > > Hello all,
> > > > >
> > > > > This is a vote to release Apache Camel-kafka-connector 0.3.0
> > > > >
> > > > > Staging repository:
> > > > >
> > https://repository.apache.org/content/repositories/orgapachecamel-1223
> > > > >
> > > > > Tag:
> > > > >
> > > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=camel-kafka-connector.git;a=tag;h=refs/tags/camel-kafka-connector-0.3.0
> > > > >
> > > > > the main focus of this release has been in stabilizing and
> polishing
> > > the
> > > > > integration tests along with updating to camel-3.3.0.
> > > > >
> > > > > Please test this release candidate and cast your vote.
> > > > > [ ] +1 Release the binary as Apache Camel-kafka-connector 0.3.0
> > > > > [ ] -1 Veto the release (provide specific comments)
> > > > >
> > > > > The vote is open for at least 48 hours.
> > > > >
> > > > > Thanks,
> > > > > Andrea.
> > > > >
> > > >
> > >
> >
>
>
> --
> Otavio R. Piske
> http://orpiske.net
>

Re: [VOTE] Release Apache Camel K 1.0.1

[Ioannis Polyzos]

+1

On Fri, 26 Jun 2020, 06:56 Jean-Baptiste Onofre,  wrote:

> +1 (binding)
>
> Regards
> JB
>
> > Le 25 juin 2020 à 17:01, Nicola Ferraro  a écrit :
> >
> > Hello all:
> >
> > This is a vote to release Apache Camel K 1.0.1.
> >
> > This is a maintenance release that addresses some of the issues that have
> > been found on the 1.0.0 release. You can see more details in the release
> > notes: https://github.com/apache/camel-k/issues/1565#issue-645491033
> >
> > Camel K staging repository:
> https://dist.apache.org/repos/dist/dev/camel/
> > camel-k/1.0.1/
> > Camel K Tag:
> >
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/1.0.1
> >
> > 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.0.1 --olm=false
> >
> > Please test this release candidate and cast your vote.
> >
> > [ ] +1 Release the binary as Apache Camel K 1.0.1
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Thanks,
> > Nicola Ferraro
>
>

Re: [VOTE] Release Apache Camel K 1.1.0 and Runtime 1.4.1

[Ioannis Polyzos]

+1


*Ioannis Polyzos**Principal Architect*

[image: about.me] <http://about.me/ipolyzos> [image: LinkedIn]
<http://gr.linkedin.com/in/ipolyzos> [image: Twitter]
<http://twitter.com/ipolyzos>

*PGP Key* : 1EC0835C
*Fingerprint : * 8B63 BA1E EA95 D087 825C 0CC7 0253 B591 1EC0 835C


On Tue, Jul 21, 2020 at 8:27 PM Zoran Regvart  wrote:

> +1 (binding)
>
> thanks Nicola
>
> zoran
>
> On Tue, Jul 21, 2020 at 3:33 PM Nicola Ferraro 
> wrote:
> >
> > Hello all:
> >
> > This is a vote to release Apache Camel K 1.1.0 and Camel K Runtime 1.4.1.
> >
> > This is intended to be a stable release before major changes are added.
> > More details on the release notes:
> > https://github.com/apache/camel-k/issues/1618#issuecomment-661859438
> >
> > Runtime staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1235
> > Runtime Tag:
> >
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.4.1
> >
> > Camel K staging repository:
> > https://dist.apache.org/repos/dist/dev/camel/camel-k/1.1.0/
> > Camel K Tag:
> >
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.1.0
> >
> > 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.1.0 --maven-repository=
> > https://repository.apache.org/content/repositories/orgapachecamel-1235
> >  --olm=false
> >
> > Please test this release candidate and cast your vote.
> >
> > [ ] +1 Release the binary as Apache Camel K 1.1.0 and Apache Camel K
> Runtime
> > 1.4.1
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Thanks,
> > Nicola Ferraro
>
>
>
> --
> Zoran Regvart
>

Re: [VOTE] Release Apache Camel-kafka-connector 0.4.0

[Ioannis Polyzos]

+1

On Thu, 30 Jul 2020, 21:55 Zoran Regvart,  wrote:

> +1 (binding)
>
> Thanks Andrea!
>
> zoran
>
> On Thu, Jul 30, 2020 at 10:14 AM Andrea  wrote:
> >
> > Hello all,
> >
> > This is a vote to release Apache Camel-kafka-connector 0.4.0
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1236
> >
> > Tag:
> >
> https://gitbox.apache.org/repos/asf?p=camel-kafka-connector.git;a=tag;h=camel-kafka-connector-0.4.0
> >
> > This release is aligning to camel 3.4.x LTS and bringing in some new
> feature like support for aggregation and dataformats for both marshaling
> and unmarshaling in sink and sources.
> >
> > Please test this release candidate and cast your vote.
> > [ ] +1 Release the binary as  Apache Camel-kafka-connector 0.4.0
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 48 hours.
> >
> > Thanks,
> > Andrea.
>
>
>
> --
> Zoran Regvart
>

Re: Redesigning the Camel website front page

[Ioannis Polyzos]

+1

Very nice.

On Sat, 1 Aug 2020, 06:45 Otavio Rodolfo Piske, 
wrote:

> +1
>
> Looks very good!
>
> I also think that it would be more consistent to use "Camel Kafka
> Connector" instead of Camel Kafka. I'd also suggest the same for "Camel
> Core" as it can be potentially confusing, IMHO.
>
>
> On Fri, Jul 31, 2020 at 7:37 PM Federico Valeri 
> wrote:
>
> > +1
> >
> > Really cool.
> >
> > Minor note: shouldn't be "Camel Kafka Connector" on the front page,
> > like in the documentation page? As long as we are consistent, I don't
> > care if we choose the short or long version.
> >
> > On Fri, Jul 31, 2020 at 7:10 PM Djordje Bajić 
> > wrote:
> > >
> > > Hello Zoran,
> > >
> > > This looks great! Only thing that i noticed is that camel-kafka logo is
> > not
> > > visible enough since it's black, maybe add some background which will
> > > create contrast?
> > >
> > > Thank you on your time. :)
> > >
> > > - Djordje
> > >
> > > On Fri, 31 Jul 2020, 19:05 prerna singh, 
> > wrote:
> > >
> > > > This looks pretty good to me.
> > > > Good job done.
> > > >
> > > >
> > > > On Fri, 31 Jul 2020, 22:24 Zoran Regvart,  wrote:
> > > >
> > > > > Hi Cameleers,
> > > > > in the past few months we had a lot of help with the Camel website
> > > > > from two interns from the Outreachy program.
> > > > >
> > > > > We're now at a point where we're redesigning the website front page
> > > > > and we would like to hear some feedback from you. Take a look at
> the
> > > > > preview:
> > > > >
> > > > > https://deploy-preview-442--camel.netlify.app/
> > > > >
> > > > > And if you wish to provide some feedback chime in on the pull
> > request:
> > > > >
> > > > > https://github.com/apache/camel-website/pull/442
> > > > >
> > > > > thanks!
> > > > >
> > > > > zoran
> > > > > --
> > > > > Zoran Regvart
> > > > >
> > > >
> >
>
>
> --
> Otavio R. Piske
> http://orpiske.net
>

Re: [VOTE] Release Apache Camel Quarkus 1.0.0

[Ioannis Polyzos]

+1

On Wed, 12 Aug 2020, 06:45 Zheng Feng,  wrote:

> +1
>
> On Mon, Aug 10, 2020 at 7:19 PM Peter Palaga  wrote:
>
> > Hi,
> >
> > This is a vote to release Apache Camel Quarkus 1.0.0.
> >
> > Highlights:
> > * Based on LTS Camel 3.4.x
> > * Quarkus 1.7.0.Final
> > * Fixed issues:
> > https://github.com/apache/camel-quarkus/milestone/1?closed=1
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1238
> >
> >
> > Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=camel-quarkus.git;a=tag;h=c8be84fe0208ae87be32feeaa444c0caa4d19a38
> >
> > Source release package:
> >
> >
> https://repository.apache.org/service/local/repositories/orgapachecamel-1238/content/org/apache/camel/quarkus/camel-quarkus/1.0.0/camel-quarkus-1.0.0-src.zip
> >
> > Please test this release candidate and cast your vote.
> >
> > [ ] +1 Release the binary as Apache Camel Quarkus 1.0.0
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Many thanks to all contributors!
> >
> > -- Peter
> >
> >
>

Re: [VOTE] Switch from Gitter to Zulip as official Camel chatroom

[Ioannis Polyzos]

+1

On Mon, 31 Aug 2020, 07:45 Luca Burgazzoli,  wrote:

> Hi,
>
> This is a vote to switch the official Camel chatroom from Gitter [1] to
> Zulip [2].
>
> For detail about the reason for the switch and discussion about
> alternatives, please see the related thread on the @dev mailing list [3]. A
> Zulip test instance you can join using GitHub, GitLab, Google or plain mail
> is available [4], feel free to plain with it while the vote is open.
>
> [ ] +1 To switch from Gitter to Zulip
> [ ] -1 To Veto the switch (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Thank you for your participation,
> Luca
>
> [1] https://gitter.im
> [2] https://zulipchat.com/
> [3]
> https://mail-archives.apache.org/mod_mbox/camel-dev/202008.mbox/browser
> [4] https://camel-test.zulipchat.com
>
>
> ---
> Luca Burgazzoli
>

Re: [VOTE] Release Apache Camel K 1.2.0 and Runtime 1.5.0

[Ioannis Polyzos]

+1

On Fri, 9 Oct 2020, 08:55 Andrea Cosentino,  wrote:

> +1 (binding)
>
> Il gio 8 ott 2020, 19:36 Nicola Ferraro  ha scritto:
>
> > Hello all:
> >
> > This is a vote to release Apache Camel K 1.2.0 and Camel K Runtime 1.5.1.
> >
> > This release contains many changes in the runtime and includes many new
> > features, such as support for Kamelets. More details on the changelog:
> > https://github.com/apache/camel-k/blob/master/CHANGELOG.md#unreleased
> >
> > Runtime staging repository:
> > https://repository.apache.org/content/repositories/orgapachecamel-1251
> > Runtime Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=camel-k-runtime.git;a=shortlog;h=refs/tags/camel-k-runtime-parent-1.5.0
> >
> > Camel K staging repository:
> > https://dist.apache.org/repos/dist/dev/camel/camel-k/1.2.0/
> > Camel K Tag:
> >
> >
> https://gitbox.apache.org/repos/asf?p=camel-k.git;a=shortlog;h=refs/tags/v1.2.0
> >
> > 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.2.0 --maven-repository=
> > https://repository.apache.org/content/repositories/orgapachecamel-1251
> >  --olm=false
> >
> > Please test this release candidate and cast your vote.
> >
> > [ ] +1 Release the binary as Apache Camel K 1.2.0 and Apache Camel K
> > Runtime
> > 1.5.0
> > [ ] -1 Veto the release (provide specific comments)
> >
> > The vote is open for at least 72 hours.
> >
> > Thanks,
> > Nicola Ferraro
> >
>

[jira] [Commented] (CAMEL-4055) Hazelcast should use CamelCase keys for its headers

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053930#comment-13053930
 ] 

Ioannis Polyzos commented on CAMEL-4055:


 Claus sorry for the misunderstanding, my fault, I thought it was just camel 
case, I didn't catch that should start with "Camel"...

 Ashwin thank alot for your help, please let me know if your like me to proceed 
with any further changes ... 

> Hazelcast should use CamelCase keys for its headers
> ---
>
> Key: CAMEL-4055
> URL: https://issues.apache.org/jira/browse/CAMEL-4055
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-hazelcast
>Affects Versions: 2.7.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.9.0
>
> Attachments: CAMEL-4055.patch
>
>
> Its an idiom that Camel components that supports headers to control its 
> actions should use CamelCase for its keys, eg CamelHazelcastOperation. 
> Also it would be great that if camel-hazelcast would remove the control 
> headers after usage, eg operation type and objectId. Then those headers is 
> not propagated during route as they was only intended as input for the 
> hazelcast endpoint.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

New component: camel-hzlq
-

 Key: CAMEL-3590
 URL: https://issues.apache.org/jira/browse/CAMEL-3590
 Project: Camel
  Issue Type: New Feature
Affects Versions: 2.7.0
Reporter: Ioannis Polyzos
Priority: Minor


 I am submitting this component for your review and consideration for its 
addition as an official Camel component...

 HzlQ component implements a work-queue on top of the Hazelcast in-memory 
data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
to the core "SEDA" component. By making use of Hazelcast's implementation of 
BlockingQueue, it allows the system to scale across multiple machines with 
minimal or no configuration while the replication features provided increase 
reliability and fault-tolerance.

For more information on Hazelcast please refer to : http://www.hazelcast.com/.

(Hazelcast is released under Apache 2.0 License)



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: camel-hzlq-20110126.tar.gz
camel-hzlq-20110126.patch

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
> Attachments: camel-hzlq-20110126.patch, camel-hzlq-20110126.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986829#action_12986829
 ] 

Ioannis Polyzos commented on CAMEL-3590:


Hi Richard, 

 Thank  you very much for the feedback it is very appreciated.

 I have gone through the changes you suggested (very good points) and a new 
patch is attached. In the new patch the pool interval is configurable through 
the "poolInterval" parameter and the consumer make use of the 
ExecutorServiceStrategy.

 Regarding the name, indeed,  I have chosen this name because the component 
uses only a subset of the Hazelcast data structures. To be more specific it 
uses only the BlockingQueue implementation. Though I wouldn't mind at all to 
rename the project if you believe that another name would be more apropriate.

  





> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>Reporter: Ioannis Polyzos
>Priority: Minor
> Attachments: camel-hzlq-20110126.patch, camel-hzlq-20110126.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: camel-hzlq-20110126-2.tar.gz
camel-hzlq-20110126-2.patch

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
> Attachments: camel-hzlq-20110126-2.patch, 
> camel-hzlq-20110126-2.tar.gz, camel-hzlq-20110126.patch, 
> camel-hzlq-20110126.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: (was: camel-hzlq-20110126.tar.gz)

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
> Attachments: camel-hzlq-20110126-2.patch, camel-hzlq-20110126-2.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: (was: camel-hzlq-20110126.patch)

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
> Attachments: camel-hzlq-20110126-2.patch, camel-hzlq-20110126-2.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: (was: camel-hzlq-20110126-2.patch)

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: (was: camel-hzlq-20110126-2.tar.gz)

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: camel-hzlq-20110126-3.tar.gz
camel-hzlq-20110126-3.patch

fix pool/poll typo...

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
> Attachments: camel-hzlq-20110126-3.patch, camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: camel-hazelcast-20110205.tar.gz
camel-hazelcast-20110205.patch

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>        Reporter: Ioannis Polyzos
>Priority: Minor
> Fix For: 2.7.0
>
> Attachments: camel-hazelcast-20110205.patch, 
> camel-hazelcast-20110205.tar.gz, camel-hzlq-20110126-3.patch, 
> camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990972#comment-12990972
 ] 

Ioannis Polyzos commented on CAMEL-3590:


Hi Handrian, 

 Thanks for your feedback ...

 Following your suggestions  I have renamed the component into camel-hazelcast 
and I have uploaded a new patch.

 Also I have put the code into github for easier access, you can check for the 
latest updates @ https://github.com/ipolyzos/camel-hazelcast

 
 

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>    Reporter: Ioannis Polyzos
>Priority: Minor
> Fix For: 2.7.0
>
> Attachments: camel-hazelcast-20110205.patch, 
> camel-hazelcast-20110205.tar.gz, camel-hzlq-20110126-3.patch, 
> camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990972#comment-12990972
 ] 

Ioannis Polyzos edited comment on CAMEL-3590 at 2/5/11 12:37 PM:
-

Hi Hadrian, 

 Thanks for your feedback ...

 Following your suggestions  I have renamed the component into camel-hazelcast 
and I have uploaded a new patch.

 Also I have put the code into github for easier access, you can check for the 
latest updates @ https://github.com/ipolyzos/camel-hazelcast


  was (Author: omicron):
Hi Handrian, 

 Thanks for your feedback ...

 Following your suggestions  I have renamed the component into camel-hazelcast 
and I have uploaded a new patch.

 Also I have put the code into github for easier access, you can check for the 
latest updates @ https://github.com/ipolyzos/camel-hazelcast

 
 
  
> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>    Reporter: Ioannis Polyzos
>Priority: Minor
> Fix For: 2.7.0
>
> Attachments: camel-hazelcast-20110205.patch, 
> camel-hazelcast-20110205.tar.gz, camel-hzlq-20110126-3.patch, 
> camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990972#comment-12990972
 ] 

Ioannis Polyzos edited comment on CAMEL-3590 at 2/5/11 12:38 PM:
-

Hi Hadrian, 

 Thanks for your feedback ...

 Following your suggestion  I have renamed the component into camel-hazelcast 
and I have uploaded a new patch.

 Also I have put the code into github for easier access, you can check for the 
latest updates @ https://github.com/ipolyzos/camel-hazelcast


  was (Author: omicron):
Hi Hadrian, 

 Thanks for your feedback ...

 Following your suggestions  I have renamed the component into camel-hazelcast 
and I have uploaded a new patch.

 Also I have put the code into github for easier access, you can check for the 
latest updates @ https://github.com/ipolyzos/camel-hazelcast

  
> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.7.0
>    Reporter: Ioannis Polyzos
>Priority: Minor
> Fix For: 2.7.0
>
> Attachments: camel-hazelcast-20110205.patch, 
> camel-hazelcast-20110205.tar.gz, camel-hzlq-20110126-3.patch, 
> camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3590:
---

Attachment: camel-hazelcast-20110225.zip
camel-hazelcast-20110225.diff

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>    Reporter: Ioannis Polyzos
> Fix For: 2.8.0
>
> Attachments: camel-hazelcast-20110205.patch, 
> camel-hazelcast-20110205.tar.gz, camel-hazelcast-20110225.diff, 
> camel-hazelcast-20110225.zip, camel-hzlq-20110126-3.patch, 
> camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (CAMEL-3590) New component: camel-hzlq

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999746#comment-12999746
 ] 

Ioannis Polyzos commented on CAMEL-3590:


 Hi Claus, 

 Sorry for the delay submitting the source code.

 I submit here the latest version of the camel-hazelcast component source 
(joined work with Claus) along with a patch containing also the required 
changes in camel features.

> New component: camel-hzlq
> -
>
> Key: CAMEL-3590
> URL: https://issues.apache.org/jira/browse/CAMEL-3590
> Project: Camel
>  Issue Type: New Feature
>        Reporter: Ioannis Polyzos
> Fix For: 2.8.0
>
> Attachments: camel-hazelcast-20110205.patch, 
> camel-hazelcast-20110205.tar.gz, camel-hazelcast-20110225.diff, 
> camel-hazelcast-20110225.zip, camel-hzlq-20110126-3.patch, 
> camel-hzlq-20110126-3.tar.gz
>
>
>  I am submitting this component for your review and consideration for its 
> addition as an official Camel component...
>  HzlQ component implements a work-queue on top of the Hazelcast in-memory 
> data-grid. Its purpose is to support asynchronous SEDA architectures, similar 
> to the core "SEDA" component. By making use of Hazelcast's implementation of 
> BlockingQueue, it allows the system to scale across multiple machines with 
> minimal or no configuration while the replication features provided increase 
> reliability and fault-tolerance.
> For more information on Hazelcast please refer to : http://www.hazelcast.com/.
> (Hazelcast is released under Apache 2.0 License)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041181#comment-13041181
 ] 

Ioannis Polyzos commented on CAMEL-3983:


Indeed the current implementation of Hazelcast SEDA component transfers only 
the body of the exchange.

To my humble opinion  it might be better to make use of the 
*DefaultExchangeHolder* in order to send the whole exchange as a serialized 
object.

more on *DefaultExchangeHolder* can be found on 
*http://camel.apache.org/maven/camel-2.7.0/camel-core/apidocs/org/apache/camel/impl/DefaultExchangeHolder.html*

I will prepare a proof-of-concept patch for your consideration later today... 

> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3983:
---

Attachment: SEDA-CAMEL-3983.patch

 @Claus.S your solution is very nice and elegant, however I agree with @Claus.I 
that it would not be a good idea to take a different path that the rest of the 
remoting components and magically marshal objects that are not serializable.

  From a quick grep in the components source base I saw that 
*DefaultExchangeHolder* is widely used from several components e.g mina, jms ,  
netty and others, and I believe it would be good solution.

 I attach here a patch with a POC test case for your consideration.

> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983.patch, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041567#comment-13041567
 ] 

Ioannis Polyzos commented on CAMEL-3983:


 Hi Claus.S , 

 I saw in your last patch that you introduce a new object called 
_HazelcastMessage_ that wraps the body and header of the exchange and send both 
of them through the wire. To my understanding this is the purpose of 
_DefaultExchangeHolder_ object (plus additional info of the exchange like fault 
headers etc) . 

 Is there any specific reason used a second object to wrap headers and body ?

 Also  according to the documentation in 
http://camel.apache.org/maven/camel-2.7.0/camel-core/apidocs/org/apache/camel/impl/DefaultExchangeHolder.html
 , either the whole exchange should be transferred (transferExchange=true) or 
just the body of the message (normal usage).
 
 Please excuse me if my understanding is not correct, though I believe that it 
would be better to comply with this and in case of normal use 
(transferExchange=false) only the body should be send and no other 
information...

> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983.patch, hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-3983:
---

Attachment: SEDA-CAMEL-3983-2.patch

 I would agree with Claus.I. JMS is a different scenario than ours and would be 
reasonable to transfer specific headers in JMS due to the spec.

 Components like netty and mina that are closer to our case follow the 
aforementioned convention and transfer either the whole exchange or only the 
body (please refer to the payload helpers of the components for more info).

 I attach a new patch with the changes discussed earlier for your consideration.

> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983-2.patch, SEDA-CAMEL-3983.patch, 
> hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042019#comment-13042019
 ] 

Ioannis Polyzos commented on CAMEL-3983:


 To my humble opinion, I think that the component should follow what is 
described in the javadoc of the DefaultExchangeHolder, and make the transfer of 
header and other information optional. To be more specific by default to 
exchange only the body of the message and give the ability to exchange the 
whole exchange (with headers and other info) with the use of 
transferExchange=true option.

 The reason of this is mainly flexibility and compliance. To be more specific, 
if we make the exchange of headers the default case and mandatory with the use 
of DefaultExchangeHolder the whole route flow is tighten to camel. And in case 
we make it mandatory and default through the use of a custom component, the 
flow is tighten specifically to the camel-hazelcast component.
 
 In such cases we come to what Claus.S described earlier and any third party 
system that may want for example to participate to this flow e.g by using the 
queue or by registering any listeners to this queue it will have to  import and 
use of the camel libraries and be obligated to use either our custom wrapper or 
DefaultExchangeHolder.
 
 Also I believe that we should treat all the component uniformly as for 
external communication (in the same way we have worked with the other 
components) in order to ensure interoperability and compliance between the 
camel-hazelcast components. For example the case one wants to register a 
listener in the queue used from a SEDA component for statistics by using the 
hezelcast:queue component.

 



> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983-2.patch, SEDA-CAMEL-3983.patch, 
> hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042019#comment-13042019
 ] 

Ioannis Polyzos edited comment on CAMEL-3983 at 6/1/11 7:25 AM:


 To my humble opinion, I think that the component should follow what is 
described in the javadoc of the DefaultExchangeHolder, and make the transfer of 
header and other information optional. To be more specific by default to 
exchange only the body of the message and give the ability to exchange the 
whole exchange (with headers and other info) with the use of 
transferExchange=true option.

 The reason of this is mainly flexibility and compliance. To be more specific, 
if we make the exchange of headers the default case and mandatory with the use 
of DefaultExchangeHolder the whole route flow is tighten to camel. And in case 
we make it mandatory and default through the use of a custom component, the 
flow is tighten specifically to the camel-hazelcast component.
 
 In such cases we come to what Claus.I described earlier and any third party 
system that may want for example to participate to this flow e.g by using the 
queue or by registering any listeners to this queue it will have to  import and 
use of the camel libraries and be obligated to use either our custom wrapper or 
DefaultExchangeHolder.
 
 Also I believe that we should treat all the component uniformly as for 
external communication (in the same way we have worked with the other 
components) in order to ensure interoperability and compliance between the 
camel-hazelcast components. For example the case one wants to register a 
listener in the queue used from a SEDA component for statistics by using the 
hezelcast:queue component.

 



  was (Author: omicron):
 To my humble opinion, I think that the component should follow what is 
described in the javadoc of the DefaultExchangeHolder, and make the transfer of 
header and other information optional. To be more specific by default to 
exchange only the body of the message and give the ability to exchange the 
whole exchange (with headers and other info) with the use of 
transferExchange=true option.

 The reason of this is mainly flexibility and compliance. To be more specific, 
if we make the exchange of headers the default case and mandatory with the use 
of DefaultExchangeHolder the whole route flow is tighten to camel. And in case 
we make it mandatory and default through the use of a custom component, the 
flow is tighten specifically to the camel-hazelcast component.
 
 In such cases we come to what Claus.S described earlier and any third party 
system that may want for example to participate to this flow e.g by using the 
queue or by registering any listeners to this queue it will have to  import and 
use of the camel libraries and be obligated to use either our custom wrapper or 
DefaultExchangeHolder.
 
 Also I believe that we should treat all the component uniformly as for 
external communication (in the same way we have worked with the other 
components) in order to ensure interoperability and compliance between the 
camel-hazelcast components. For example the case one wants to register a 
listener in the queue used from a SEDA component for statistics by using the 
hezelcast:queue component.

 


  
> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983-2.patch, SEDA-CAMEL-3983.patch, 
> hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042390#comment-13042390
 ] 

Ioannis Polyzos commented on CAMEL-3983:


 The queue consumers register hazelcast listeners and are get notified upon 
events on the queue, such as addition of an item. In the scenario that we have 
5 consumers listening on a queue with the use of a listener, upon addition of a 
new item all of them will be notified and react upon the very same event while 
the data will remain on the queue.

 On the other hand SEDA component implements a work queue and focus on 
distributing of tasks to different consumers. Unlike the case of queue 
consumers that make use of listeners, SEDA make use of the poll() method on the 
queue which means that will remove and return the head of the queue. Every item 
on the queue will retrieved by only one consumer and then it will be deleted.

 It works in the same way as the plain SEDA component but by using the 
hazelcast underneath, distribution can scale not only cross threads but it can 
scale cross different machines

> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983-2.patch, SEDA-CAMEL-3983.patch, 
> hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042642#comment-13042642
 ] 

Ioannis Polyzos commented on CAMEL-3983:



 Earlier I have not described the SEDA architecture but how the SEDA 
*component* works, and I have noted that works like a *work queue*.
 
 What I have stated as a difference is that in case someone use the 
hazelcast:queue, an event will broadcast to all consumers, while in the case of 
hazelcast:seda only to one.

 It is very reasonable that your example does not work because in the current 
implementation does not transfer headers, and this is what the patch 
SEDA-CAMEL-3983-2.patch provide. But even in the case you have used this code 
you have note used the "transferExchange" option. If you please refer to the 
test cases of patch for examples on usage...

  

> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983-2.patch, SEDA-CAMEL-3983.patch, 
> hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CAMEL-3983) Added Support for Serialization and Message Headers to Hazelcast SEDA functionality

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043238#comment-13043238
 ] 

Ioannis Polyzos commented on CAMEL-3983:


 I agree, indeed this discussion may never end, and as both solutions exist in 
this thread,  camel committers can choose.

 My argument is on making transfer of headers etc mandatory. I work in a case 
that an external component works like an agent and register a listener to a 
queue used by SEDA component in order to gather statistics.

  I believe that this case even though is not so common would be of use by some 
users and would be not a good idea to tightly couple a queue with the 
camel-seda component and therefore leave this functionality optional.

 :D 


> Added Support for Serialization and Message Headers to Hazelcast SEDA 
> functionality
> ---
>
> Key: CAMEL-3983
> URL: https://issues.apache.org/jira/browse/CAMEL-3983
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hazelcast
>Affects Versions: 2.8.0
>Reporter: Claus Straube
> Fix For: Future
>
> Attachments: SEDA-CAMEL-3983-2.patch, SEDA-CAMEL-3983.patch, 
> hazelcast_seda_headers_04.diff, 
> hazelcast_seda_serialization_and_headers_01.diff, 
> hazelcast_seda_serialization_and_headers_02.diff, 
> hazelcast_seda_serialization_and_headers_03.diff
>
>
> The current implementation looses headers that are given to a 
> 'hazelcast:seda:foo' route and is has problems serializing complex objects 
> inside body that are not serializable. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CAMEL-4055) Hazelcast should use CamelCase keys for its headers

[Ioannis Polyzos (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ioannis Polyzos updated CAMEL-4055:
---

Attachment: CAMEL-4055.patch

I have uploaded a patch containing the aforementioned changes for your 
consideration.

 Names changed to camel case to comply with the idiom you previously mentioned. 
Regarding the removal of control headers i.e operation type and object id, are 
already already removed during the copyHeaders() call for Queue, Map, MultiMap, 
List and AtomicNumbers. In SEDA component these headers kept only in case 
transferExchange is set to true.

 
  


> Hazelcast should use CamelCase keys for its headers
> ---
>
> Key: CAMEL-4055
> URL: https://issues.apache.org/jira/browse/CAMEL-4055
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-hazelcast
>Affects Versions: 2.7.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.9.0
>
> Attachments: CAMEL-4055.patch
>
>
> Its an idiom that Camel components that supports headers to control its 
> actions should use CamelCase for its keys, eg CamelHazelcastOperation. 
> Also it would be great that if camel-hazelcast would remove the control 
> headers after usage, eg operation type and objectId. Then those headers is 
> not propagated during route as they was only intended as input for the 
> hazelcast endpoint.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (CAMEL-4055) Hazelcast should use CamelCase keys for its headers

[Ioannis Polyzos (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045062#comment-13045062
 ] 

Ioannis Polyzos edited comment on CAMEL-4055 at 6/6/11 8:13 PM:


I have uploaded a patch containing the aforementioned changes for your 
consideration.

 Names changed to camel case to comply with the idiom you previously mentioned. 
Regarding the removal of control headers i.e operation type and object id, are 
already removed during the copyHeaders() call for Queue, Map, MultiMap, List 
and AtomicNumbers. In SEDA component these headers kept only in case 
transferExchange is set to true.

 
  


  was (Author: omicron):
I have uploaded a patch containing the aforementioned changes for your 
consideration.

 Names changed to camel case to comply with the idiom you previously mentioned. 
Regarding the removal of control headers i.e operation type and object id, are 
already already removed during the copyHeaders() call for Queue, Map, MultiMap, 
List and AtomicNumbers. In SEDA component these headers kept only in case 
transferExchange is set to true.

 
  

  
> Hazelcast should use CamelCase keys for its headers
> ---
>
> Key: CAMEL-4055
> URL: https://issues.apache.org/jira/browse/CAMEL-4055
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-hazelcast
>Affects Versions: 2.7.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.9.0
>
> Attachments: CAMEL-4055.patch
>
>
> Its an idiom that Camel components that supports headers to control its 
> actions should use CamelCase for its keys, eg CamelHazelcastOperation. 
> Also it would be great that if camel-hazelcast would remove the control 
> headers after usage, eg operation type and objectId. Then those headers is 
> not propagated during route as they was only intended as input for the 
> hazelcast endpoint.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira