[jira] [Updated] (CAMEL-15774) [Website] suppress warnings for unimplemented camel-quarkus components; upgrade to Antora 3.0.0-alpha.1

2020-10-29 Thread Dmitry Volodin (Jira)


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

Dmitry Volodin updated CAMEL-15774:
---
Component/s: website

> [Website] suppress warnings for unimplemented camel-quarkus components; 
> upgrade to Antora 3.0.0-alpha.1
> ---
>
> Key: CAMEL-15774
> URL: https://issues.apache.org/jira/browse/CAMEL-15774
> Project: Camel
>  Issue Type: Bug
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> With Antora 3.0.0-alpha.1, include:: instructions can suppress "asciidoctor: 
> ERROR: atlasmap-component.adoc: line 11: include target not found: ..." 
> errors by including 
> [opts=optional].  This modifies tooling to include this in the generated 
> includes for cq bits, updates the generated files correspondingly, and 
> upgrades the Antora version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15773) (website) Workaround xref-validator bogus errors

2020-10-29 Thread Dmitry Volodin (Jira)


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

Dmitry Volodin updated CAMEL-15773:
---
Component/s: (was: came-core)
 website

> (website) Workaround xref-validator bogus errors
> 
>
> Key: CAMEL-15773
> URL: https://issues.apache.org/jira/browse/CAMEL-15773
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> The recent change to the Antora xref-validator to validate nav files is 
> useful but bogus as it reclassifies nav files as pages, breaking the index 
> extension used to generate tables.
> We can work around this by explicitly excluding nav files from the indexTable 
> macro.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15094) Create an Endpoint DSL archetype

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-15094:
-

Yes correct

> Create an Endpoint DSL archetype
> 
>
> Key: CAMEL-15094
> URL: https://issues.apache.org/jira/browse/CAMEL-15094
> Project: Camel
>  Issue Type: Task
>  Components: tooling
>Reporter: Andrea Cosentino
>Priority: Major
>  Labels: help-wanted
> Fix For: 3.x
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15774) [Website] suppress warnings for unimplemented camel-quarkus components; upgrade to Antora 3.0.0-alpha.1

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-15774:


djencks opened a new pull request #495:
URL: https://github.com/apache/camel-website/pull/495


   actual Antora version upgrade.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Website] suppress warnings for unimplemented camel-quarkus components; 
> upgrade to Antora 3.0.0-alpha.1
> ---
>
> Key: CAMEL-15774
> URL: https://issues.apache.org/jira/browse/CAMEL-15774
> Project: Camel
>  Issue Type: Bug
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> With Antora 3.0.0-alpha.1, include:: instructions can suppress "asciidoctor: 
> ERROR: atlasmap-component.adoc: line 11: include target not found: ..." 
> errors by including 
> [opts=optional].  This modifies tooling to include this in the generated 
> includes for cq bits, updates the generated files correspondingly, and 
> upgrades the Antora version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15773) (website) Workaround xref-validator bogus errors

2020-10-29 Thread David Jencks (Jira)


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

David Jencks resolved CAMEL-15773.
--
Resolution: Fixed

> (website) Workaround xref-validator bogus errors
> 
>
> Key: CAMEL-15773
> URL: https://issues.apache.org/jira/browse/CAMEL-15773
> Project: Camel
>  Issue Type: Task
>  Components: came-core
>Reporter: David Jencks
>Assignee: David Jencks
>Priority: Major
>
> The recent change to the Antora xref-validator to validate nav files is 
> useful but bogus as it reclassifies nav files as pages, breaking the index 
> extension used to generate tables.
> We can work around this by explicitly excluding nav files from the indexTable 
> macro.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15774) [Website] suppress warnings for unimplemented camel-quarkus components; upgrade to Antora 3.0.0-alpha.1

2020-10-29 Thread David Jencks (Jira)
David Jencks created CAMEL-15774:


 Summary: [Website] suppress warnings for unimplemented 
camel-quarkus components; upgrade to Antora 3.0.0-alpha.1
 Key: CAMEL-15774
 URL: https://issues.apache.org/jira/browse/CAMEL-15774
 Project: Camel
  Issue Type: Bug
Reporter: David Jencks
Assignee: David Jencks


With Antora 3.0.0-alpha.1, include:: instructions can suppress "asciidoctor: 
ERROR: atlasmap-component.adoc: line 11: include target not found: ..." errors 
by including 

[opts=optional].  This modifies tooling to include this in the generated 
includes for cq bits, updates the generated files correspondingly, and upgrades 
the Antora version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-14682:


djencks edited a comment on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-719052913


   It's unnecessary to revert the xref validator version, we can change the 
filter in the indexTable macro. Issue and PRs on its way.
   See https://issues.apache.org/jira/browse/CAMEL-15773



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15773) (website) Workaround xref-validator bogus errors

