[jira] [Commented] (CAMEL-14935) KafkaConsumer commits old offset values in a failure scenario causing message replays and offset reset error
[ https://issues.apache.org/jira/browse/CAMEL-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124469#comment-17124469 ] Chris McCarthy commented on CAMEL-14935: Yes agreed, we dont want to clear as other consumers use that map and we will lose their state > KafkaConsumer commits old offset values in a failure scenario causing message > replays and offset reset error > > > Key: CAMEL-14935 > URL: https://issues.apache.org/jira/browse/CAMEL-14935 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 2.24.0 >Reporter: Chris McCarthy >Priority: Major > Fix For: 3.x > > > We are experiencing unexpected offset reset errors occasionally, as well as > occasional replay of messages (without an offset reset error). > The cause seems to be a failed commit on rebalance, leaving an old value in > the hashMap used to store the latest processed offset for a partition. This > old value is then re-read and re-committed across rebalances in certain > situations. > Our relevant configuration details are: > autoCommitEnable=false > allowManualCommit=true > autoOffsetReset=earliest > It seems when the KafkaConsumer experiences an Exception committing the > offset (CommitFailedException) upon a rebalance, this leaves the old offset > value in the lastProcessedOffset hashMap. > A subsequent rebalance that assigns the same partition to the same consumer, > that then thereafter experiences another rebalance (before any messages have > been processed successfully as this will over write the invalid value and > self correct the problem) will commit this old offset again. This offset may > be very old if there have been many rebalances in between the original > rebalance that failed to commit its offset. > If the old offset is beyond the retention period and the message is no longer > available the outcome is an offset reset error. If the offset is within the > retention period all messages are replayed from that offset without an error > being thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15081) Camel health - Make it easier to configure in camel-main
[ https://issues.apache.org/jira/browse/CAMEL-15081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15081. - Resolution: Fixed > Camel health - Make it easier to configure in camel-main > > > Key: CAMEL-15081 > URL: https://issues.apache.org/jira/browse/CAMEL-15081 > Project: Camel > Issue Type: New Feature > Components: camel-core, camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.4.0 > > > There are some health configuration options you can set. We should make it > easy to configure in camel-main, so you can configure them across runtimes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14994) camel website - Projects page can we add logos
[ https://issues.apache.org/jira/browse/CAMEL-14994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123682#comment-17123682 ] ASF GitHub Bot commented on CAMEL-14994: aashnajena commented on pull request #370: URL: https://github.com/apache/camel-website/pull/370#issuecomment-637489066 What's the smallest width for which we need to adjust our design? Right now, the buttons get broken at <400px width, so I will fix 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 > camel website - Projects page can we add logos > -- > > Key: CAMEL-14994 > URL: https://issues.apache.org/jira/browse/CAMEL-14994 > Project: Camel > Issue Type: Improvement > Components: website >Reporter: Claus Ibsen >Priority: Major > Attachments: projects-desgin.png, projects_mockup.png > > > The page > https://camel.apache.org/projects/ > List the projects (we should btw add Camel itself IMHO). > So basically can we add the logos that we have on the front page, and list > them with same caption too. This would make it more appealing as today its a > bit dull. And if you go to the front page you have to scroll down to see > those projects and logos, so some users may miss seeing that. > Also order them so its > - camel > - camel k > - camel kafka > - camel spring boot > - camel quarkus > - camel karaf -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-14935) KafkaConsumer commits old offset values in a failure scenario causing message replays and offset reset error
[
https://issues.apache.org/jira/browse/CAMEL-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123576#comment-17123576
]
Darius Cooper edited comment on CAMEL-14935 at 6/2/20, 11:11 AM:
-
[~Chris McCarthy] Claus [suggested the
following|[https://github.com/apache/camel/pull/3877]], which sounds good to me:
* On Exception, we clear
* In the Finally, we remove the current offset key
The existing code had:
{code:java}
lastProcessedOffset.remove(offsetKey);{code}
So, we'd be putting that in the finally block
Indeed, I have a question: do we really need to clear within the catch block?
Removing the offset for the current partition, within the finally block ought
to do it, right?
That's the code that was being skipped originally...so, we just need to move it
to the finally block?
was (Author: dariusx):
[~Chris McCarthy] Claus [suggested the
following|[https://github.com/apache/camel/pull/3877]], which sounds good to me:
* On Exception, we clear
* In the Finally, we remove the current offset key
The existing code had:
{code:java}
lastProcessedOffset.remove(offsetKey);{code}
So, we'd be putting that in the finally block
> KafkaConsumer commits old offset values in a failure scenario causing message
> replays and offset reset error
>
>
> Key: CAMEL-14935
> URL: https://issues.apache.org/jira/browse/CAMEL-14935
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 2.24.0
>Reporter: Chris McCarthy
>Priority: Major
> Fix For: 3.x
>
>
> We are experiencing unexpected offset reset errors occasionally, as well as
> occasional replay of messages (without an offset reset error).
> The cause seems to be a failed commit on rebalance, leaving an old value in
> the hashMap used to store the latest processed offset for a partition. This
> old value is then re-read and re-committed across rebalances in certain
> situations.
> Our relevant configuration details are:
> autoCommitEnable=false
> allowManualCommit=true
> autoOffsetReset=earliest
> It seems when the KafkaConsumer experiences an Exception committing the
> offset (CommitFailedException) upon a rebalance, this leaves the old offset
> value in the lastProcessedOffset hashMap.
> A subsequent rebalance that assigns the same partition to the same consumer,
> that then thereafter experiences another rebalance (before any messages have
> been processed successfully as this will over write the invalid value and
> self correct the problem) will commit this old offset again. This offset may
> be very old if there have been many rebalances in between the original
> rebalance that failed to commit its offset.
> If the old offset is beyond the retention period and the message is no longer
> available the outcome is an offset reset error. If the offset is within the
> retention period all messages are replayed from that offset without an error
> being thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15142) Build a Documentation Under Constructions handlebar
[ https://issues.apache.org/jira/browse/CAMEL-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123584#comment-17123584 ] Aemie commented on CAMEL-15142: --- They are easy to navigate through the camel spring documentation and it was just completely empty. Yea, if those pages are not meant to be found, it must be fixed but if that's the case why are they existing within the nav.adoc file? > Build a Documentation Under Constructions handlebar > --- > > Key: CAMEL-15142 > URL: https://issues.apache.org/jira/browse/CAMEL-15142 > Project: Camel > Issue Type: Task >Reporter: Aemie >Priority: Major > Labels: outreachy2020 > > * I observed that for certain pages including > [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-zookeeper.html] > & > [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-consul.html], > the documentation is yet not written however published on the website. So in > such cases, I believe it is a good practice to include a construction page > handlebar as a user would be informed about if documentation is yet to be > made or not. > * What are your opinions on this, [~zregvart]? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14904) Nav pane does not show current page
[ https://issues.apache.org/jira/browse/CAMEL-14904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123579#comment-17123579 ] Aemie commented on CAMEL-14904: --- Yea hopefully it might 'cause they calculate the panel.scrollTop fr the current page item however they don't perform any scroll functioning for it. I have recheched with the repo on gitlab. > Nav pane does not show current page > --- > > Key: CAMEL-14904 > URL: https://issues.apache.org/jira/browse/CAMEL-14904 > Project: Camel > Issue Type: Task > Components: website >Affects Versions: 3.2.0 >Reporter: David Jencks >Priority: Major > > The Antora default UI highlights and makes sure the nav list item for the > current page remains visible. The Camel components list does not do this, > always scrolling to the top when you click on an item. This makes it very > hard to use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-15128) camel health - Add standalone health check
[ https://issues.apache.org/jira/browse/CAMEL-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15128. - Resolution: Fixed > camel health - Add standalone health check > -- > > Key: CAMEL-15128 > URL: https://issues.apache.org/jira/browse/CAMEL-15128 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.4.0 > > > If you run camel standalone and have camel-health on the classpath, we should > include a basic camel context health check. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14935) KafkaConsumer commits old offset values in a failure scenario causing message replays and offset reset error
[
https://issues.apache.org/jira/browse/CAMEL-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123576#comment-17123576
]
Darius Cooper commented on CAMEL-14935:
---
[~Chris McCarthy] Claus [suggested the
following|[https://github.com/apache/camel/pull/3877]], which sounds good to me:
* On Exception, we clear
* In the Finally, we remove the current offset key
The existing code had:
{code:java}
lastProcessedOffset.remove(offsetKey);{code}
So, we'd be putting that in the finally block
> KafkaConsumer commits old offset values in a failure scenario causing message
> replays and offset reset error
>
>
> Key: CAMEL-14935
> URL: https://issues.apache.org/jira/browse/CAMEL-14935
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 2.24.0
>Reporter: Chris McCarthy
>Priority: Major
> Fix For: 3.x
>
>
> We are experiencing unexpected offset reset errors occasionally, as well as
> occasional replay of messages (without an offset reset error).
> The cause seems to be a failed commit on rebalance, leaving an old value in
> the hashMap used to store the latest processed offset for a partition. This
> old value is then re-read and re-committed across rebalances in certain
> situations.
> Our relevant configuration details are:
> autoCommitEnable=false
> allowManualCommit=true
> autoOffsetReset=earliest
> It seems when the KafkaConsumer experiences an Exception committing the
> offset (CommitFailedException) upon a rebalance, this leaves the old offset
> value in the lastProcessedOffset hashMap.
> A subsequent rebalance that assigns the same partition to the same consumer,
> that then thereafter experiences another rebalance (before any messages have
> been processed successfully as this will over write the invalid value and
> self correct the problem) will commit this old offset again. This offset may
> be very old if there have been many rebalances in between the original
> rebalance that failed to commit its offset.
> If the old offset is beyond the retention period and the message is no longer
> available the outcome is an offset reset error. If the offset is within the
> retention period all messages are replayed from that offset without an error
> being thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15147) camel-core - Supervising route nicer logging
Claus Ibsen created CAMEL-15147: --- Summary: camel-core - Supervising route nicer logging Key: CAMEL-15147 URL: https://issues.apache.org/jira/browse/CAMEL-15147 Project: Camel Issue Type: Task Reporter: Claus Ibsen Fix For: 3.4.0 Start supervising route: netty with back-off: BackOff[delay=PT2S, maxDelay=PT2562047788015H12M55.807S, maxElapsedTime=PT2562047788015H12M55.807S, maxAttempts=10, multiplier=1.0] Lets avoid those ugly duration logs with something human understandable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123476#comment-17123476 ] Zheng Feng commented on CAMEL-14805: OK, it sounds good to me ! > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15146) Handle validatorFactory field in BeanValidatorComponentConfigurer
James Netherton created CAMEL-15146: --- Summary: Handle validatorFactory field in BeanValidatorComponentConfigurer Key: CAMEL-15146 URL: https://issues.apache.org/jira/browse/CAMEL-15146 Project: Camel Issue Type: Improvement Components: camel-bean-validator Reporter: James Netherton Assignee: James Netherton Fix For: 3.4.0 Seems there's the intention of being able to provide a custom ValidatorFactory to BeanValidatorComponent. But, there's no getter or setter method for the private validatorFactory field. Thus it can never be handled by BeanValidatorComponentConfigurer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123461#comment-17123461 ] Claus Ibsen commented on CAMEL-14805: - We could have a .md or .adoc file in the components folder, then its located where they are. We can name it something like components-init-work-in-progress Then we can keep it up to date with PRs > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123459#comment-17123459 ] Zheng Feng commented on CAMEL-14805: sure, where can I put this table ? in camel document website ? Actually, I went over the more components not on this list. So I will put them together. > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123432#comment-17123432 ] Claus Ibsen commented on CAMEL-14805: - Can we make the table sorted A..Z and put up somewhere, as frankly we should go over all the Camel components (not only current quarkus extensions, as that will grow over time). And this benefits all runtimes and Camel in general too. > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123430#comment-17123430 ] Zheng Feng commented on CAMEL-14805: [~davsclaus] I went through most of these components on this list and it could be ready for 3.4.0 > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-7881) camel-resetlet feature should include httpclient4 bundle
[
https://issues.apache.org/jira/browse/CAMEL-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123431#comment-17123431
]
Andrea Cosentino commented on CAMEL-7881:
-
The error you posted is from a fuse build. Report to Red Hat. We don't release
2.21 anymore
> camel-resetlet feature should include httpclient4 bundle
>
>
> Key: CAMEL-7881
> URL: https://issues.apache.org/jira/browse/CAMEL-7881
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.12.4, 2.13.2, 2.14.0
>Reporter: Willem Jiang
>Assignee: Willem Jiang
>Priority: Major
> Fix For: 2.12.5, 2.13.3, 2.14.1
>
>
> {code}
> 2014-09-29 16:26:41,670 | INFO | FelixStartLevel | restlet
> | org.restlet.engine.Engine 900 | 75 - org.restlet -
> 2.2.1.v20140506-1533 | Unable to register the helper
> org.restlet.ext.httpclient.HttpClientHelper
> java.lang.NoClassDefFoundError: org/apache/http/params/HttpParams
> at java.lang.Class.getDeclaredConstructors0(Native Method)[:1.7.0_45]
> at
> java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)[:1.7.0_45]
> at java.lang.Class.getConstructor0(Class.java:2803)[:1.7.0_45]
> at java.lang.Class.getConstructor(Class.java:1718)[:1.7.0_45]
> at
> org.restlet.engine.Engine.registerHelper(Engine.java:896)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.Engine.registerHelpers(Engine.java:928)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.registerHelper(Activator.java:96)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.registerHelper(Activator.java:78)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.registerHelpers(Activator.java:117)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.start(Activator.java:143)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:1895)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)[org.apache.felix.framework-4.0.3.jar:]
> at java.lang.Thread.run(Thread.java:744)[:1.7.0_45]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.http.params.HttpParams not found by org.restlet.ext.httpclient [76]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_45]
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113209#comment-17113209 ] Zheng Feng edited comment on CAMEL-14805 at 6/2/20, 7:13 AM: - [~gnodet], I get a list of extension from the camel-quarkus currently, which the camel component has the doStart. ||Component||Status||Reason|| |camel-ahc|REJECT|create thread pool| |camel-aws2-s3|REJECT| | |camel-aws-ec2|REJECT| | |camel-aws-ecs|REJECT| | |camel-aws-eks|REJECT| | |camel-aws-iam|REJECT| | |camel-aws-kinesis|REJECT| | |camel-aws-kms|REJECT| | |camel-aws-lambda|REJECT| | |camel-aws-s3|REJECT| | |camel-aws-sdb|REJECT| | |camel-aws-swf|REJECT| | |camel-aws-translate|REJECT| | |camel-bean|DONE| | |camel-dataformat|DONE| | |camel-dozer|DONE| | |camel-file|DONE| | |camel-infinispan|REJECT|start a server and create thread | |camel-jira|REJECT|create the http client | |camel-kubernetes|REJECT|OKHttp client create thread pool | |camel-kudu|REJECT|create thread pool| |camel-log|DONE| | |camel-mongodb|REJECT| resolve the MongClient from the camelContext and it potentially open the connection and run the command | |camel-netty-http|DONE| | |camel-olingo4|REJECT|create the asyn http client | |camel-platform-http|DONE| | |camel-quartz|REJECT|quartz schedule create thread pool | |camel-ref|REJECT|add the other endpoint uri | |camel-salesforce|REJECT|create a http client and start it | |camel-seda|DONE| | |camel-sjms|REJECT|create connections pool | |camel-sql|DONE| | |camel-stream|DONE| | |camel-telegram|REJECT|create thread pool | |camel-timer|DONE| | |camel-xslt|DONE| | I'd like to take a look at these component at first and ignore what use the XXXClient to open the network connection which I think should not be moved to doInit(). I just wonder what component you have been investigating ? was (Author: zhfeng): [~gnodet], I get a list of extension from the camel-quarkus currently, which the camel component has the doStart. ||Component||Status||Reason|| |camel-ahc|REJECT|create thread pool| |camel-aws2-s3|REJECT| | |camel-aws-ec2|REJECT| | |camel-aws-ecs|REJECT| | |camel-aws-eks| |REJECT| |camel-aws-iam| |REJECT| |camel-aws-kinesis|REJECT| | |camel-aws-kms|REJECT| | |camel-aws-lambda|REJECT| | |camel-aws-s3|REJECT| | |camel-aws-sdb|REJECT| | |camel-aws-swf|REJECT| | |camel-aws-translate|REJECT| | |camel-bean|DONE| | |camel-dataformat|DONE| | |camel-dozer|DONE| | |camel-file|DONE| | |camel-infinispan|REJECT|start a server and create thread | |camel-jira|REJECT|create the http client | |camel-kubernetes|REJECT|OKHttp client create thread pool | |camel-kudu|REJECT|create thread pool| |camel-log|DONE| | |camel-mongodb|REJECT| resolve the MongClient from the camelContext and it potentially open the connection and run the command | |camel-netty-http|DONE| | |camel-olingo4|REJECT|create the asyn http client | |camel-platform-http|DONE| | |camel-quartz|REJECT|quartz schedule create thread pool | |camel-ref|REJECT|add the other endpoint uri | |camel-salesforce|REJECT|create a http client and start it | |camel-seda|DONE| | |camel-sjms|REJECT|create connections pool | |camel-sql|DONE| | |camel-stream|DONE| | |camel-telegram|REJECT|create thread pool | |camel-timer|DONE| | |camel-xslt|DONE| | I'd like to take a look at these component at first and ignore what use the XXXClient to open the network connection which I think should not be moved to doInit(). I just wonder what component you have been investigating ? > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14904) Nav pane does not show current page
[ https://issues.apache.org/jira/browse/CAMEL-14904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123420#comment-17123420 ] Zoran Regvart commented on CAMEL-14904: --- We discussed this on the call and agreed to try to rebase on the latest Antora Default UI to try to fix this first. > Nav pane does not show current page > --- > > Key: CAMEL-14904 > URL: https://issues.apache.org/jira/browse/CAMEL-14904 > Project: Camel > Issue Type: Task > Components: website >Affects Versions: 3.2.0 >Reporter: David Jencks >Priority: Major > > The Antora default UI highlights and makes sure the nav list item for the > current page remains visible. The Camel components list does not do this, > always scrolling to the top when you click on an item. This makes it very > hard to use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-14805) Component - Use doInit for wiring instead of doStart
[ https://issues.apache.org/jira/browse/CAMEL-14805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113209#comment-17113209 ] Zheng Feng edited comment on CAMEL-14805 at 6/2/20, 7:13 AM: - [~gnodet], I get a list of extension from the camel-quarkus currently, which the camel component has the doStart. ||Component||Status||Reason|| |camel-ahc|REJECT|create thread pool| |camel-aws2-s3|REJECT| | |camel-aws-ec2|REJECT| | |camel-aws-ecs|REJECT| | |camel-aws-eks| |REJECT| |camel-aws-iam| |REJECT| |camel-aws-kinesis|REJECT| | |camel-aws-kms|REJECT| | |camel-aws-lambda|REJECT| | |camel-aws-s3|REJECT| | |camel-aws-sdb|REJECT| | |camel-aws-swf|REJECT| | |camel-aws-translate|REJECT| | |camel-bean|DONE| | |camel-dataformat|DONE| | |camel-dozer|DONE| | |camel-file|DONE| | |camel-infinispan|REJECT|start a server and create thread | |camel-jira|REJECT|create the http client | |camel-kubernetes|REJECT|OKHttp client create thread pool | |camel-kudu|REJECT|create thread pool| |camel-log|DONE| | |camel-mongodb|REJECT| resolve the MongClient from the camelContext and it potentially open the connection and run the command | |camel-netty-http|DONE| | |camel-olingo4|REJECT|create the asyn http client | |camel-platform-http|DONE| | |camel-quartz|REJECT|quartz schedule create thread pool | |camel-ref|REJECT|add the other endpoint uri | |camel-salesforce|REJECT|create a http client and start it | |camel-seda|DONE| | |camel-sjms|REJECT|create connections pool | |camel-sql|DONE| | |camel-stream|DONE| | |camel-telegram|REJECT|create thread pool | |camel-timer|DONE| | |camel-xslt|DONE| | I'd like to take a look at these component at first and ignore what use the XXXClient to open the network connection which I think should not be moved to doInit(). I just wonder what component you have been investigating ? was (Author: zhfeng): [~gnodet], I get a list of extension from the camel-quarkus currently, which the camel component has the doStart. ||Component||Status||Reason|| |camel-ahc|REJECT|create thread pool| |camel-aws2-s3| | | |camel-aws-ec2| | | |camel-aws-ecs| | | |camel-aws-eks| | | |camel-aws-iam| | | |camel-aws-kinesis| | | |camel-aws-kms| | | |camel-aws-lambda| | | |camel-aws-s3| | | |camel-aws-sdb| | | |camel-aws-swf| | | |camel-aws-translate| | | |camel-bean|DONE| | |camel-dataformat|DONE| | |camel-dozer|DONE| | |camel-file|DONE| | |camel-infinispan|REJECT|start a server and create thread | |camel-jira|REJECT|create the http client | |camel-kubernetes|REJECT|OKHttp client create thread pool | |camel-kudu|REJECT|create thread pool| |camel-log|DONE| | |camel-mongodb|REJECT| resolve the MongClient from the camelContext and it potentially open the connection and run the command | |camel-netty-http|DONE| | |camel-olingo4|REJECT|create the asyn http client | |camel-platform-http|DONE| | |camel-quartz|REJECT|quartz schedule create thread pool | |camel-ref|REJECT|add the other endpoint uri | |camel-salesforce|REJECT|create a http client and start it | |camel-seda|DONE| | |camel-sjms|REJECT|create connections pool | |camel-sql|DONE| | |camel-stream|DONE| | |camel-telegram|REJECT|create thread pool | |camel-timer|DONE| | |camel-xslt|DONE| | I'd like to take a look at these component at first and ignore what use the XXXClient to open the network connection which I think should not be moved to doInit(). I just wonder what component you have been investigating ? > Component - Use doInit for wiring instead of doStart > > > Key: CAMEL-14805 > URL: https://issues.apache.org/jira/browse/CAMEL-14805 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Assignee: Zheng Feng >Priority: Major > Fix For: 3.4.0 > > > We should move logic from start to init for wiring and other similar things > that can be setup as early as possible for lightweight camel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (CAMEL-15141) documentation - Image not display on a FAQ page
[ https://issues.apache.org/jira/browse/CAMEL-15141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aemie updated CAMEL-15141: -- Comment: was deleted (was: [~zregvart] I had a query when I went through the Antora docs for inserting the images in the adoc files, it said that all images must be placed within *assets/images* folder and with the particular syntax, the filename should be relative to this image file structure. In spite of that, *image::using-getin-or-getout-methods-on-exchange/Message-flow-in-Route.png[image]* results in no image, and the tree structure of image within faq is as follows: - assets - images - using-getin-or-getout-methods-on-exchange - Message-flow-in-Route.png) > documentation - Image not display on a FAQ page > --- > > Key: CAMEL-15141 > URL: https://issues.apache.org/jira/browse/CAMEL-15141 > Project: Camel > Issue Type: Task > Components: documentation, website >Reporter: Claus Ibsen >Priority: Major > Labels: help-wanted, outreachy2020 > Fix For: 3.x > > > See this page > https://camel.apache.org/manual/latest/faq/using-getin-or-getout-methods-on-exchange.html > There is an image that is not displayed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15142) Build a Documentation Under Constructions handlebar
[ https://issues.apache.org/jira/browse/CAMEL-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123416#comment-17123416 ] Zoran Regvart commented on CAMEL-15142: --- How did you reach those pages? If we link to those pages either they’re no longer relevant and links need do be removed, and in that case the broken link checker should have failed to find them so we need to fix the link checker as well. > Build a Documentation Under Constructions handlebar > --- > > Key: CAMEL-15142 > URL: https://issues.apache.org/jira/browse/CAMEL-15142 > Project: Camel > Issue Type: Task >Reporter: Aemie >Priority: Major > Labels: outreachy2020 > > * I observed that for certain pages including > [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-zookeeper.html] > & > [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-consul.html], > the documentation is yet not written however published on the website. So in > such cases, I believe it is a good practice to include a construction page > handlebar as a user would be informed about if documentation is yet to be > made or not. > * What are your opinions on this, [~zregvart]? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14952) Better search on the website
[
https://issues.apache.org/jira/browse/CAMEL-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123409#comment-17123409
]
Zoran Regvart commented on CAMEL-14952:
---
[~Aemie] here is the documentation for the docsearch:
https://docsearch.algolia.com/docs/how-does-it-work that is the extent of my
knowledge, everything is configured by Algolia and we have no influence on the
configuration. From what I understand the sitemaps provide URLs to index.
> Better search on the website
>
>
> Key: CAMEL-14952
> URL: https://issues.apache.org/jira/browse/CAMEL-14952
> Project: Camel
> Issue Type: Improvement
> Components: website
>Reporter: Zoran Regvart
>Priority: Major
>
> We use [Algolia|http://algolia.com/] for the search functionality on the
> website using their [free plan|https://www.algolia.com/for-open-source/] for
> Open Source projects. The index is built by Algolia's crawler using the
> [DocSearch|https://docsearch.algolia.com/].
> When this was done we built our own UI on top of Algolia JavaScript API, as
> one if requirements is that clients use Algolia's JavaScript clients. We did
> not use Algolia UI as at that point it was rather large JavaScript dependency
> to add and it would slow down the loading of the website.
> We also have some [initial
> work|https://github.com/apache/camel-website/pull/74] on creating our own
> Algolia index at build time.
> The current search doesn't seem to index the whole website, some results
> don't appear in the search, looks like most of the content from Antora is not
> indexed: trying to search for {{removeHeader}}, the [FAQ
> entry|https://camel.apache.org/manual/latest/faq/how-to-avoid-sending-some-or-all-message-headers.html]
> is not found. There's also a list of failed searches on the Algolia
> dashboard we can use to benchmark the search.
> What we need is to build the search index over the whole content. Approach
> taken in [#74|https://github.com/apache/camel-website/pull/74] is good start
> for Hugo generated content. We need to expand that to Antora built content as
> well.
> This search index would be built at the website build time and would include
> both Hugo and Algolia content in the same file or possibly in several files
> if we use multi-index search. More on how indexes are built can be seen in
> the [Algolia
> documentation|https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/].
> We need to figure out what data to send and how to integrate this with
> Antora, for Hugo we have a good idea from
> [#74|https://github.com/apache/camel-website/pull/74], importantly the
> structure needs to be the same. One good source of inspiration on building
> the index for Antora content is in the [Lunr.js
> integration|https://github.com/Mogztter/antora-lunr].
> We need to build the index with the search UI in mind, i.e. the index needs
> to contain the data we wish to present in the UI as well as enough content
> for Algolia to be able to use the content to perform search. So starting with
> a mockup of what we wish to present/utilize in the search UI and deriving the
> data structure for the index from that would be a good start.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-7881) camel-resetlet feature should include httpclient4 bundle
[
https://issues.apache.org/jira/browse/CAMEL-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123395#comment-17123395
]
Luca Ferrari commented on CAMEL-7881:
-
I still see this issue:
{code:java}
19:29:52.001 [main] INFO org.restlet - Unable to register the helper
org.restlet.ext.httpclient.HttpClientHelper
java.lang.NoClassDefFoundError:
org/apache/http/conn/ClientConnectionManager{code}
when using camel-restlet with version 2.21.0.fuse-760027-redhat-1
> camel-resetlet feature should include httpclient4 bundle
>
>
> Key: CAMEL-7881
> URL: https://issues.apache.org/jira/browse/CAMEL-7881
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.12.4, 2.13.2, 2.14.0
>Reporter: Willem Jiang
>Assignee: Willem Jiang
>Priority: Major
> Fix For: 2.12.5, 2.13.3, 2.14.1
>
>
> {code}
> 2014-09-29 16:26:41,670 | INFO | FelixStartLevel | restlet
> | org.restlet.engine.Engine 900 | 75 - org.restlet -
> 2.2.1.v20140506-1533 | Unable to register the helper
> org.restlet.ext.httpclient.HttpClientHelper
> java.lang.NoClassDefFoundError: org/apache/http/params/HttpParams
> at java.lang.Class.getDeclaredConstructors0(Native Method)[:1.7.0_45]
> at
> java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)[:1.7.0_45]
> at java.lang.Class.getConstructor0(Class.java:2803)[:1.7.0_45]
> at java.lang.Class.getConstructor(Class.java:1718)[:1.7.0_45]
> at
> org.restlet.engine.Engine.registerHelper(Engine.java:896)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.Engine.registerHelpers(Engine.java:928)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.registerHelper(Activator.java:96)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.registerHelper(Activator.java:78)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.registerHelpers(Activator.java:117)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.restlet.engine.internal.Activator.start(Activator.java:143)[75:org.restlet:2.2.1.v20140506-1533]
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:1895)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)[org.apache.felix.framework-4.0.3.jar:]
> at java.lang.Thread.run(Thread.java:744)[:1.7.0_45]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.http.params.HttpParams not found by org.restlet.ext.httpclient [76]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_45]
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14952) Better search on the website
[
https://issues.apache.org/jira/browse/CAMEL-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123386#comment-17123386
]
Aemie commented on CAMEL-14952:
---
[~zregvart] if the DocSearch scrapes the entire documentation of the website,
it is only able to scrape through the parts within the camel-website repo, it
doesn't go in-depth indexing through any component or user manual documentation
that was created using antora within the camel repository.
> Better search on the website
>
>
> Key: CAMEL-14952
> URL: https://issues.apache.org/jira/browse/CAMEL-14952
> Project: Camel
> Issue Type: Improvement
> Components: website
>Reporter: Zoran Regvart
>Priority: Major
>
> We use [Algolia|http://algolia.com/] for the search functionality on the
> website using their [free plan|https://www.algolia.com/for-open-source/] for
> Open Source projects. The index is built by Algolia's crawler using the
> [DocSearch|https://docsearch.algolia.com/].
> When this was done we built our own UI on top of Algolia JavaScript API, as
> one if requirements is that clients use Algolia's JavaScript clients. We did
> not use Algolia UI as at that point it was rather large JavaScript dependency
> to add and it would slow down the loading of the website.
> We also have some [initial
> work|https://github.com/apache/camel-website/pull/74] on creating our own
> Algolia index at build time.
> The current search doesn't seem to index the whole website, some results
> don't appear in the search, looks like most of the content from Antora is not
> indexed: trying to search for {{removeHeader}}, the [FAQ
> entry|https://camel.apache.org/manual/latest/faq/how-to-avoid-sending-some-or-all-message-headers.html]
> is not found. There's also a list of failed searches on the Algolia
> dashboard we can use to benchmark the search.
> What we need is to build the search index over the whole content. Approach
> taken in [#74|https://github.com/apache/camel-website/pull/74] is good start
> for Hugo generated content. We need to expand that to Antora built content as
> well.
> This search index would be built at the website build time and would include
> both Hugo and Algolia content in the same file or possibly in several files
> if we use multi-index search. More on how indexes are built can be seen in
> the [Algolia
> documentation|https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/].
> We need to figure out what data to send and how to integrate this with
> Antora, for Hugo we have a good idea from
> [#74|https://github.com/apache/camel-website/pull/74], importantly the
> structure needs to be the same. One good source of inspiration on building
> the index for Antora content is in the [Lunr.js
> integration|https://github.com/Mogztter/antora-lunr].
> We need to build the index with the search UI in mind, i.e. the index needs
> to contain the data we wish to present in the UI as well as enough content
> for Algolia to be able to use the content to perform search. So starting with
> a mockup of what we wish to present/utilize in the search UI and deriving the
> data structure for the index from that would be a good start.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15145) Create a gRPC component based on vert.x
[ https://issues.apache.org/jira/browse/CAMEL-15145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123383#comment-17123383 ] James Netherton commented on CAMEL-15145: - Ok, that makes sense. Let me know if you find whether its possible to update the current component. > Create a gRPC component based on vert.x > --- > > Key: CAMEL-15145 > URL: https://issues.apache.org/jira/browse/CAMEL-15145 > Project: Camel > Issue Type: New Feature >Reporter: James Netherton >Priority: Minor > Fix For: 3.x > > > It'd be good for Quarkus integration if the the gRPC component could support > vertx-grpc (for both producer & consumer). > Not sure if it's feasible or correct to modify the existing camel-grpc > component to support this. Hence I propose a new component. > [~dmvolod] what do you think? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-15142) Build a Documentation Under Constructions handlebar
[ https://issues.apache.org/jira/browse/CAMEL-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aemie updated CAMEL-15142: -- Description: * I observed that for certain pages including [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-zookeeper.html] & [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-consul.html], the documentation is yet not written however published on the website. So in such cases, I believe it is a good practice to include a construction page handlebar as a user would be informed about if documentation is yet to be made or not. * What are your opinions on this, [~zregvart]? was: * I observed that for certain pages including [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-zookeeper.html] & [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-consul.html], the documentation is yet not written however published on the website. So in such cases, I believe it is a good practice to include a construction page handlebar as a user would be informed about if documentation is yet to be made or not. * What are your opinions on this? > Build a Documentation Under Constructions handlebar > --- > > Key: CAMEL-15142 > URL: https://issues.apache.org/jira/browse/CAMEL-15142 > Project: Camel > Issue Type: Task >Reporter: Aemie >Priority: Major > Labels: outreachy2020 > > * I observed that for certain pages including > [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-zookeeper.html] > & > [https://camel.apache.org/camel-spring-boot/latest/spring-cloud-consul.html], > the documentation is yet not written however published on the website. So in > such cases, I believe it is a good practice to include a construction page > handlebar as a user would be informed about if documentation is yet to be > made or not. > * What are your opinions on this, [~zregvart]? -- This message was sent by Atlassian Jira (v8.3.4#803005)
