[jira] [Resolved] (CAMEL-10381) camel-google-mail getting NPE from component configuration
[ https://issues.apache.org/jira/browse/CAMEL-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-10381. - Resolution: Fixed Fix Version/s: 2.17.3 [janstey@ghost camel-google-mail]$ git push Counting objects: 39, done. Delta compression using up to 8 threads. Compressing objects: 100% (27/27), done. Writing objects: 100% (39/39), 4.29 KiB | 0 bytes/s, done. Total 39 (delta 13), reused 0 (delta 0) remote: camel git commit: CAMEL-10381 - fix NPE from component configuration remote: camel git commit: CAMEL-10381 - fix NPE from component configuration remote: camel git commit: CAMEL-10381 - fix NPE from component configuration To https://git-wip-us.apache.org/repos/asf/camel.git 9fc87f2..592e7cf camel-2.17.x -> camel-2.17.x fa1789a..37a12df camel-2.18.x -> camel-2.18.x da614b7..5d79ddc master -> master > camel-google-mail getting NPE from component configuration > -- > > Key: CAMEL-10381 > URL: https://issues.apache.org/jira/browse/CAMEL-10381 > Project: Camel > Issue Type: Bug >Affects Versions: 2.18.0 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.19.0, 2.18.1, 2.17.3 > > > From forums: > When i run the application and start the route i get an NPE which points to > org.apache.camel.component.google.mail.GoogleMailComponent.getClient(GoogleMailComponent.java:50 > as the culprit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10381) camel-google-mail getting NPE from component configuration
Jonathan Anstey created CAMEL-10381: --- Summary: camel-google-mail getting NPE from component configuration Key: CAMEL-10381 URL: https://issues.apache.org/jira/browse/CAMEL-10381 Project: Camel Issue Type: Bug Affects Versions: 2.18.0 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.19.0, 2.18.1 >From forums: When i run the application and start the route i get an NPE which points to org.apache.camel.component.google.mail.GoogleMailComponent.getClient(GoogleMailComponent.java:50 as the culprit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-10243) Force camel-atom feature to install abdera-parser
[ https://issues.apache.org/jira/browse/CAMEL-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419183#comment-15419183 ] Jonathan Anstey commented on CAMEL-10243: - [janstey@ghost features]$ git push origin Counting objects: 18, done. Delta compression using up to 8 threads. Compressing objects: 100% (14/14), done. Writing objects: 100% (18/18), 1.32 KiB | 0 bytes/s, done. Total 18 (delta 10), reused 0 (delta 0) remote: camel git commit: CAMEL-10243 - Force camel-atom feature to install abdera-parser remote: camel git commit: CAMEL-10243 - Force camel-atom feature to install abdera-parser To https://git-wip-us.apache.org/repos/asf/camel.git 291ea10..e500ce3 camel-2.17.x -> camel-2.17.x e3c9f1b..db1f8ea master -> master > Force camel-atom feature to install abdera-parser > - > > Key: CAMEL-10243 > URL: https://issues.apache.org/jira/browse/CAMEL-10243 > Project: Camel > Issue Type: Bug >Affects Versions: 2.17.3 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.18.0, 2.17.4 > > > Abdera-parser is already in the camel-atom feature but because camel-atom > bundle has no compile dependency on it, it doesn't actually get installed > with the feature. The parser is almost always required though so would be > nice to always install this so folks don't have to install additional bundles > after the camel-atom feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-10243) Force camel-atom feature to install abdera-parser
[ https://issues.apache.org/jira/browse/CAMEL-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-10243. - Resolution: Fixed Fix Version/s: 2.17.4 2.18.0 > Force camel-atom feature to install abdera-parser > - > > Key: CAMEL-10243 > URL: https://issues.apache.org/jira/browse/CAMEL-10243 > Project: Camel > Issue Type: Bug >Affects Versions: 2.17.3 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.18.0, 2.17.4 > > > Abdera-parser is already in the camel-atom feature but because camel-atom > bundle has no compile dependency on it, it doesn't actually get installed > with the feature. The parser is almost always required though so would be > nice to always install this so folks don't have to install additional bundles > after the camel-atom feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10243) Force camel-atom feature to install abdera-parser
Jonathan Anstey created CAMEL-10243: --- Summary: Force camel-atom feature to install abdera-parser Key: CAMEL-10243 URL: https://issues.apache.org/jira/browse/CAMEL-10243 Project: Camel Issue Type: Bug Affects Versions: 2.17.3 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Abdera-parser is already in the camel-atom feature but because camel-atom bundle has no compile dependency on it, it doesn't actually get installed with the feature. The parser is almost always required though so would be nice to always install this so folks don't have to install additional bundles after the camel-atom feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-10011) Overlap in management name for multiple contexts in OSGi bundle
[ https://issues.apache.org/jira/browse/CAMEL-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-10011. - Resolution: Fixed > Overlap in management name for multiple contexts in OSGi bundle > --- > > Key: CAMEL-10011 > URL: https://issues.apache.org/jira/browse/CAMEL-10011 > Project: Camel > Issue Type: Bug >Affects Versions: 2.17.1 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.2, 2.18.0 > > > Problem is that OsgiManagementNameStrategy uses only the bundle symbolic name > for the management name used for each CamelContext. So if you have multiple > CamelContexts per bundle this creates overlap in the naming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10011) Overlap in management name for multiple contexts in OSGi bundle
Jonathan Anstey created CAMEL-10011: --- Summary: Overlap in management name for multiple contexts in OSGi bundle Key: CAMEL-10011 URL: https://issues.apache.org/jira/browse/CAMEL-10011 Project: Camel Issue Type: Bug Affects Versions: 2.17.1 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.17.2, 2.18.0 Problem is that OsgiManagementNameStrategy uses only the bundle symbolic name for the management name used for each CamelContext. So if you have multiple CamelContexts per bundle this creates overlap in the naming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9900) camel-jms - provide option for MessageListenerContainer for reply managers to stop quicker when CamelContext is stopping
[
https://issues.apache.org/jira/browse/CAMEL-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-9900.
Resolution: Fixed
> camel-jms - provide option for MessageListenerContainer for reply managers to
> stop quicker when CamelContext is stopping
>
>
> Key: CAMEL-9900
> URL: https://issues.apache.org/jira/browse/CAMEL-9900
> Project: Camel
> Issue Type: Improvement
> Components: camel-jms
>Reporter: Jonathan Anstey
>Assignee: Jonathan Anstey
> Fix For: 2.17.1, 2.18.0
>
>
> CAMEL-7667 included a fix for the DMLC used in JMS consumers to stop quickly
> if the CameContext is already shutting down. This helps avoid spring-jms
> getting into a bad state with a null sharedConnection which has a telling
> stack like:
> {code}
> 2014-08-07 10:33:42,975 [sonnel.records]] ERROR
> ultJmsMessageListenerContainer - Could not refresh JMS Connection for
> destination 'personnel.records' - retrying in 5000 ms. Cause: null
> java.lang.NullPointerException
> at
> org.springframework.jms.listener.AbstractJmsListeningContainer.refreshSharedConnection(AbstractJmsListeningContainer.java:392)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful(DefaultMessageListenerContainer.java:885)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer.recoverAfterListenerSetupFailure(DefaultMessageListenerContainer.java:861)
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1012)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> This can also occur in the DMLC used for request-reply messaging. We should
> provide an option for this to be enabled because usually this is not an issue
> and you don't mind waiting for a while for replies to come in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9900) camel-jms - provide option for MessageListenerContainer for reply managers to stop quicker when CamelContext is stopping
Jonathan Anstey created CAMEL-9900:
--
Summary: camel-jms - provide option for MessageListenerContainer
for reply managers to stop quicker when CamelContext is stopping
Key: CAMEL-9900
URL: https://issues.apache.org/jira/browse/CAMEL-9900
Project: Camel
Issue Type: Improvement
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.17.1, 2.18.0
CAMEL-7667 included a fix for the DMLC used in JMS consumers to stop quickly if
the CameContext is already shutting down. This helps avoid spring-jms getting
into a bad state with a null sharedConnection which has a telling stack like:
{code}
2014-08-07 10:33:42,975 [sonnel.records]] ERROR ultJmsMessageListenerContainer
- Could not refresh JMS Connection for destination 'personnel.records' -
retrying in 5000 ms. Cause: null
java.lang.NullPointerException
at
org.springframework.jms.listener.AbstractJmsListeningContainer.refreshSharedConnection(AbstractJmsListeningContainer.java:392)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful(DefaultMessageListenerContainer.java:885)
at
org.springframework.jms.listener.DefaultMessageListenerContainer.recoverAfterListenerSetupFailure(DefaultMessageListenerContainer.java:861)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1012)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{code}
This can also occur in the DMLC used for request-reply messaging. We should
provide an option for this to be enabled because usually this is not an issue
and you don't mind waiting for a while for replies to come in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9838) Add ends with operator to simple language
[ https://issues.apache.org/jira/browse/CAMEL-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-9838. Resolution: Fixed https://github.com/apache/camel/commit/ff085260d530e7bc5b23c124acdca8094739ee7d > Add ends with operator to simple language > - > > Key: CAMEL-9838 > URL: https://issues.apache.org/jira/browse/CAMEL-9838 > Project: Camel > Issue Type: Improvement >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.1 > > > We have endsWith available via PredicateBuilder in the Java DSL. Would be > nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9838) Add ends with operator to simple language
[ https://issues.apache.org/jira/browse/CAMEL-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-9838: --- Fix Version/s: 2.18.0 > Add ends with operator to simple language > - > > Key: CAMEL-9838 > URL: https://issues.apache.org/jira/browse/CAMEL-9838 > Project: Camel > Issue Type: Improvement >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.17.1, 2.18.0 > > > We have endsWith available via PredicateBuilder in the Java DSL. Would be > nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9838) Add ends with operator to simple language
Jonathan Anstey created CAMEL-9838: -- Summary: Add ends with operator to simple language Key: CAMEL-9838 URL: https://issues.apache.org/jira/browse/CAMEL-9838 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.17.1 We have endsWith available via PredicateBuilder in the Java DSL. Would be nice to have this in simple so it could be used in XML DSL as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9543) Discovering new type converters in OSGi wipes out those manually added
Jonathan Anstey created CAMEL-9543:
--
Summary: Discovering new type converters in OSGi wipes out those
manually added
Key: CAMEL-9543
URL: https://issues.apache.org/jira/browse/CAMEL-9543
Project: Camel
Issue Type: Bug
Affects Versions: 2.15.5
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
When adding a type converter manually like:
{code}
getContext().getTypeConverterRegistry().addTypeConverter(A.class, B.class, new
ABConverter());
{code}
It gets removed from the type converter registry when a new type converter is
discovered in a newly installed bundle. (Like when you install camel-hl7
feature in Karaf say).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9543) Discovering new type converters in OSGi wipes out those manually added
[
https://issues.apache.org/jira/browse/CAMEL-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-9543.
Resolution: Fixed
Fix Version/s: 2.17.0
2.16.2
2.15.6
[janstey@bender camel-core-osgi]$ git push origin
Counting objects: 30, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (30/30), 2.33 KiB | 0 bytes/s, done.
Total 30 (delta 10), reused 0 (delta 0)
To https://git-wip-us.apache.org/repos/asf/camel.git
cb67fe9..508c1df camel-2.15.x -> camel-2.15.x
b4f2374..206a464 camel-2.16.x -> camel-2.16.x
e4223b9..d3bfca9 master -> master
[janstey@bender camel-core-osgi]$
> Discovering new type converters in OSGi wipes out those manually added
> --
>
> Key: CAMEL-9543
> URL: https://issues.apache.org/jira/browse/CAMEL-9543
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.5
>Reporter: Jonathan Anstey
>Assignee: Jonathan Anstey
> Fix For: 2.15.6, 2.16.2, 2.17.0
>
>
> When adding a type converter manually like:
> {code}
> getContext().getTypeConverterRegistry().addTypeConverter(A.class, B.class,
> new ABConverter());
> {code}
> It gets removed from the type converter registry when a new type converter is
> discovered in a newly installed bundle. (Like when you install camel-hl7
> feature in Karaf say).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9526) Blueprint depends-on can no longer contain multiple bean ids
[
https://issues.apache.org/jira/browse/CAMEL-9526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-9526.
Resolution: Fixed
Fix Version/s: 2.16.2
2.15.6
To https://git-wip-us.apache.org/repos/asf/camel.git
91fbaa4..1805c6b camel-2.15.x -> camel-2.15.x
eaefb7c..ea6262b camel-2.16.x -> camel-2.16.x
6705ca9..b6355ae master -> master
> Blueprint depends-on can no longer contain multiple bean ids
>
>
> Key: CAMEL-9526
> URL: https://issues.apache.org/jira/browse/CAMEL-9526
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.3, 2.16.0
>Reporter: Jonathan Anstey
>Assignee: Jonathan Anstey
> Fix For: 2.15.6, 2.16.2, 2.17.0
>
>
> Used to be able to do something like:
> {code}
>
>
> http://camel.apache.org/schema/blueprint;
> id="testCamelContext" depends-on="id1 id2"/>
> {code}
> Now as of 2.16 and 2.15.3 we get the following:
> {code}
> 2016-01-20 16:44:07,541 | ERROR | rint Extender: 1 | BlueprintContainerImpl
> | 12 - org.apache.aries.blueprint.core - 1.4.3 | Unable to start
> blueprint container for bundle camelContext.xml
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unresolved
> ref/idref to component: id1 id2
> at
> org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.RecipeBuilder.createRepository(RecipeBuilder.java:96)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.getRepository(BlueprintContainerImpl.java:481)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:328)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
> at
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9526) Blueprint depends-on can no longer contain multiple bean ids
Jonathan Anstey created CAMEL-9526:
--
Summary: Blueprint depends-on can no longer contain multiple bean
ids
Key: CAMEL-9526
URL: https://issues.apache.org/jira/browse/CAMEL-9526
Project: Camel
Issue Type: Bug
Affects Versions: 2.16.0, 2.15.3
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.17.0
Used to be able to do something like:
{code}
http://camel.apache.org/schema/blueprint;
id="testCamelContext" depends-on="id1 id2"/>
{code}
Now as of 2.16 and 2.15.3 we get the following:
{code}
2016-01-20 16:44:07,541 | ERROR | rint Extender: 1 | BlueprintContainerImpl
| 12 - org.apache.aries.blueprint.core - 1.4.3 | Unable to start
blueprint container for bundle camelContext.xml
org.osgi.service.blueprint.container.ComponentDefinitionException: Unresolved
ref/idref to component: id1 id2
at
org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.RecipeBuilder.createRepository(RecipeBuilder.java:96)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.getRepository(BlueprintContainerImpl.java:481)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:328)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)[12:org.apache.aries.blueprint.core:1.4.3]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
at
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)[12:org.apache.aries.blueprint.core:1.4.3]
at
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.3]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9368) Netty4 producer hangs when connection is prematurely closed
[ https://issues.apache.org/jira/browse/CAMEL-9368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033672#comment-15033672 ] Jonathan Anstey commented on CAMEL-9368: Darn :-) I have to look into another Netty issue anyways later this week so will try and revisit this one too. > Netty4 producer hangs when connection is prematurely closed > --- > > Key: CAMEL-9368 > URL: https://issues.apache.org/jira/browse/CAMEL-9368 > Project: Camel > Issue Type: Bug >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.16.2, 2.15.5, 2.17.0 > > > Netty4 producer is reusing connections and implementing a request-response > style protocol. If the server closes socket connection after reading request > packet and prior to sending back response packet, Netty4 producer hangs. If, > on the other hand, the server closes socket after sending back response and > does not bother to read next request, then producer does not hang. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9368) Netty4 producer hangs when connection is prematurely closed
Jonathan Anstey created CAMEL-9368: -- Summary: Netty4 producer hangs when connection is prematurely closed Key: CAMEL-9368 URL: https://issues.apache.org/jira/browse/CAMEL-9368 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.17.0 Netty4 producer is reusing connections and implementing a request-response style protocol. If the server closes socket connection after reading request packet and prior to sending back response packet, Netty4 producer hangs. If, on the other hand, the server closes socket after sending back response and does not bother to read next request, then producer does not hang. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9290) netty4 consumer in clientMode only reconnects once
[ https://issues.apache.org/jira/browse/CAMEL-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-9290. Resolution: Fixed Fix Version/s: 2.17.0 http://git-wip-us.apache.org/repos/asf/camel/commit/79396207 > netty4 consumer in clientMode only reconnects once > -- > > Key: CAMEL-9290 > URL: https://issues.apache.org/jira/browse/CAMEL-9290 > Project: Camel > Issue Type: Bug >Affects Versions: 2.16.0 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.16.1, 2.17.0 > > > Currently, when the server goes down the first time, it will reconnect fine. > But if the server goes down again later, it will not attempt a reconnect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9290) netty4 consumer in clientMode only reconnects once
Jonathan Anstey created CAMEL-9290: -- Summary: netty4 consumer in clientMode only reconnects once Key: CAMEL-9290 URL: https://issues.apache.org/jira/browse/CAMEL-9290 Project: Camel Issue Type: Bug Affects Versions: 2.16.0 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.1 Currently, when the server goes down the first time, it will reconnect fine. But if the server goes down again later, it will not attempt a reconnect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9223) IllegalArgumentException when reverting fields using property placeholders
Jonathan Anstey created CAMEL-9223:
--
Summary: IllegalArgumentException when reverting fields using
property placeholders
Key: CAMEL-9223
URL: https://issues.apache.org/jira/browse/CAMEL-9223
Project: Camel
Issue Type: Bug
Affects Versions: 2.16.0
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.17.0, 2.16.1
When using a route like
{code}
http://camel.apache.org/schema/spring;>
http://camel.apache.org/schema/spring; />
{code}
The following exception is thrown:
{code}
java.lang.IllegalArgumentException: Could not find a suitable setter for
property: stopOnException as there isn't a setter method with same type:
java.lang.String nor type conversion possible: {{stop}}
at
org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:561)
at
org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:571)
at
org.apache.camel.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:454)
at
org.apache.camel.model.ProcessorDefinitionHelper$1.run(ProcessorDefinitionHelper.java:623)
at
org.apache.camel.model.ProcessorDefinitionHelper$RestoreAction.run(ProcessorDefinitionHelper.java:572)
at
org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:491)
at
org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:218)
at
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1025)
at
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:185)
at
org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:841)
at
org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:2895)
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2618)
at
org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:167)
at
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2467)
at
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2463)
at
org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2486)
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2463)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2432)
at
org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:255)
at
org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:121)
at
org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:332)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:96)
at
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:334)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:950)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at
org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
at
org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9223) IllegalArgumentException when reverting fields using property placeholders
[
https://issues.apache.org/jira/browse/CAMEL-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-9223.
Resolution: Fixed
[janstey@bender camel-core]$ git push origin
Counting objects: 22, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (22/22), 2.00 KiB | 0 bytes/s, done.
Total 22 (delta 9), reused 0 (delta 0)
To https://git-wip-us.apache.org/repos/asf/camel.git
d444e86..b09b1a6 camel-2.16.x -> camel-2.16.x
52a9b2b..d84594d master -> master
> IllegalArgumentException when reverting fields using property placeholders
> --
>
> Key: CAMEL-9223
> URL: https://issues.apache.org/jira/browse/CAMEL-9223
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Jonathan Anstey
>Assignee: Jonathan Anstey
> Fix For: 2.17.0, 2.16.1
>
>
> When using a route like
> {code}
> http://camel.apache.org/schema/spring;>
>xmlns="http://camel.apache.org/schema/spring; />
>
>
>
>
>
>
>
>
> {code}
> The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Could not find a suitable setter for
> property: stopOnException as there isn't a setter method with same type:
> java.lang.String nor type conversion possible: {{stop}}
> at
> org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:561)
> at
> org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:571)
> at
> org.apache.camel.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:454)
> at
> org.apache.camel.model.ProcessorDefinitionHelper$1.run(ProcessorDefinitionHelper.java:623)
> at
> org.apache.camel.model.ProcessorDefinitionHelper$RestoreAction.run(ProcessorDefinitionHelper.java:572)
> at
> org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:491)
> at
> org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:218)
> at
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1025)
> at
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:185)
> at
> org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:841)
> at
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:2895)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2618)
> at
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:167)
> at
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2467)
> at
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2463)
> at
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2486)
> at
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2463)
> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> at
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2432)
> at
> org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:255)
> at
> org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:121)
> at
> org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:332)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:96)
> at
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:334)
> at
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:950)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
> at
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
> at
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9208) camel-netty4-http does not resolve nettyHttpBinding option
[ https://issues.apache.org/jira/browse/CAMEL-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-9208. Resolution: Fixed [janstey@bender camel-netty4-http]$ git push origin Counting objects: 32, done. Delta compression using up to 8 threads. Compressing objects: 100% (20/20), done. Writing objects: 100% (32/32), 2.50 KiB | 0 bytes/s, done. Total 32 (delta 10), reused 0 (delta 0) To https://git-wip-us.apache.org/repos/asf/camel.git 44a07f9..ae9f291 camel-2.15.x -> camel-2.15.x c1e0f30..0f09a86 camel-2.16.x -> camel-2.16.x 805ec4c..4b3bbf8 master -> master > camel-netty4-http does not resolve nettyHttpBinding option > -- > > Key: CAMEL-9208 > URL: https://issues.apache.org/jira/browse/CAMEL-9208 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3, 2.16.0 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.15.4, 2.17.0, 2.16.1 > > > camel-netty4-http does not resolve or strip out the "nettyHttpBinding" > endpoint option. For example, take the following route producer: > uri="netty4-http:http://www.google.com:80?nettyHttpBinding=#myHttpBinding; /> > It will issue the following HTTP GET request URI: > GET http://www.google.com:80?nettyHttpBinding=%23myHttpBinding HTTP/1.1 > Assigning any of the other endpoint options, results in those options being > removed from the GET request URI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9208) camel-netty4-http does not resolve nettyHttpBinding option
Jonathan Anstey created CAMEL-9208: -- Summary: camel-netty4-http does not resolve nettyHttpBinding option Key: CAMEL-9208 URL: https://issues.apache.org/jira/browse/CAMEL-9208 Project: Camel Issue Type: Bug Affects Versions: 2.16.0, 2.15.3 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.4, 2.17.0, 2.16.1 camel-netty4-http does not resolve or strip out the "nettyHttpBinding" endpoint option. For example, take the following route producer: http://www.google.com:80?nettyHttpBinding=#myHttpBinding; /> It will issue the following HTTP GET request URI: GET http://www.google.com:80?nettyHttpBinding=%23myHttpBinding HTTP/1.1 Assigning any of the other endpoint options, results in those options being removed from the GET request URI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8975) camel-kafka - Message loss with batch commit
[ https://issues.apache.org/jira/browse/CAMEL-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14736711#comment-14736711 ] Jonathan Anstey commented on CAMEL-8975: [~mcoyote] would you mind submitting a PR for this? Sounds like an awesome improvement! > camel-kafka - Message loss with batch commit > > > Key: CAMEL-8975 > URL: https://issues.apache.org/jira/browse/CAMEL-8975 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 2.15.2 > Environment: Unbuntu LTS 14.x, Java 7 >Reporter: Michael J. Kitchin > > These issues center around Kafka consumer (KafaConsumer.java, line numbers > below): > # Exchange exceptions/failures ignored at process() (:148), meaning: > ## Automatic offset commit on exchange failure (e.g., processor/endpoint > exception) > ## In-flight exchange loss on Camel context/runtime shutdown (i.e., route > interrupted -> exception suppressed -> offset committed) > # BatchCommitConsumerTask activations are unbalanced during periods of low > activity, meaning: > ## await() (:165) will timeout for active BatchCommitConsumerTask(s) when > other consumer threads are binding on it.hasNext() (:145) (blocking call, > despite no @throws) > ## Any, previously-activated await()'ing thread will (a) get a > TimeoutExeception, (b) loop, and (c) get a BrokenBarrierException on the next > await() call and (d) exit > ## Process will repeat until (a) all consumer stream threads have exited, (b) > leaving consumer dead > ## Aggravated if process() (:148) blocks (e.g., for delay/redelivery on the > route) > # An ExecutorService is obtained from Camel to handle KafkaStreams with # of > threads set to the consumerStreams param (:77). Since the # of KafkaStreams > actually created is (consumersCount * consumerStreams) and executor runnables > are indefinite loops, a random selection of streams will not be serviced if > consumersCount>1. > Source code URL: > - > https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaConsumer.java > We've troubleshot this extensively and reimplemented the KafkaConsumer class > with params added to KafkaConfiguration to address these concerns and are > happy to submit these back to the community, if interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9086) Add support for relative path requests in netty http
[ https://issues.apache.org/jira/browse/CAMEL-9086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-9086. Resolution: Fixed Add support for relative path requests in netty http Key: CAMEL-9086 URL: https://issues.apache.org/jira/browse/CAMEL-9086 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 Some third party backend systems such as IBM Datapower do not support absolute URIs in HTTP POSTs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9086) Add support for relative path requests in netty http
Jonathan Anstey created CAMEL-9086: -- Summary: Add support for relative path requests in netty http Key: CAMEL-9086 URL: https://issues.apache.org/jira/browse/CAMEL-9086 Project: Camel Issue Type: Improvement Affects Versions: 2.15.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 Some third party backend systems such as IBM Datapower do not support absolute URIs in HTTP POSTs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9003) Allow multiple producers with differing request timeouts
Jonathan Anstey created CAMEL-9003: -- Summary: Allow multiple producers with differing request timeouts Key: CAMEL-9003 URL: https://issues.apache.org/jira/browse/CAMEL-9003 Project: Camel Issue Type: Improvement Components: camel-netty, camel-netty4 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 User reported that Camel is 'caching' the timeout setting on outgoing netty calls, so the first call out it would be using the correct timeout setting, but subsequent outgoing calls with different timeout settings Camel would still use the same initial timeout given instead of the new one. So usually you would override these kind of things in headers for each request... but you can't just change the timeout value for each call in netty, you'd have to reconstruct the entire channel pipeline... which would be a bit expensive :-) Solution is to add requestTimeout to key for ProducerCache so we get distinct producers with different requestTimeout values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9005) Yammer - Endpoint received does not work
Jonathan Anstey created CAMEL-9005: -- Summary: Yammer - Endpoint received does not work Key: CAMEL-9005 URL: https://issues.apache.org/jira/browse/CAMEL-9005 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9003) Allow multiple producers with differing request timeouts
[ https://issues.apache.org/jira/browse/CAMEL-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638759#comment-14638759 ] Jonathan Anstey commented on CAMEL-9003: Yeah, I agree it isn't ideal. Ideal would have been to use a header override for this... but at least now you can have more than one timeout :-) Allow multiple producers with differing request timeouts Key: CAMEL-9003 URL: https://issues.apache.org/jira/browse/CAMEL-9003 Project: Camel Issue Type: Improvement Components: camel-netty, camel-netty4 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 User reported that Camel is 'caching' the timeout setting on outgoing netty calls, so the first call out it would be using the correct timeout setting, but subsequent outgoing calls with different timeout settings Camel would still use the same initial timeout given instead of the new one. So usually you would override these kind of things in headers for each request... but you can't just change the timeout value for each call in netty, you'd have to reconstruct the entire channel pipeline... which would be a bit expensive :-) Solution is to add requestTimeout to key for ProducerCache so we get distinct producers with different requestTimeout values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9003) Allow multiple producers with differing request timeouts
[ https://issues.apache.org/jira/browse/CAMEL-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14639275#comment-14639275 ] Jonathan Anstey commented on CAMEL-9003: I was assuming that modifying the channel pipeline would be a really expensive thing to do but in reality over a lot of messages the difference is minimal. It was only slightly slower to use a header over 100K messages: 10 messages with timeout set via header: 27101ms. 10 messages with timeout set via uri: 26615ms. After http://git-wip-us.apache.org/repos/asf/camel/commit/b587d402 you can now use a CamelNettyRequestTimneout header to override this setting. Allow multiple producers with differing request timeouts Key: CAMEL-9003 URL: https://issues.apache.org/jira/browse/CAMEL-9003 Project: Camel Issue Type: Improvement Components: camel-netty, camel-netty4 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 User reported that Camel is 'caching' the timeout setting on outgoing netty calls, so the first call out it would be using the correct timeout setting, but subsequent outgoing calls with different timeout settings Camel would still use the same initial timeout given instead of the new one. So usually you would override these kind of things in headers for each request... but you can't just change the timeout value for each call in netty, you'd have to reconstruct the entire channel pipeline... which would be a bit expensive :-) Solution is to add requestTimeout to key for ProducerCache so we get distinct producers with different requestTimeout values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9003) Allow multiple producers with differing request timeouts
[ https://issues.apache.org/jira/browse/CAMEL-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-9003. Resolution: Fixed Allow multiple producers with differing request timeouts Key: CAMEL-9003 URL: https://issues.apache.org/jira/browse/CAMEL-9003 Project: Camel Issue Type: Improvement Components: camel-netty, camel-netty4 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 User reported that Camel is 'caching' the timeout setting on outgoing netty calls, so the first call out it would be using the correct timeout setting, but subsequent outgoing calls with different timeout settings Camel would still use the same initial timeout given instead of the new one. So usually you would override these kind of things in headers for each request... but you can't just change the timeout value for each call in netty, you'd have to reconstruct the entire channel pipeline... which would be a bit expensive :-) Solution is to add requestTimeout to key for ProducerCache so we get distinct producers with different requestTimeout values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8988) Can't manually trigger quartz2 jobs
Jonathan Anstey created CAMEL-8988: -- Summary: Can't manually trigger quartz2 jobs Key: CAMEL-8988 URL: https://issues.apache.org/jira/browse/CAMEL-8988 Project: Camel Issue Type: Bug Components: camel-quartz2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 Using org.quartz.Scheduler.triggerJob to manually trigger jobs will result in an exception like: 2015-07-20 16:17:28,295 [amel-1_Worker-1] ERROR CamelJob - Failed to execute CamelJob. org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: quartz2://MyTimer?cron=05+00+00+*+*+%3F due to: Trigger key Camel.MyTimer is already in use by Endpoint[quartz2://MyTimer?cron=05+00+00+*+*+%3F] Problem is that CamelJob is having trouble with looking up the proper endpoint from a previously saved URI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8989) SJMS drops messages with null body even if allowNullBody is true
Jonathan Anstey created CAMEL-8989: -- Summary: SJMS drops messages with null body even if allowNullBody is true Key: CAMEL-8989 URL: https://issues.apache.org/jira/browse/CAMEL-8989 Project: Camel Issue Type: Bug Components: camel-sjms Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8988) Can't manually trigger quartz2 jobs
[ https://issues.apache.org/jira/browse/CAMEL-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8988. Resolution: Fixed Can't manually trigger quartz2 jobs --- Key: CAMEL-8988 URL: https://issues.apache.org/jira/browse/CAMEL-8988 Project: Camel Issue Type: Bug Components: camel-quartz2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 Using org.quartz.Scheduler.triggerJob to manually trigger jobs will result in an exception like: 2015-07-20 16:17:28,295 [amel-1_Worker-1] ERROR CamelJob - Failed to execute CamelJob. org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: quartz2://MyTimer?cron=05+00+00+*+*+%3F due to: Trigger key Camel.MyTimer is already in use by Endpoint[quartz2://MyTimer?cron=05+00+00+*+*+%3F] Problem is that CamelJob is having trouble with looking up the proper endpoint from a previously saved URI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8989) SJMS drops messages with null body even if allowNullBody is true
[ https://issues.apache.org/jira/browse/CAMEL-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8989. Resolution: Fixed SJMS drops messages with null body even if allowNullBody is true Key: CAMEL-8989 URL: https://issues.apache.org/jira/browse/CAMEL-8989 Project: Camel Issue Type: Bug Components: camel-sjms Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8949) Netty 3 component spins on receiving TCP RST
Jonathan Anstey created CAMEL-8949:
--
Summary: Netty 3 component spins on receiving TCP RST
Key: CAMEL-8949
URL: https://issues.apache.org/jira/browse/CAMEL-8949
Project: Camel
Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.16.0, 2.15.3
When receiving a TCP RST, Netty 3 goes into a deep recursion identified by a
stack something like:
{code}
[Camel Thread #1 - NettyServerTCPWorker] WARN
org.apache.camel.component.netty.http.NettyHttpConsumer -
HttpServerChannelHandler is not found as attachment to handle exception, send
404 back to the client.
java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
at
org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
at org.jboss.netty.channel.Channels.write(Channels.java:725)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
at org.jboss.netty.channel.Channels.write(Channels.java:704)
at org.jboss.netty.channel.Channels.write(Channels.java:671)
at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at
org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.exceptionCaught(HttpServerMultiplexChannelHandler.java:142)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChannelUpstreamHandler.java:153)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:377)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:525)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:291)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
at org.jboss.netty.channel.Channels.write(Channels.java:725)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
[jira] [Created] (CAMEL-8950) Injected Quartz2 scheduler doesn't have access to CamelContext in jobs
Jonathan Anstey created CAMEL-8950: -- Summary: Injected Quartz2 scheduler doesn't have access to CamelContext in jobs Key: CAMEL-8950 URL: https://issues.apache.org/jira/browse/CAMEL-8950 Project: Camel Issue Type: Bug Affects Versions: 2.15.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 Currently if you inject a scheduler the CamelContext won't be available for jobs to access. When the scheduler is created automatically, the context is added to the quartz scheduler context so the jobs can access it: quartzContext.put(QuartzConstants.QUARTZ_CAMEL_CONTEXT + - + camelContextName, getCamelContext()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8949) Netty 3 component spins on receiving TCP RST
[
https://issues.apache.org/jira/browse/CAMEL-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-8949.
Resolution: Fixed
http://git-wip-us.apache.org/repos/asf/camel/commit/821bddf5
Netty 3 component spins on receiving TCP RST
Key: CAMEL-8949
URL: https://issues.apache.org/jira/browse/CAMEL-8949
Project: Camel
Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.16.0, 2.15.3
When receiving a TCP RST, Netty 3 goes into a deep recursion identified by a
stack something like:
{code}
[Camel Thread #1 - NettyServerTCPWorker] WARN
org.apache.camel.component.netty.http.NettyHttpConsumer -
HttpServerChannelHandler is not found as attachment to handle exception, send
404 back to the client.
java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
at
org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
at org.jboss.netty.channel.Channels.write(Channels.java:725)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
at org.jboss.netty.channel.Channels.write(Channels.java:704)
at org.jboss.netty.channel.Channels.write(Channels.java:671)
at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at
org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.exceptionCaught(HttpServerMultiplexChannelHandler.java:142)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChannelUpstreamHandler.java:153)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:377)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:525)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:291)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
at org.jboss.netty.channel.Channels.write(Channels.java:725)
at
[jira] [Updated] (CAMEL-8909) Jasypt CLI outputs help twice
[ https://issues.apache.org/jira/browse/CAMEL-8909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-8909: --- Priority: Minor (was: Major) Jasypt CLI outputs help twice - Key: CAMEL-8909 URL: https://issues.apache.org/jira/browse/CAMEL-8909 Project: Camel Issue Type: Bug Affects Versions: 2.15.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Priority: Minor Fix For: 2.16.0 Using -help results in the following output: [janstey@bender apache-camel-2.15.2]$ java -jar lib/camel-jasypt-2.15.2.jar -help Apache Camel Jasypt takes the following options -h or -help = Displays the help screen -c or -command command = Command either encrypt or decrypt -p or -password password = Password to use -i or -input input = Text to encrypt or decrypt -a or -algorithm algorithm = Optional algorithm to use Error: Command is empty Apache Camel Jasypt takes the following options -h or -help = Displays the help screen -c or -command command = Command either encrypt or decrypt -p or -password password = Password to use -i or -input input = Text to encrypt or decrypt -a or -algorithm algorithm = Optional algorithm to use -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8909) Jasypt CLI outputs help twice
[ https://issues.apache.org/jira/browse/CAMEL-8909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8909. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/cf447ac2 Jasypt CLI outputs help twice - Key: CAMEL-8909 URL: https://issues.apache.org/jira/browse/CAMEL-8909 Project: Camel Issue Type: Bug Affects Versions: 2.15.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Priority: Minor Fix For: 2.16.0 Using -help results in the following output: [janstey@bender apache-camel-2.15.2]$ java -jar lib/camel-jasypt-2.15.2.jar -help Apache Camel Jasypt takes the following options -h or -help = Displays the help screen -c or -command command = Command either encrypt or decrypt -p or -password password = Password to use -i or -input input = Text to encrypt or decrypt -a or -algorithm algorithm = Optional algorithm to use Error: Command is empty Apache Camel Jasypt takes the following options -h or -help = Displays the help screen -c or -command command = Command either encrypt or decrypt -p or -password password = Password to use -i or -input input = Text to encrypt or decrypt -a or -algorithm algorithm = Optional algorithm to use -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8560) camel-mail - Make it easier to configure sort term in XML DSL
[ https://issues.apache.org/jira/browse/CAMEL-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey reassigned CAMEL-8560: -- Assignee: Jonathan Anstey camel-mail - Make it easier to configure sort term in XML DSL - Key: CAMEL-8560 URL: https://issues.apache.org/jira/browse/CAMEL-8560 Project: Camel Issue Type: Improvement Components: camel-mail Reporter: Claus Ibsen Assignee: Jonathan Anstey Fix For: 2.16.0 See nabble http://camel.465427.n5.nabble.com/SortTerm-in-Spring-XML-tp5764866.html SortTerm is not an enum so we may need to add a type converter fro String - SortTerm. And then allow sort.XXX in the uri style to setup this easier like you can do wtih search term. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8560) camel-mail - Make it easier to configure sort term in XML DSL
[ https://issues.apache.org/jira/browse/CAMEL-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8560. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/edabde20 camel-mail - Make it easier to configure sort term in XML DSL - Key: CAMEL-8560 URL: https://issues.apache.org/jira/browse/CAMEL-8560 Project: Camel Issue Type: Improvement Components: camel-mail Reporter: Claus Ibsen Assignee: Jonathan Anstey Fix For: 2.16.0 See nabble http://camel.465427.n5.nabble.com/SortTerm-in-Spring-XML-tp5764866.html SortTerm is not an enum so we may need to add a type converter fro String - SortTerm. And then allow sort.XXX in the uri style to setup this easier like you can do wtih search term. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8710) Make auth configurable for Google app components
Jonathan Anstey created CAMEL-8710: -- Summary: Make auth configurable for Google app components Key: CAMEL-8710 URL: https://issues.apache.org/jira/browse/CAMEL-8710 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.2, 2.16.0 Right now we auth against google user accounts only (see https://github.com/apache/camel/blob/master/components/camel-google-calendar/src/main/java/org/apache/camel/component/google/calendar/BatchGoogleCalendarClientFactory.java) but there are also other options like service accounts. Should make this pluggable so folks can use whatever they want. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8710) Make auth configurable for Google app components
[ https://issues.apache.org/jira/browse/CAMEL-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8710. Resolution: Fixed https://github.com/apache/camel/commit/d57437c663e4218ce2525e0ce6082411e37b00b9 Make auth configurable for Google app components Key: CAMEL-8710 URL: https://issues.apache.org/jira/browse/CAMEL-8710 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.2, 2.16.0 Right now we auth against google user accounts only (see https://github.com/apache/camel/blob/master/components/camel-google-calendar/src/main/java/org/apache/camel/component/google/calendar/BatchGoogleCalendarClientFactory.java) but there are also other options like service accounts. Should make this pluggable so folks can use whatever they want. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8676) Camel smtp causes error if email address have character ''
[
https://issues.apache.org/jira/browse/CAMEL-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-8676.
Resolution: Not A Problem
Assignee: Jonathan Anstey
You need to use the raw value of the property to handle special characters like
. See
http://camel.apache.org/how-do-i-configure-password-options-on-camel-endpoints-without-the-value-being-encoded.html.
I just added a note to the camel-mail wiki docs about this.
Camel smtp causes error if email address have character ''
---
Key: CAMEL-8676
URL: https://issues.apache.org/jira/browse/CAMEL-8676
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.12.0, 2.15.0
Environment: All
Reporter: JaySenSharma
Assignee: Jonathan Anstey
Attachments: Spring_Based_Camel_SMTP.zip
- If a camel mail route contains an E-Mail address containing '' symbol in
it then trhe camel route fails to start.
Example:
===
{code}
camelContext trace=true
xmlns=http://camel.apache.org/schema/blueprint;
route
from uri=timer://foo?delay=2samp;repeatCount=1/
to
uri=smtp://test.mail.com:25?To=useramp;1...@gmail.comamp;From=jsens...@gmail.com
/
!-- Sending mail using smtp when the email address
contains '' character like user1...@gmail.com Caues issue--
/route
/camelContext
{code}
- Where as, As per the http://en.wikipedia.org/wiki/Email_address
AND http://tools.ietf.org/html/rfc5322#section-3.2.3
- The local-part of the email address may use any of these ASCII
characters RFC 5322 Section 3.2.3
- The following error is received during camel route deployment:
{code}
17:56:31,791 | INFO | l Console Thread | BlueprintCamelContext|
143 - org.apache.camel.camel-core - 2.12.0.redhat-610379 | Apache Camel
2.12.0.redhat-610379 (CamelContext: camel-9) is starting
17:56:31,792 | INFO | l Console Thread | BlueprintCamelContext|
143 - org.apache.camel.camel-core - 2.12.0.redhat-610379 | Tracing is enabled
on CamelContext: camel-9
17:56:31,792 | INFO | l Console Thread | ManagedManagementStrategy|
143 - org.apache.camel.camel-core - 2.12.0.redhat-610379 | JMX is enabled
17:56:31,803 | INFO | l Console Thread | BlueprintCamelContext|
143 - org.apache.camel.camel-core - 2.12.0.redhat-610379 | Apache Camel
2.12.0.redhat-610379 (CamelContext: camel-9) is shutting down
17:56:31,804 | INFO | l Console Thread | BlueprintCamelContext|
143 - org.apache.camel.camel-core - 2.12.0.redhat-610379 | Apache Camel
2.12.0.redhat-610379 (CamelContext: camel-9) uptime 0.013 seconds
17:56:31,804 | INFO | l Console Thread | BlueprintCamelContext|
143 - org.apache.camel.camel-core - 2.12.0.redhat-610379 | Apache Camel
2.12.0.redhat-610379 (CamelContext: camel-9) is shutdown in 0.001 seconds
17:56:31,804 | ERROR | l Console Thread | BlueprintCamelContext|
151 - org.apache.camel.camel-blueprint - 2.12.0.redhat-610379 | Error
occurred during starting Camel: CamelContext(camel-9) due Failed to create
route route9 at:
To[smtp://test.mail.com:25?To=user1...@gmail.comFrom=jsens...@gmail.com]
in route: Route(route9)[[From[timer://foo?delay=2srepeatCount=1]] - ...
because of Failed to resolve endpoint:
smtp://test.mail.com:25?123%40gmail.com=From=jsenshar%40gmail.comTo=user
due to: Failed to resolve endpoint:
smtp://test.mail.com:25?123%40gmail.com=From=jsenshar%40gmail.comTo=user
due to: There are 1 parameters that couldn't be set on the endpoint. Check
the uri if the parameters are spelt correctly and that they are properties of
the endpoint. Unknown parameters=[{1...@gmail.com=}]
org.apache.camel.FailedToCreateRouteException: Failed to create route route9
at:
To[smtp://test.mail.com:25?To=user1...@gmail.comFrom=jsens...@gmail.com]
in route: Route(route9)[[From[timer://foo?delay=2srepeatCount=1]] - ...
because of Failed to resolve endpoint:
smtp://test.mail.com:25?123%40gmail.com=From=jsenshar%40gmail.comTo=user
due to: Failed to resolve endpoint:
smtp://test.mail.com:25?123%40gmail.com=From=jsenshar%40gmail.comTo=user
due to: There are 1 parameters that couldn't be set on the endpoint. Check
the uri if the parameters are spelt correctly and that they are properties of
the endpoint. Unknown parameters=[{1...@gmail.com=}]
at
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:912)
at
org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:177)
at
org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:778)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at
[jira] [Resolved] (CAMEL-8678) Infinite recursion in TransactionErrorHandler toString method
[ https://issues.apache.org/jira/browse/CAMEL-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8678. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/b7138260 Infinite recursion in TransactionErrorHandler toString method - Key: CAMEL-8678 URL: https://issues.apache.org/jira/browse/CAMEL-8678 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.2, 2.16.0 This causes the stack to overflow, which is bad :-) Offending code: https://github.com/apache/camel/blob/66e04492c34cc4150abcd9908c8afd837c9eb51d/components/camel-spring/src/main/java/org/apache/camel/spring/spi/TransactionErrorHandler.java#L227-L229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8678) Infinite recursion in TransactionErrorHandler toString method
Jonathan Anstey created CAMEL-8678: -- Summary: Infinite recursion in TransactionErrorHandler toString method Key: CAMEL-8678 URL: https://issues.apache.org/jira/browse/CAMEL-8678 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.2, 2.16.0 This causes the stack to overflow, which is bad :-) Offending code: https://github.com/apache/camel/blob/66e04492c34cc4150abcd9908c8afd837c9eb51d/components/camel-spring/src/main/java/org/apache/camel/spring/spi/TransactionErrorHandler.java#L227-L229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8453) camel-avro throws SAXParseException when used from spring or blueprint
[ https://issues.apache.org/jira/browse/CAMEL-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350578#comment-14350578 ] Jonathan Anstey commented on CAMEL-8453: Fix for master http://git-wip-us.apache.org/repos/asf/camel/commit/fa38e09b camel-avro throws SAXParseException when used from spring or blueprint -- Key: CAMEL-8453 URL: https://issues.apache.org/jira/browse/CAMEL-8453 Project: Camel Issue Type: Bug Affects Versions: 2.14.1 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.3, 2.15.0 Getting this exception when using avro dataformat from spring: org.xml.sax.SAXParseException; lineNumber: 27; columnNumber: 88; cvc-complex-type.3.2.2: Attribute 'instanceClass' is not allowed to appear in element 'avro'. Don't think this has ever worked from spring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8453) camel-avro throws SAXParseException when used from spring or blueprint
Jonathan Anstey created CAMEL-8453: -- Summary: camel-avro throws SAXParseException when used from spring or blueprint Key: CAMEL-8453 URL: https://issues.apache.org/jira/browse/CAMEL-8453 Project: Camel Issue Type: Bug Affects Versions: 2.14.1 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.3, 2.15.0 Getting this exception when using avro dataformat from spring: org.xml.sax.SAXParseException; lineNumber: 27; columnNumber: 88; cvc-complex-type.3.2.2: Attribute 'instanceClass' is not allowed to appear in element 'avro'. Don't think this has ever worked from spring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8453) camel-avro throws SAXParseException when used from spring or blueprint
[ https://issues.apache.org/jira/browse/CAMEL-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8453. Resolution: Fixed camel-avro throws SAXParseException when used from spring or blueprint -- Key: CAMEL-8453 URL: https://issues.apache.org/jira/browse/CAMEL-8453 Project: Camel Issue Type: Bug Affects Versions: 2.14.1 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.3, 2.15.0 Getting this exception when using avro dataformat from spring: org.xml.sax.SAXParseException; lineNumber: 27; columnNumber: 88; cvc-complex-type.3.2.2: Attribute 'instanceClass' is not allowed to appear in element 'avro'. Don't think this has ever worked from spring. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8214) Support partial responses in google APIs
Jonathan Anstey created CAMEL-8214: -- Summary: Support partial responses in google APIs Key: CAMEL-8214 URL: https://issues.apache.org/jira/browse/CAMEL-8214 Project: Camel Issue Type: Bug Affects Versions: 2.14.1 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Would be good to support partial responses in the Google API components: https://developers.google.com/blogger/docs/3.0/performance#partial-response -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8216) Unable to specify startHistoryId for history list in camel-google-mail
Jonathan Anstey created CAMEL-8216: -- Summary: Unable to specify startHistoryId for history list in camel-google-mail Key: CAMEL-8216 URL: https://issues.apache.org/jira/browse/CAMEL-8216 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Getting Missing/invalid parameter: startHistoryId when calling history list via camel-google-mail component. This is a required parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8214) Support partial responses in google APIs
[ https://issues.apache.org/jira/browse/CAMEL-8214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8214. Resolution: Fixed Fix Version/s: 2.14.2 http://git-wip-us.apache.org/repos/asf/camel/commit/ecd9977c Support partial responses in google APIs Key: CAMEL-8214 URL: https://issues.apache.org/jira/browse/CAMEL-8214 Project: Camel Issue Type: Bug Affects Versions: 2.14.1 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.2, 2.15.0 Would be good to support partial responses in the Google API components: https://developers.google.com/blogger/docs/3.0/performance#partial-response -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8216) Unable to specify startHistoryId for history list in camel-google-mail
[ https://issues.apache.org/jira/browse/CAMEL-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8216. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/ebae9b51 Unable to specify startHistoryId for history list in camel-google-mail -- Key: CAMEL-8216 URL: https://issues.apache.org/jira/browse/CAMEL-8216 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Getting Missing/invalid parameter: startHistoryId when calling history list via camel-google-mail component. This is a required parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8158) Provide way to specify fields to patch in google drive endpoints
Jonathan Anstey created CAMEL-8158: -- Summary: Provide way to specify fields to patch in google drive endpoints Key: CAMEL-8158 URL: https://issues.apache.org/jira/browse/CAMEL-8158 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.2, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8158) Provide way to specify fields to patch in google drive endpoints
[ https://issues.apache.org/jira/browse/CAMEL-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8158. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/52b7b945 Provide way to specify fields to patch in google drive endpoints Key: CAMEL-8158 URL: https://issues.apache.org/jira/browse/CAMEL-8158 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.2, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8110) Google Mail Component
[ https://issues.apache.org/jira/browse/CAMEL-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8110. Resolution: Fixed Google Mail Component - Key: CAMEL-8110 URL: https://issues.apache.org/jira/browse/CAMEL-8110 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's mail API https://developers.google.com/gmail/api/v1/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8050) Google Calendar component
[ https://issues.apache.org/jira/browse/CAMEL-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8050. Resolution: Fixed Google Calendar component - Key: CAMEL-8050 URL: https://issues.apache.org/jira/browse/CAMEL-8050 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's calendar API https://developers.google.com/google-apps/calendar/v3/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8050) Google Calendar component
[ https://issues.apache.org/jira/browse/CAMEL-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232096#comment-14232096 ] Jonathan Anstey commented on CAMEL-8050: Committed here: http://git-wip-us.apache.org/repos/asf/camel/commit/d3589e83 Still need to do up some docs. Google Calendar component - Key: CAMEL-8050 URL: https://issues.apache.org/jira/browse/CAMEL-8050 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's calendar API https://developers.google.com/google-apps/calendar/v3/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8110) Google Mail Component
Jonathan Anstey created CAMEL-8110: -- Summary: Google Mail Component Key: CAMEL-8110 URL: https://issues.apache.org/jira/browse/CAMEL-8110 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's mail API https://developers.google.com/gmail/api/v1/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8110) Google Mail Component
[ https://issues.apache.org/jira/browse/CAMEL-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232125#comment-14232125 ] Jonathan Anstey commented on CAMEL-8110: Added here: http://git-wip-us.apache.org/repos/asf/camel/commit/3c6769db Still need to do up some docs. Google Mail Component - Key: CAMEL-8110 URL: https://issues.apache.org/jira/browse/CAMEL-8110 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's mail API https://developers.google.com/gmail/api/v1/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8089) Support paging and restricting results from google drive
Jonathan Anstey created CAMEL-8089: -- Summary: Support paging and restricting results from google drive Key: CAMEL-8089 URL: https://issues.apache.org/jira/browse/CAMEL-8089 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8089) Support paging and restricting results from google drive
[ https://issues.apache.org/jira/browse/CAMEL-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8089. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/94898489 Support paging and restricting results from google drive Key: CAMEL-8089 URL: https://issues.apache.org/jira/browse/CAMEL-8089 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8050) Google Calendar component
Jonathan Anstey created CAMEL-8050: -- Summary: Google Calendar component Key: CAMEL-8050 URL: https://issues.apache.org/jira/browse/CAMEL-8050 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's calendar API https://developers.google.com/google-apps/calendar/v3/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14209893#comment-14209893 ] Jonathan Anstey edited comment on CAMEL-7627 at 11/13/14 3:23 PM: -- Just merged your patches with a few minor modifications. Thanks Nikolay! was (Author: janstey): Just merged your patches with a few miro modifications. Thanks Nikolay! Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0, 2.13.4 Attachments: 0001-Fix-reshedule-changed-trigger-after-restart.patch, 0002-Test-trigger-type-change.patch Camel-quartz2 component in clustered mode uses trigger options stored in DB rather (possibly changed) ones from endpoint's URI. Desirable behavior is to compare trigger options in DB and endpoint's URI and reschedule quartz job when they changed (like in camel-quartz component). Component camel-quartz already have this functionality, but there is no test for it and it works incorrectly with changed SimpleTrigger options. I attached a patch with unit tests. Every test prepares DB, than creates application context twice with different trigger options. Both times it retrieves options back, accessing them via trigger (not via endpoint, so that it uses values stored in DB). After that it asserts that retrieved options are indeed different. You can ensure, that the tests fail with old versions of org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods and pass with patched implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-7627. Resolution: Fixed Fix Version/s: 2.13.4 2.14.1 Assignee: Jonathan Anstey Just merged your patches with a few miro modifications. Thanks Nikolay! Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0, 2.13.4 Attachments: 0001-Fix-reshedule-changed-trigger-after-restart.patch, 0002-Test-trigger-type-change.patch Camel-quartz2 component in clustered mode uses trigger options stored in DB rather (possibly changed) ones from endpoint's URI. Desirable behavior is to compare trigger options in DB and endpoint's URI and reschedule quartz job when they changed (like in camel-quartz component). Component camel-quartz already have this functionality, but there is no test for it and it works incorrectly with changed SimpleTrigger options. I attached a patch with unit tests. Every test prepares DB, than creates application context twice with different trigger options. Both times it retrieves options back, accessing them via trigger (not via endpoint, so that it uses values stored in DB). After that it asserts that retrieved options are indeed different. You can ensure, that the tests fail with old versions of org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods and pass with patched implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7940) Disable SSL security protocol by default
[ https://issues.apache.org/jira/browse/CAMEL-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186782#comment-14186782 ] Jonathan Anstey commented on CAMEL-7940: Switched to use TLS by default in the netty components as well: https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commit;h=c10a91ac Disable SSL security protocol by default Key: CAMEL-7940 URL: https://issues.apache.org/jira/browse/CAMEL-7940 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.2, 2.14.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 Camel SSLContextParameters doesn't disable the SSL protocol by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7580) Google Drive component
[ https://issues.apache.org/jira/browse/CAMEL-7580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-7580. Resolution: Fixed Fix Version/s: (was: 2.15.0) 2.14.0 Google Drive component -- Key: CAMEL-7580 URL: https://issues.apache.org/jira/browse/CAMEL-7580 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.0 Looking into creating a component for accessing Google's Drive service (see https://developers.google.com/drive/v2/reference/). Going to use the new camel-api-component-maven-plugin for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7580) Google Drive component
[ https://issues.apache.org/jira/browse/CAMEL-7580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14109096#comment-14109096 ] Jonathan Anstey commented on CAMEL-7580: I'll try and take a look later this week. Not a blocker for the 2.14 release though. Google Drive component -- Key: CAMEL-7580 URL: https://issues.apache.org/jira/browse/CAMEL-7580 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.0 Looking into creating a component for accessing Google's Drive service (see https://developers.google.com/drive/v2/reference/). Going to use the new camel-api-component-maven-plugin for this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7580) Google Drive component
Jonathan Anstey created CAMEL-7580: -- Summary: Google Drive component Key: CAMEL-7580 URL: https://issues.apache.org/jira/browse/CAMEL-7580 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.0 Looking into creating a component for accessing Google's Drive service (see https://developers.google.com/drive/v2/reference/). Going to use the new camel-api-component-maven-plugin for this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-6568) camel-linkedin component
[ https://issues.apache.org/jira/browse/CAMEL-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017789#comment-14017789 ] Jonathan Anstey commented on CAMEL-6568: [~sachin.handiekar] did you still have an interest in creating this component? LinkedIn is very popular so it would be nice to have this one in Camel. Cheers, Jon camel-linkedin component Key: CAMEL-6568 URL: https://issues.apache.org/jira/browse/CAMEL-6568 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Fix For: Future People have been asking for a camel-linkedin component. It would be nice to have some component that can lookup a linkedin profile and get some details of that profile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-6568) camel-linkedin component
[ https://issues.apache.org/jira/browse/CAMEL-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017941#comment-14017941 ] Jonathan Anstey commented on CAMEL-6568: Cool stuff. Looking forward to trying it out :-) camel-linkedin component Key: CAMEL-6568 URL: https://issues.apache.org/jira/browse/CAMEL-6568 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Fix For: Future People have been asking for a camel-linkedin component. It would be nice to have some component that can lookup a linkedin profile and get some details of that profile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-5093) Create a camel-paypal component
[ https://issues.apache.org/jira/browse/CAMEL-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13996275#comment-13996275 ] Jonathan Anstey commented on CAMEL-5093: Yeah, this one sounds like a good one for camel-extra. Especially since we didn't officially hear back from legal (LEGAL-159). If we do get the OK, we can always move it back into the main :-) [~joesan] are you still working on this component? It would be a great addition to Camel IMO. Create a camel-paypal component --- Key: CAMEL-5093 URL: https://issues.apache.org/jira/browse/CAMEL-5093 Project: Camel Issue Type: New Feature Reporter: Christian Müller Assignee: Christian Müller Fix For: Future See [1] for the SDK (if wecan use it - we have to check it) and/or the wsdl file for the soap interface. [1] https://cms.paypal.com/us/cgi-bin/?cmd=_render-contentcontent_ID=developer/library_download_sdks Feel free to pick up this ticket if you would like to work on it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7279) Yammer now uses bearer token for auth
Jonathan Anstey created CAMEL-7279: -- Summary: Yammer now uses bearer token for auth Key: CAMEL-7279 URL: https://issues.apache.org/jira/browse/CAMEL-7279 Project: Camel Issue Type: Bug Affects Versions: 2.12.3 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.4, 2.13.1 ... which means camel-yammer cannot connect to the yammer API currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7279) Yammer now uses bearer token for auth
[ https://issues.apache.org/jira/browse/CAMEL-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-7279. Resolution: Fixed master - http://git-wip-us.apache.org/repos/asf/camel/commit/263b5681 camel-2.12.x - http://git-wip-us.apache.org/repos/asf/camel/commit/496026d6 Yammer now uses bearer token for auth - Key: CAMEL-7279 URL: https://issues.apache.org/jira/browse/CAMEL-7279 Project: Camel Issue Type: Bug Affects Versions: 2.12.3 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.4, 2.13.1 ... which means camel-yammer cannot connect to the yammer API currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7216) Upgrade to xstream 1.4.7
[ https://issues.apache.org/jira/browse/CAMEL-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-7216. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/9640e23f http://git-wip-us.apache.org/repos/asf/camel/commit/f02b9bec Upgrade to xstream 1.4.7 Key: CAMEL-7216 URL: https://issues.apache.org/jira/browse/CAMEL-7216 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.4, 2.13.0 Fix for CVE-2013-7285 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CAMEL-7216) Upgrade to xstream 1.4.7
Jonathan Anstey created CAMEL-7216: -- Summary: Upgrade to xstream 1.4.7 Key: CAMEL-7216 URL: https://issues.apache.org/jira/browse/CAMEL-7216 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.13.0 Fix for CVE-2013-7285 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CAMEL-7216) Upgrade to xstream 1.4.7
[ https://issues.apache.org/jira/browse/CAMEL-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-7216: --- Fix Version/s: 2.12.4 Upgrade to xstream 1.4.7 Key: CAMEL-7216 URL: https://issues.apache.org/jira/browse/CAMEL-7216 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.4, 2.13.0 Fix for CVE-2013-7285 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7216) Upgrade to xstream 1.4.7
[ https://issues.apache.org/jira/browse/CAMEL-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903460#comment-13903460 ] Jonathan Anstey commented on CAMEL-7216: Waiting on current SMX bundles vote to close before pushing. Upgrade to xstream 1.4.7 Key: CAMEL-7216 URL: https://issues.apache.org/jira/browse/CAMEL-7216 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.4, 2.13.0 Fix for CVE-2013-7285 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CAMEL-7159) camel-bindy not picking up @Link annotation items
[ https://issues.apache.org/jira/browse/CAMEL-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-7159. Resolution: Fixed camel-bindy not picking up @Link annotation items - Key: CAMEL-7159 URL: https://issues.apache.org/jira/browse/CAMEL-7159 Project: Camel Issue Type: Bug Affects Versions: 2.12.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.11.4, 2.12.3, 2.13.0 It works fine (like in the tests) when you provide bindy with a MapString, Object of model objects corresponding to the @Linked-ed classes. We should do better though and try to figure this out for users. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CAMEL-7159) camel-bindy not picking up @Link annotation items
Jonathan Anstey created CAMEL-7159: -- Summary: camel-bindy not picking up @Link annotation items Key: CAMEL-7159 URL: https://issues.apache.org/jira/browse/CAMEL-7159 Project: Camel Issue Type: Bug Affects Versions: 2.12.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey It works fine (like in the tests) when you provide bindy with a MapString, Object of model objects corresponding to the @Linked-ed classes. We should do better though and try to figure this out for users. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CAMEL-7159) camel-bindy not picking up @Link annotation items
[ https://issues.apache.org/jira/browse/CAMEL-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-7159: --- Fix Version/s: 2.13.0 2.12.3 2.11.4 camel-bindy not picking up @Link annotation items - Key: CAMEL-7159 URL: https://issues.apache.org/jira/browse/CAMEL-7159 Project: Camel Issue Type: Bug Affects Versions: 2.12.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.11.4, 2.12.3, 2.13.0 It works fine (like in the tests) when you provide bindy with a MapString, Object of model objects corresponding to the @Linked-ed classes. We should do better though and try to figure this out for users. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CAMEL-6849) Update to jruby 1.7.5
[ https://issues.apache.org/jira/browse/CAMEL-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-6849. Resolution: Fixed Update to jruby 1.7.5 - Key: CAMEL-6849 URL: https://issues.apache.org/jira/browse/CAMEL-6849 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.2, 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6849) Update to jruby 1.7.5
[ https://issues.apache.org/jira/browse/CAMEL-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13791475#comment-13791475 ] Jonathan Anstey commented on CAMEL-6849: Yeah, there was a problem alright. JRuby is now split into 2 OSGi bundles: jruby-core and jruby-stdlib. The old jruby artifact can still be used for Maven builds since it now just has transitive dependencies to core and stdlib. Update to jruby 1.7.5 - Key: CAMEL-6849 URL: https://issues.apache.org/jira/browse/CAMEL-6849 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.2, 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6849) Update to jruby 1.7.5
Jonathan Anstey created CAMEL-6849: -- Summary: Update to jruby 1.7.5 Key: CAMEL-6849 URL: https://issues.apache.org/jira/browse/CAMEL-6849 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.2, 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6849) Update to jruby 1.7.5
[ https://issues.apache.org/jira/browse/CAMEL-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-6849. Resolution: Fixed Update to jruby 1.7.5 - Key: CAMEL-6849 URL: https://issues.apache.org/jira/browse/CAMEL-6849 Project: Camel Issue Type: Task Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.2, 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6761) Upgrade to restlet 2.1.4
[ https://issues.apache.org/jira/browse/CAMEL-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13769532#comment-13769532 ] Jonathan Anstey commented on CAMEL-6761: Thanks Christian. Didn't notice at all that they split out the OSGi bundle for 2.1. Upgrade to restlet 2.1.4 Key: CAMEL-6761 URL: https://issues.apache.org/jira/browse/CAMEL-6761 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1, 2.13.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6761) Upgrade to restlet 2.1
Jonathan Anstey created CAMEL-6761: -- Summary: Upgrade to restlet 2.1 Key: CAMEL-6761 URL: https://issues.apache.org/jira/browse/CAMEL-6761 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1, 2.13.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6761) Upgrade to restlet 2.1
[ https://issues.apache.org/jira/browse/CAMEL-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-6761. Resolution: Fixed Upgrade to restlet 2.1 -- Key: CAMEL-6761 URL: https://issues.apache.org/jira/browse/CAMEL-6761 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1, 2.13.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6761) Upgrade to restlet 2.1.4
[ https://issues.apache.org/jira/browse/CAMEL-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-6761: --- Summary: Upgrade to restlet 2.1.4 (was: Upgrade to restlet 2.1) Upgrade to restlet 2.1.4 Key: CAMEL-6761 URL: https://issues.apache.org/jira/browse/CAMEL-6761 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1, 2.13.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6741) Upgrade to hadoop 1.2.1
Jonathan Anstey created CAMEL-6741: -- Summary: Upgrade to hadoop 1.2.1 Key: CAMEL-6741 URL: https://issues.apache.org/jira/browse/CAMEL-6741 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1, 2.13.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6741) Upgrade to hadoop 1.2.1
[ https://issues.apache.org/jira/browse/CAMEL-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-6741. Resolution: Fixed Upgrade to hadoop 1.2.1 --- Key: CAMEL-6741 URL: https://issues.apache.org/jira/browse/CAMEL-6741 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1, 2.13.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6709) camel-yammer - Endpoint yammer:current throwns JsonMappingException exception camel-yammer - Endpoint yammer:current throwns JsonMappingException exception
Jonathan Anstey created CAMEL-6709: -- Summary: camel-yammer - Endpoint yammer:current throwns JsonMappingException exception camel-yammer - Endpoint yammer:current throwns JsonMappingException exception Key: CAMEL-6709 URL: https://issues.apache.org/jira/browse/CAMEL-6709 Project: Camel Issue Type: Bug Affects Versions: 2.12.0 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1 Getting org.codehaus.jackson.map.JsonMappingException: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token when trying to return the current user using yammer:current. Workaround is to just add ?useJson=true and do marshaling manually. Fixing on master shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6709) camel-yammer - Endpoint yammer:current throwns JsonMappingException exception
[ https://issues.apache.org/jira/browse/CAMEL-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-6709: --- Summary: camel-yammer - Endpoint yammer:current throwns JsonMappingException exception (was: camel-yammer - Endpoint yammer:current throwns JsonMappingException exception camel-yammer - Endpoint yammer:current throwns JsonMappingException exception ) camel-yammer - Endpoint yammer:current throwns JsonMappingException exception -- Key: CAMEL-6709 URL: https://issues.apache.org/jira/browse/CAMEL-6709 Project: Camel Issue Type: Bug Affects Versions: 2.12.0 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1 Getting org.codehaus.jackson.map.JsonMappingException: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token when trying to return the current user using yammer:current. Workaround is to just add ?useJson=true and do marshaling manually. Fixing on master shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6709) camel-yammer - Endpoint yammer:current throwns JsonMappingException exception
[ https://issues.apache.org/jira/browse/CAMEL-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759090#comment-13759090 ] Jonathan Anstey commented on CAMEL-6709: Fixed with https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commit;h=420ab5d2 No need to hold up 2.12 release for this as you can still get the raw info of the current user via useJson=true. camel-yammer - Endpoint yammer:current throwns JsonMappingException exception -- Key: CAMEL-6709 URL: https://issues.apache.org/jira/browse/CAMEL-6709 Project: Camel Issue Type: Bug Affects Versions: 2.12.0 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1 Getting org.codehaus.jackson.map.JsonMappingException: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token when trying to return the current user using yammer:current. Workaround is to just add ?useJson=true and do marshaling manually. Fixing on master shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6710) Add endpoint to consume received messages in camel-yammer
Jonathan Anstey created CAMEL-6710: -- Summary: Add endpoint to consume received messages in camel-yammer Key: CAMEL-6710 URL: https://issues.apache.org/jira/browse/CAMEL-6710 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6662) camel-yammer - don't share requestor between different endpoint types
Jonathan Anstey created CAMEL-6662: -- Summary: camel-yammer - don't share requestor between different endpoint types Key: CAMEL-6662 URL: https://issues.apache.org/jira/browse/CAMEL-6662 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.0 This means that the same API connection info is used for say a messages consumer and users consumer - which is bad because they are supposed to connect to different yammer APIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6662) camel-yammer - don't share requestor between different endpoint types
[ https://issues.apache.org/jira/browse/CAMEL-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-6662. Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commit;h=bb4f2e5b camel-yammer - don't share requestor between different endpoint types - Key: CAMEL-6662 URL: https://issues.apache.org/jira/browse/CAMEL-6662 Project: Camel Issue Type: Bug Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.12.0 This means that the same API connection info is used for say a messages consumer and users consumer - which is bad because they are supposed to connect to different yammer APIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6663) camel-sap-netweaver throws JsonParseException when using json=false option
Jonathan Anstey created CAMEL-6663:
--
Summary: camel-sap-netweaver throws JsonParseException when using
json=false option
Key: CAMEL-6663
URL: https://issues.apache.org/jira/browse/CAMEL-6663
Project: Camel
Issue Type: Bug
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.12.0
If you set json=false like:
{code}
sap-netweaver:https://sapes1.sapdevcenter.com/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/?username=USERamp;password=PASSamp;json=false
{code}
It will try and parse the body as JSON because jsonAsMap is still true. This is
the result:
{code}
org.codehaus.jackson.JsonParseException: Unexpected character ('' (code 60)):
expected a valid value (number, String, array, object, 'true', 'false' or
'null')
at [Source: java.io.StringReader@343eb53f; line: 1, column: 2]
at
org.codehaus.jackson.JsonParser._constructError(JsonParser.java:1433)[51:jackson-core-asl:1.9.10]
at
org.codehaus.jackson.impl.JsonParserMinimalBase._reportError(JsonParserMinimalBase.java:521)[51:jackson-core-asl:1.9.10]
at
org.codehaus.jackson.impl.JsonParserMinimalBase._reportUnexpectedChar(JsonParserMinimalBase.java:442)[51:jackson-core-asl:1.9.10]
at
org.codehaus.jackson.impl.ReaderBasedParser._handleUnexpectedValue(ReaderBasedParser.java:1198)[51:jackson-core-asl:1.9.10]
at
org.codehaus.jackson.impl.ReaderBasedParser.nextToken(ReaderBasedParser.java:485)[51:jackson-core-asl:1.9.10]
at
org.codehaus.jackson.map.ObjectMapper._initForReading(ObjectMapper.java:2770)[53:jackson-mapper-asl:1.9.10]
at
org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2718)[53:jackson-mapper-asl:1.9.10]
at
org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1863)[53:jackson-mapper-asl:1.9.10]
at
org.apache.camel.component.sap.netweaver.NetWeaverProducer.process(NetWeaverProducer.java:61)[237:org.apache.camel.camel-sap-netweaver:2.12.0.redhat-610030]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:110)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:192)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:192)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:352)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:199)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:165)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:152)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:102)[131:org.apache.camel.camel-core:2.12.0.redhat-610030]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_25]
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)[:1.7.0_25]
at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)[:1.7.0_25]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)[:1.7.0_25]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_25]
at