2020-10-29 Thread David Jencks (Jira)
David Jencks created CAMEL-15773:


 Summary: (website) Workaround xref-validator bogus errors
 Key: CAMEL-15773
 URL: https://issues.apache.org/jira/browse/CAMEL-15773
 Project: Camel
  Issue Type: Task
  Components: came-core
Reporter: David Jencks
Assignee: David Jencks


The recent change to the Antora xref-validator to validate nav files is useful 
but bogus as it reclassifies nav files as pages, breaking the index extension 
used to generate tables.

We can work around this by explicitly excluding nav files from the indexTable 
macro.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-14682:


djencks commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-719052913


   It's unnecessary to revert the xref validator version, we can change the 
filter in the indexTable macro. Issue and PRs on its way.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15094) Create an Endpoint DSL archetype

2020-10-29 Thread Praveen Kottarathil (Jira)


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

Praveen Kottarathil commented on CAMEL-15094:
-

I am picking this up.
I noticed that [~acosentino] recently moved springboot & karaf archetype to 
their respective projects. Since endpoint DSL is a part of Camel core, planning 
to keep this under `camel/archetypes`, just like `camel-archetype-java`. Is 
this alright?

> Create an Endpoint DSL archetype
> 
>
> Key: CAMEL-15094
> URL: https://issues.apache.org/jira/browse/CAMEL-15094
> Project: Camel
>  Issue Type: Task
>  Components: tooling
>Reporter: Andrea Cosentino
>Priority: Major
>  Labels: help-wanted
> Fix For: 3.x
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 8:43 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source 
code *DONE*
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*
TODO: sort so methods with deepest class level is first so we match the most 
concrete from the beginning *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source 
code *DONE*
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*
TODO: sort so methods with deepest class level is first so we match the most 
concrete from the beginning

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15770) Kafka serialize/deserialize properties are inconsistently named

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino commented on CAMEL-15770:
--

On the camel side this is done. I need to do more work on SB and examples 
around. Also add some migration and update documentation. The codebase in main 
camel is done.

> Kafka serialize/deserialize properties are inconsistently named
> ---
>
> Key: CAMEL-15770
> URL: https://issues.apache.org/jira/browse/CAMEL-15770
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-kafka, documentation
>Affects Versions: 3.6.0
>Reporter: Franky Georg
>Assignee: Andrea Cosentino
>Priority: Minor
>  Labels: breaking
> Fix For: 3.7.0
>
>
> There are 3 pairs of serializer/deserialiser properties on the Kafka 
> component.
> The inconsistent parts of the names are highlighted
>  
> ||Consumer||Producer||Type||
> |*kafka*HeaderDeserializer|*kafka*HeaderSerializer|Bean|
> |keyDeserializer|keySerializer*Class*|String FQN|
> |*value*Deserializer|serializer*Class*|String FQN|
>  
> I think it would be worth making these names consistent.
> ||Current||Proposed||
> |kafkaHeaderDeserializer|headerDeserializer|
> |kafkaHeaderSerializer|headerSerializer|
> |keyDeserializer|keyDeserializer |
> |keySerializerClass|keySerializer|
> |valueDeserializer|valueDeserializer|
> |serializerClass|valueSerializer|
> It looks like there was an intent to denote the key- and value- properties as 
> expecting a class FQN string by appending 'Class' to the name. I don't see 
> any other properties that do this so I think the consistent approach is to 
> leave it off.
> I've made an assumption that valueDeserializer & serializerClass are a pair, 
> as the descriptions don't match. It would be good to take the opportunity to 
> make all six descriptions consistent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 6:53 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source 
code *DONE*
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*
TODO: sort so methods with deepest class level is first so we match the most 
concrete from the beginning


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source 
code *DONE*
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 6:44 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source 
code *DONE*
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15772) camel-pulsar - should support readCompacted configuration

2020-10-29 Thread Ludovic Boutros (Jira)


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

Ludovic Boutros commented on CAMEL-15772:
-

Yes :) PR available. 

> camel-pulsar - should support readCompacted configuration
> -
>
> Key: CAMEL-15772
> URL: https://issues.apache.org/jira/browse/CAMEL-15772
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-pulsar
>Affects Versions: 3.6.0
>Reporter: Ludovic Boutros
>Priority: Major
> Fix For: 3.7.0
>
>
> In order to read compacted topics, the component (consumer) should support 
> the _readCompacted_ option.
> [readCompacted 
> documentation|https://pulsar.apache.org/docs/en/cookbooks-compaction/#java] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15764) Twilo camel case endpoint URI options leads to reflective property binding

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-15764:

Fix Version/s: 3.7.0

> Twilo camel case endpoint URI options leads to reflective property binding
> --
>
> Key: CAMEL-15764
> URL: https://issues.apache.org/jira/browse/CAMEL-15764
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-twilio
>Affects Versions: 3.6.0
>Reporter: James Netherton
>Priority: Minor
> Fix For: 3.7.0
>
>
> I noticed some inconsistency when adding native support for Twilio in Camel 
> Quarkus. 
> Consider the following URI:
> twilio://incoming-phone-number/create?phoneNumber=RAW(+15005550006)
> Turns out that this leads to the phoneNumber property binding being done 
> reflectively instead of via the configurer.
> This problem is that ignoreCase is always false here:
> https://github.com/apache/camel/blob/master/components/camel-twilio/src/generated/java/org/apache/camel/component/twilio/IncomingPhoneNumberEndpointConfigurationConfigurer.java#L33
> Hence the case logic attempts to match on the exact parameter name, and there 
> is no case block for the camel cased 'phoneNumber'.
> The obvious workaround is to name the URI param 'phonenumber' or 
> 'PhoneNumber' but the camel-twilio docs all refer to camel cased parameter 
> names.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15769) Ability to disable tokenization on jsonpath split returning a single element as string

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-15769:
-

Scott you are very welcome to help work on this. And if you could add an unit 
test in the PR that would be great

> Ability to disable tokenization on jsonpath split returning a single element 
> as string
> --
>
> Key: CAMEL-15769
> URL: https://issues.apache.org/jira/browse/CAMEL-15769
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-base
>Affects Versions: 3.4.0
>Reporter: Scott Carrier
>Priority: Minor
> Fix For: 3.7.0
>
>
> *Sample json message body:*
> { "text": \{ "div": "some, text" } }
> *DSL*
> .split(jsonpath("text.div"))
> *Result*
> The "some, text" string gets split into two pieces: "some" and " text"; (it's 
> split on the comma token).
> I do not want the above string to be split on comma tokens, but this appears 
> to happen by default when jsonpath returns a single element as a string 
> value. A workaround is to override the default tokenization by providing some 
> string I hope never appears in the json I process. For example:
> .split(jsonpath("text.div").tokenize("@@@"))
> If I alter the json as follows, CamelSplitSize is 1 and the output is "some, 
> text" (no split on comma):
> { "text": \{ "div": [ "some, text" ] } } 
> I discussed this with Claus on Zulip and this was his response:
>  ??"Yeah its a bit of corner case, and as you say you can change the token to 
> @@@ or something. To avoid introducing a new option for a case like this, 
> then we can look at if you specify token="false" then its turned off. You are 
> welcome to create a Jira"??
> Only concern with the following is if someone actually wanted to tokenize a 
> string on "false" rather than disable tokenization. Possible I misinterpreted 
> Claus' suggestion though.
> .split(jsonpath("text.div").tokenize("false"))
> I'd be happy to work on contributing this capability to camel and/or unit 
> test cases to help facilitate a contribution.
> Thanks in advance



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15769) Ability to disable tokenization on jsonpath split returning a single element as string

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-15769:

Fix Version/s: 3.7.0

> Ability to disable tokenization on jsonpath split returning a single element 
> as string
> --
>
> Key: CAMEL-15769
> URL: https://issues.apache.org/jira/browse/CAMEL-15769
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-base
>Affects Versions: 3.4.0
>Reporter: Scott Carrier
>Priority: Minor
> Fix For: 3.7.0
>
>
> *Sample json message body:*
> { "text": \{ "div": "some, text" } }
> *DSL*
> .split(jsonpath("text.div"))
> *Result*
> The "some, text" string gets split into two pieces: "some" and " text"; (it's 
> split on the comma token).
> I do not want the above string to be split on comma tokens, but this appears 
> to happen by default when jsonpath returns a single element as a string 
> value. A workaround is to override the default tokenization by providing some 
> string I hope never appears in the json I process. For example:
> .split(jsonpath("text.div").tokenize("@@@"))
> If I alter the json as follows, CamelSplitSize is 1 and the output is "some, 
> text" (no split on comma):
> { "text": \{ "div": [ "some, text" ] } } 
> I discussed this with Claus on Zulip and this was his response:
>  ??"Yeah its a bit of corner case, and as you say you can change the token to 
> @@@ or something. To avoid introducing a new option for a case like this, 
> then we can look at if you specify token="false" then its turned off. You are 
> welcome to create a Jira"??
> Only concern with the following is if someone actually wanted to tokenize a 
> string on "false" rather than disable tokenization. Possible I misinterpreted 
> Claus' suggestion though.
> .split(jsonpath("text.div").tokenize("false"))
> I'd be happy to work on contributing this capability to camel and/or unit 
> test cases to help facilitate a contribution.
> Thanks in advance



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15769) Ability to disable tokenization on jsonpath split returning a single element as string

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-15769:
-

Yeah using "false" is a okay way to tell to not use it. We use also false in 
recipient list EIP for turning off the delimiter
org.apache.camel.processor.RecipientList#IGNORE_DELIMITER_MARKER

> Ability to disable tokenization on jsonpath split returning a single element 
> as string
> --
>
> Key: CAMEL-15769
> URL: https://issues.apache.org/jira/browse/CAMEL-15769
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-base
>Affects Versions: 3.4.0
>Reporter: Scott Carrier
>Priority: Minor
>
> *Sample json message body:*
> { "text": \{ "div": "some, text" } }
> *DSL*
> .split(jsonpath("text.div"))
> *Result*
> The "some, text" string gets split into two pieces: "some" and " text"; (it's 
> split on the comma token).
> I do not want the above string to be split on comma tokens, but this appears 
> to happen by default when jsonpath returns a single element as a string 
> value. A workaround is to override the default tokenization by providing some 
> string I hope never appears in the json I process. For example:
> .split(jsonpath("text.div").tokenize("@@@"))
> If I alter the json as follows, CamelSplitSize is 1 and the output is "some, 
> text" (no split on comma):
> { "text": \{ "div": [ "some, text" ] } } 
> I discussed this with Claus on Zulip and this was his response:
>  ??"Yeah its a bit of corner case, and as you say you can change the token to 
> @@@ or something. To avoid introducing a new option for a case like this, 
> then we can look at if you specify token="false" then its turned off. You are 
> welcome to create a Jira"??
> Only concern with the following is if someone actually wanted to tokenize a 
> string on "false" rather than disable tokenization. Possible I misinterpreted 
> Claus' suggestion though.
> .split(jsonpath("text.div").tokenize("false"))
> I'd be happy to work on contributing this capability to camel and/or unit 
> test cases to help facilitate a contribution.
> Thanks in advance



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15772) camel-pulsar - should support readCompacted configuration

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-15772:

Fix Version/s: 3.7.0

> camel-pulsar - should support readCompacted configuration
> -
>
> Key: CAMEL-15772
> URL: https://issues.apache.org/jira/browse/CAMEL-15772
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-pulsar
>Affects Versions: 3.6.0
>Reporter: Ludovic Boutros
>Priority: Major
> Fix For: 3.7.0
>
>
> In order to read compacted topics, the component (consumer) should support 
> the _readCompacted_ option.
> [readCompacted 
> documentation|https://pulsar.apache.org/docs/en/cookbooks-compaction/#java] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15772) camel-pulsar - should support readCompacted configuration

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen commented on CAMEL-15772:
-

Thanks for reporting are you able to help contribute this?

> camel-pulsar - should support readCompacted configuration
> -
>
> Key: CAMEL-15772
> URL: https://issues.apache.org/jira/browse/CAMEL-15772
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-pulsar
>Affects Versions: 3.6.0
>Reporter: Ludovic Boutros
>Priority: Major
>
> In order to read compacted topics, the component (consumer) should support 
> the _readCompacted_ option.
> [readCompacted 
> documentation|https://pulsar.apache.org/docs/en/cookbooks-compaction/#java] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 6:02 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*
TODO: camel-cxf converter test failure

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15772) camel-pulsar - should support readCompacted configuration

2020-10-29 Thread Ludovic Boutros (Jira)
Ludovic Boutros created CAMEL-15772:
---

 Summary: camel-pulsar - should support readCompacted configuration
 Key: CAMEL-15772
 URL: https://issues.apache.org/jira/browse/CAMEL-15772
 Project: Camel
  Issue Type: New Feature
  Components: camel-pulsar
Affects Versions: 3.6.0
Reporter: Ludovic Boutros


In order to read compacted topics, the component (consumer) should support the 
_readCompacted_ option.

[readCompacted 
documentation|https://pulsar.apache.org/docs/en/cookbooks-compaction/#java] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (CAMEL-15770) Kafka serialize/deserialize properties are inconsistently named

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino reassigned CAMEL-15770:


Assignee: Andrea Cosentino

> Kafka serialize/deserialize properties are inconsistently named
> ---
>
> Key: CAMEL-15770
> URL: https://issues.apache.org/jira/browse/CAMEL-15770
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-kafka, documentation
>Affects Versions: 3.6.0
>Reporter: Franky Georg
>Assignee: Andrea Cosentino
>Priority: Minor
>  Labels: breaking
>
> There are 3 pairs of serializer/deserialiser properties on the Kafka 
> component.
> The inconsistent parts of the names are highlighted
>  
> ||Consumer||Producer||Type||
> |*kafka*HeaderDeserializer|*kafka*HeaderSerializer|Bean|
> |keyDeserializer|keySerializer*Class*|String FQN|
> |*value*Deserializer|serializer*Class*|String FQN|
>  
> I think it would be worth making these names consistent.
> ||Current||Proposed||
> |kafkaHeaderDeserializer|headerDeserializer|
> |kafkaHeaderSerializer|headerSerializer|
> |keyDeserializer|keyDeserializer |
> |keySerializerClass|keySerializer|
> |valueDeserializer|valueDeserializer|
> |serializerClass|valueSerializer|
> It looks like there was an intent to denote the key- and value- properties as 
> expecting a class FQN string by appending 'Class' to the name. I don't see 
> any other properties that do this so I think the consistent approach is to 
> leave it off.
> I've made an assumption that valueDeserializer & serializerClass are a pair, 
> as the descriptions don't match. It would be good to take the opportunity to 
> make all six descriptions consistent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15770) Kafka serialize/deserialize properties are inconsistently named

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino updated CAMEL-15770:
-
Fix Version/s: 3.7.0

> Kafka serialize/deserialize properties are inconsistently named
> ---
>
> Key: CAMEL-15770
> URL: https://issues.apache.org/jira/browse/CAMEL-15770
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-kafka, documentation
>Affects Versions: 3.6.0
>Reporter: Franky Georg
>Assignee: Andrea Cosentino
>Priority: Minor
>  Labels: breaking
> Fix For: 3.7.0
>
>
> There are 3 pairs of serializer/deserialiser properties on the Kafka 
> component.
> The inconsistent parts of the names are highlighted
>  
> ||Consumer||Producer||Type||
> |*kafka*HeaderDeserializer|*kafka*HeaderSerializer|Bean|
> |keyDeserializer|keySerializer*Class*|String FQN|
> |*value*Deserializer|serializer*Class*|String FQN|
>  
> I think it would be worth making these names consistent.
> ||Current||Proposed||
> |kafkaHeaderDeserializer|headerDeserializer|
> |kafkaHeaderSerializer|headerSerializer|
> |keyDeserializer|keyDeserializer |
> |keySerializerClass|keySerializer|
> |valueDeserializer|valueDeserializer|
> |serializerClass|valueSerializer|
> It looks like there was an intent to denote the key- and value- properties as 
> expecting a class FQN string by appending 'Class' to the name. I don't see 
> any other properties that do this so I think the consistent approach is to 
> leave it off.
> I've made an assumption that valueDeserializer & serializerClass are a pair, 
> as the descriptions don't match. It would be good to take the opportunity to 
> make all six descriptions consistent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718834738


   Managed to get Netlify to work by forcing version Yarn version 1.22.5. Now 
some checks fail with:
   
   ```
   page not found from misc/index.html to misc/%22/privacy-policy%22
   page not found from blog/2020/10/ApacheCon-at-Home-videos/index.html to 
blog/2020/10/ApacheCon-at-Home-videos/Pupier_Aur%C3%A9lien_How_to_contribute_textual_tooling_for_Apache_Camel_in_several_IDEs.pdf
   ```
   
   Need to investigate that.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (CAMEL-15771) Align READMEs of fabric8 quickstart using template

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino closed CAMEL-15771.

Resolution: Invalid

> Align READMEs of fabric8 quickstart using template
> --
>
> Key: CAMEL-15771
> URL: https://issues.apache.org/jira/browse/CAMEL-15771
> Project: Camel
>  Issue Type: Improvement
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> Readme files from various fabric8 quickstart are almost the same.
> e.g. spring-boot ones like:
>  * 
> [https://github.com/fabric8-quickstarts/spring-boot-camel/blob/master/README.adoc]
>  * 
> [https://github.com/fabric8-quickstarts/spring-boot-cxf-jaxws-xml/blob/master/README.adoc]
>  * 
> [https://github.com/fabric8-quickstarts/spring-boot-camel-infinispan/blob/master/README.adoc]
>  * ...
> It would be nice to implement some kind of templating mechanism which will 
> bring for example:
>  * similar readme files for various quickstarts - makes it easier to use for 
> users
>  * possibility to fix some global problem in doc for various quickstarts in 
> one place
>  * probably more benefits
> it should be possible to implement such feature using following maven plugin:
> [https://github.com/whelk-io/asciidoc-template-maven-plugin]
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-15771) Align READMEs of fabric8 quickstart using template

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino commented on CAMEL-15771:
--

I don't think this is an Apache Camel related issue, fabric8 is a different 
organization.

> Align READMEs of fabric8 quickstart using template
> --
>
> Key: CAMEL-15771
> URL: https://issues.apache.org/jira/browse/CAMEL-15771
> Project: Camel
>  Issue Type: Improvement
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
>
> Readme files from various fabric8 quickstart are almost the same.
> e.g. spring-boot ones like:
>  * 
> [https://github.com/fabric8-quickstarts/spring-boot-camel/blob/master/README.adoc]
>  * 
> [https://github.com/fabric8-quickstarts/spring-boot-cxf-jaxws-xml/blob/master/README.adoc]
>  * 
> [https://github.com/fabric8-quickstarts/spring-boot-camel-infinispan/blob/master/README.adoc]
>  * ...
> It would be nice to implement some kind of templating mechanism which will 
> bring for example:
>  * similar readme files for various quickstarts - makes it easier to use for 
> users
>  * possibility to fix some global problem in doc for various quickstarts in 
> one place
>  * probably more benefits
> it should be possible to implement such feature using following maven plugin:
> [https://github.com/whelk-io/asciidoc-template-maven-plugin]
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CAMEL-15771) Align READMEs of fabric8 quickstart using template

2020-10-29 Thread Jiri Ondrusek (Jira)
Jiri Ondrusek created CAMEL-15771:
-

 Summary: Align READMEs of fabric8 quickstart using template
 Key: CAMEL-15771
 URL: https://issues.apache.org/jira/browse/CAMEL-15771
 Project: Camel
  Issue Type: Improvement
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek


Readme files from various fabric8 quickstart are almost the same.

e.g. spring-boot ones like:
 * 
[https://github.com/fabric8-quickstarts/spring-boot-camel/blob/master/README.adoc]
 * 
[https://github.com/fabric8-quickstarts/spring-boot-cxf-jaxws-xml/blob/master/README.adoc]
 * 
[https://github.com/fabric8-quickstarts/spring-boot-camel-infinispan/blob/master/README.adoc]
 * ...

It would be nice to implement some kind of templating mechanism which will 
bring for example:
 * similar readme files for various quickstarts - makes it easier to use for 
users
 * possibility to fix some global problem in doc for various quickstarts in one 
place
 * probably more benefits

it should be possible to implement such feature using following maven plugin:

[https://github.com/whelk-io/asciidoc-template-maven-plugin]

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 3:10 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 2:19 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: xml tests failures in core
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 1:06 PM:


TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way for core camel *DONE*
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718732507


   Unplugging highlight.js seems to have helped with this. There is still the 
issue with Netlify preview which I think can be solved by using a newer Yarn 
version there. The error is:
   
   ```
   1:43:09 PM: yarn install v1.17.0
   1:43:09 PM: error Workspaces can only be enabled in private projects.
   1:43:09 PM: info Visit https://yarnpkg.com/en/docs/cli/install for 
documentation about this command.
   1:43:09 PM: Error during Yarn install
   ```



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 12:14 PM:
-

TODO: Optimize enum to let it converter sooner *DONE*
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 11:51 AM:
-

TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures *DONE*
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 10:44 AM:
-

TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures *DONE*
TODO: camel-netty-http test failures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures
TODO: camel-netty-http test failures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718506089


   Seems that I've missed something in the theme build, this is reported [on 
CI](https://ci-builds.apache.org/job/Camel/job/Camel.website/job/PR-417/30/console):
   ```
   ➤ YN: [08:42:30] The following tasks did not complete: bundle, , 
build
   ➤ YN: [08:42:30] Did you forget to signal async completion?
   ```
   
   I'll work on getting that fixed before I merge this.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 8:54 AM:


TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test failures
TODO: camel-netty-http test failures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test faulures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CAMEL-14682) Upgrade the version of Yarn

2020-10-29 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot commented on CAMEL-14682:


zregvart commented on pull request #417:
URL: https://github.com/apache/camel-website/pull/417#issuecomment-718477932


   I think I'll force the older version of xref-validator we use on main branch 
here and update when a fix is ready (either in the asciidoctor-antora-indexer 
or in the xref-validator).



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Upgrade the version of Yarn
> ---
>
> Key: CAMEL-14682
> URL: https://issues.apache.org/jira/browse/CAMEL-14682
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
>  Labels: help-wanted
>
> We currently use version 1.22.0, we could upgrade to to 1.22.1, or even 
> better switch to 2.0 (berry) as it includes improvements to the PnP.
> Switching to 2.0 (berry) would most likely require migration effort for some 
> of the dependencies we use.
> The version needs to change both for the website build and for the 
> antora-ui-camel. Note that we vendor the Yarn within both of them via 
> [policies|https://classic.yarnpkg.com/en/docs/cli/policies].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15736) LevelDB: Update/add karaf features regarding camel-leveldb and camel-levedb-legacy

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino updated CAMEL-15736:
-
Fix Version/s: 3.7.0

> LevelDB: Update/add karaf features regarding camel-leveldb and 
> camel-levedb-legacy
> --
>
> Key: CAMEL-15736
> URL: https://issues.apache.org/jira/browse/CAMEL-15736
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-leveldb, karaf
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
> Fix For: 3.7.0
>
>
> Issue https://issues.apache.org/jira/browse/CAMEL-15679 brought changes to 
> dependencies of camel-leveldb and camel-leveldb-legacy. Both changes have to 
> be reflected in karaf features.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15736) LevelDB: Update/add karaf features regarding camel-leveldb and camel-levedb-legacy

2020-10-29 Thread Andrea Cosentino (Jira)


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

Andrea Cosentino resolved CAMEL-15736.
--
Resolution: Fixed

> LevelDB: Update/add karaf features regarding camel-leveldb and 
> camel-levedb-legacy
> --
>
> Key: CAMEL-15736
> URL: https://issues.apache.org/jira/browse/CAMEL-15736
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-leveldb, karaf
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
> Fix For: 3.7.0
>
>
> Issue https://issues.apache.org/jira/browse/CAMEL-15679 brought changes to 
> dependencies of camel-leveldb and camel-leveldb-legacy. Both changes have to 
> be reflected in karaf features.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (CAMEL-15768) camel-main - can not use the camel.lra.enabled=true

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen resolved CAMEL-15768.
-
Fix Version/s: 3.7.0
   Resolution: Fixed

> camel-main - can not use the camel.lra.enabled=true
> ---
>
> Key: CAMEL-15768
> URL: https://issues.apache.org/jira/browse/CAMEL-15768
> Project: Camel
>  Issue Type: Bug
>  Components: camel-main
>Reporter: Zheng Feng
>Assignee: Zheng Feng
>Priority: Major
> Fix For: 3.7.0
>
>
> I just use the camel-example-main to reproducer this issue
>  * add the camel-lra dependency in the pom.xml
>  * add _camel.lra.enabled=true_ in the application.properties
>  * re-compile and run the example
> {noformat}
> INFO] Using custom org.apache.camel.example.MyApplication to initiate a 
> CamelContext
> [INFO] Starting Camel ...
> 23:02:19.058 [org.apache.camel.example.MyApplication.main()] INFO  
> o.a.camel.support.LRUCacheFactory - Detected and using LRUCacheFactory: 
> camel-caffeine-lrucache
> 23:02:19.161 [org.apache.camel.example.MyApplication.main()] INFO  
> o.apache.camel.main.BaseMainSupport - Using properties from: 
> classpath:application.properties;optional=true
> 23:02:19.175 [org.apache.camel.example.MyApplication.main()] INFO  
> o.apache.camel.main.BaseMainSupport - Loaded additional 1 properties from 
> file: src/main/data/foo.properties
> 23:02:19.243 [org.apache.camel.example.MyApplication.main()] INFO  
> o.a.c.i.e.DefaultBeanIntrospection - Invoked: 1 times (overall) [Method: 
> setProperty, Target: org.apache.camel.service.lra.LRASagaService@13db0de, 
> Arguments: [enabled, true]]
> [ERROR] *
> [ERROR] Error occurred while running main from: 
> org.apache.camel.example.MyApplication
> [ERROR] 
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.camel.maven.RunMojo$1.run (RunMojo.java:438)
> at java.lang.Thread.run (Thread.java:748)
> Caused by: org.apache.camel.PropertyBindingException: Error binding property 
> (camel.lra.enabled=true) with name: enabled on bean: lra-saga-service with 
> value: true
> at org.apache.camel.main.MainHelper.setPropertiesOnTarget 
> (MainHelper.java:192)
> at org.apache.camel.main.BaseMainSupport.setLraCheckProperties 
> (BaseMainSupport.java:1041)
> at 
> org.apache.camel.main.BaseMainSupport.doConfigureCamelContextFromMainConfiguration
>  (BaseMainSupport.java:795)
> at org.apache.camel.main.BaseMainSupport.autoconfigure 
> (BaseMainSupport.java:435)
> at org.apache.camel.main.BaseMainSupport.postProcessCamelContext 
> (BaseMainSupport.java:522)
> at org.apache.camel.main.MainSupport.initCamelContext 
> (MainSupport.java:320)
> at org.apache.camel.main.Main.doInit (Main.java:106)
> at org.apache.camel.support.service.BaseService.init (BaseService.java:83)
> at org.apache.camel.main.MainSupport.run (MainSupport.java:58)
> at org.apache.camel.main.MainCommandLineSupport.run 
> (MainCommandLineSupport.java:156)
> at org.apache.camel.example.MyApplication.main (MyApplication.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.camel.maven.RunMojo$1.run (RunMojo.java:438)
> at java.lang.Thread.run (Thread.java:748)
> {noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15766) camel-spring-boot - No converter found capable of converting from type [java.lang.String] to type [org.apache.camel.component.http.HttpClientConfigurer]

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-15766:

Component/s: camel-spring-boot

> camel-spring-boot - No converter found capable of converting from type 
> [java.lang.String] to type 
> [org.apache.camel.component.http.HttpClientConfigurer]
> 
>
> Key: CAMEL-15766
> URL: https://issues.apache.org/jira/browse/CAMEL-15766
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-spring-boot
>Affects Versions: 3.6.0
>Reporter: Marco Santarelli
>Priority: Major
> Fix For: 3.7.0
>
>
> When trying to use a custom http-configurer, I believe I am experiencing a 
> regression when upgrading to Camel 3.6.0
> I am using spring-boot 2.3.4.RELEASE, and I am declaring my custom configurer 
> bean using:
> {code:java}
> camel.component.http.http-client-configurer=#httpClientConfig
> {code}
> When updating to Camel 3.6.0, that configuration results in: 
> {code:java}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Failed to bind properties under 'camel.component.http.http-client-configurer' 
> to org.apache.camel.component.http.HttpClientConfigurer:
>     Property: camel.component.http.http-client-configurer
>     Value: httpClientConfig
>     Origin: class path resource [application.properties]:1:45
>     Reason: No converter found capable of converting from type 
> [java.lang.String] to type 
> [org.apache.camel.component.http.HttpClientConfigurer]
> Action:
> Update your application's configuration{code}
>  
> See [https://github.com/santam85/camel-3.6.0-http-configurer-bean] for a 
> reproduction example.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15766) camel-spring-boot - No converter found capable of converting from type [java.lang.String] to type [org.apache.camel.component.http.HttpClientConfigurer]

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-15766:

Fix Version/s: 3.7.0

> camel-spring-boot - No converter found capable of converting from type 
> [java.lang.String] to type 
> [org.apache.camel.component.http.HttpClientConfigurer]
> 
>
> Key: CAMEL-15766
> URL: https://issues.apache.org/jira/browse/CAMEL-15766
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http
>Affects Versions: 3.6.0
>Reporter: Marco Santarelli
>Priority: Major
> Fix For: 3.7.0
>
>
> When trying to use a custom http-configurer, I believe I am experiencing a 
> regression when upgrading to Camel 3.6.0
> I am using spring-boot 2.3.4.RELEASE, and I am declaring my custom configurer 
> bean using:
> {code:java}
> camel.component.http.http-client-configurer=#httpClientConfig
> {code}
> When updating to Camel 3.6.0, that configuration results in: 
> {code:java}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Failed to bind properties under 'camel.component.http.http-client-configurer' 
> to org.apache.camel.component.http.HttpClientConfigurer:
>     Property: camel.component.http.http-client-configurer
>     Value: httpClientConfig
>     Origin: class path resource [application.properties]:1:45
>     Reason: No converter found capable of converting from type 
> [java.lang.String] to type 
> [org.apache.camel.component.http.HttpClientConfigurer]
> Action:
> Update your application's configuration{code}
>  
> See [https://github.com/santam85/camel-3.6.0-http-configurer-bean] for a 
> reproduction example.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (CAMEL-15766) camel-spring-boot - No converter found capable of converting from type [java.lang.String] to type [org.apache.camel.component.http.HttpClientConfigurer]

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen updated CAMEL-15766:

Summary: camel-spring-boot - No converter found capable of converting from 
type [java.lang.String] to type 
[org.apache.camel.component.http.HttpClientConfigurer]  (was: No converter 
found capable of converting from type [java.lang.String] to type 
[org.apache.camel.component.http.HttpClientConfigurer])

> camel-spring-boot - No converter found capable of converting from type 
> [java.lang.String] to type 
> [org.apache.camel.component.http.HttpClientConfigurer]
> 
>
> Key: CAMEL-15766
> URL: https://issues.apache.org/jira/browse/CAMEL-15766
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http
>Affects Versions: 3.6.0
>Reporter: Marco Santarelli
>Priority: Major
>
> When trying to use a custom http-configurer, I believe I am experiencing a 
> regression when upgrading to Camel 3.6.0
> I am using spring-boot 2.3.4.RELEASE, and I am declaring my custom configurer 
> bean using:
> {code:java}
> camel.component.http.http-client-configurer=#httpClientConfig
> {code}
> When updating to Camel 3.6.0, that configuration results in: 
> {code:java}
> ***
> APPLICATION FAILED TO START
> ***
> Description:
> Failed to bind properties under 'camel.component.http.http-client-configurer' 
> to org.apache.camel.component.http.HttpClientConfigurer:
>     Property: camel.component.http.http-client-configurer
>     Value: httpClientConfig
>     Origin: class path resource [application.properties]:1:45
>     Reason: No converter found capable of converting from type 
> [java.lang.String] to type 
> [org.apache.camel.component.http.HttpClientConfigurer]
> Action:
> Update your application's configuration{code}
>  
> See [https://github.com/santam85/camel-3.6.0-http-configurer-bean] for a 
> reproduction example.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (CAMEL-15765) camel-core - Optimize base converters

2020-10-29 Thread Claus Ibsen (Jira)


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

Claus Ibsen edited comment on CAMEL-15765 at 10/29/20, 6:03 AM:


TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures *DONE*
TODO: camel-flatpack test faulures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*


was (Author: davsclaus):
TODO: Optimize enum to let it converter sooner
TODO: New way for type converter loaded to register as single class *DONE*
TODO: Regen type converter loader source with new way
TODO: Report number of converters via loader in new way *DONE*
TODO: Report type converter combos in a new way *DONE*
TODO: camel-cxf test failures
TODO: Potential optimize for == match before instanceof in generated source code
TODO: camel-karaf to support bulk type converter loader *DONE*

> camel-core - Optimize base converters
> -
>
> Key: CAMEL-15765
> URL: https://issues.apache.org/jira/browse/CAMEL-15765
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.7.0
>
>
> Working on optimizing the type converters from camel-base to be source code 
> generated as a single class with big if .. else for doing converters.
> This makes Camel faster and smaller
> - reduces the classes loaded as there are no lambdas classes for each 
> converter
> - does not register in the doublemap with from/to which reduces from 21kb to 
> 3kb heap memory
> - likely faster than the map lookup and with the lambda call
> Before this prototype then DefaultTypeConverterRegistry was the 2nd biggest 
> dominator from Camel (context biggest). Now its down to less than 3kb



--
This message was sent by Atlassian Jira
(v8.3.4#803005)