[jira] [Commented] (CAMEL-10452) camel-salesforce: Add an option to simulate SELECT * from

2016-11-30 Thread Luca Burgazzoli (JIRA)

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

Luca Burgazzoli commented on CAMEL-10452:
-

So then you can use such annotations field to simulate a select * ?

> camel-salesforce: Add an option to simulate SELECT * from
> -
>
> Key: CAMEL-10452
> URL: https://issues.apache.org/jira/browse/CAMEL-10452
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Luca Burgazzoli
>Assignee: Zoran Regvart
>Priority: Minor
> Fix For: 2.19.0
>
>
> As today it is not possible to run a query like SELECT * from but one is 
> forced to list all the field he want.
> It would be nice to auto generate a statement using SObject meta data so one 
> can write:
> from("salesforce:stream?SObjectName=Case=true")
> to get all the fields the SObjectName supports.
> [~dhirajsb] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10486) Google PubSub Component does not consume messages with parallel consumers

2016-11-30 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CAMEL-10486:


GitHub user evmin opened a pull request:

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

CAMEL-10486: The consumer threading/message undelelivered issue fix

Google PubSub Component did not consume messages with parallel consumers.


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

$ git pull https://github.com/evmin/camel CAMEL-10486

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

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

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

This closes #1325


commit ea3991fd2ccacf39bd8bab3b77a2b309c61df52c
Author: Evgeny Minkevich 
Date:   2016-11-17T03:50:55Z

CAMEL-10486: The consumer threading/message undelelivered issue fix




> Google PubSub Component does not consume messages with parallel consumers
> -
>
> Key: CAMEL-10486
> URL: https://issues.apache.org/jira/browse/CAMEL-10486
> Project: Camel
>  Issue Type: Bug
>Reporter: Evgeny Minkevich
> Fix For: 2.19.0
>
>
> Component: camel-google-pubsub
> When parallelConsumers option on an endpoint is assigned the value greater 
> than 1, the component will not be receiving messages.
> The issue has been traced to the underlying Google library used and I will 
> update the component once the fix is available. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10452) camel-salesforce: Add an option to simulate SELECT * from

2016-11-30 Thread Zoran Regvart (JIRA)

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

Zoran Regvart commented on CAMEL-10452:
---

So how about [this 
approach|https://github.com/zregvart/camel/commit/68bbef8fbb76f5a317e55a80a6d462da8e8002ee](github.com)
 for metadata. Basically two ways of specifying metadata: annotation and 
properties file, annotation beats the property file. Really simple, but pays 
the way for this functionality.

> camel-salesforce: Add an option to simulate SELECT * from
> -
>
> Key: CAMEL-10452
> URL: https://issues.apache.org/jira/browse/CAMEL-10452
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Luca Burgazzoli
>Assignee: Zoran Regvart
>Priority: Minor
> Fix For: 2.19.0
>
>
> As today it is not possible to run a query like SELECT * from but one is 
> forced to list all the field he want.
> It would be nice to auto generate a statement using SObject meta data so one 
> can write:
> from("salesforce:stream?SObjectName=Case=true")
> to get all the fields the SObjectName supports.
> [~dhirajsb] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10272) Aggregation is broken due to race condition in ParallelAggregateTask.doAggregateInternal()

2016-11-30 Thread Peter Keller (JIRA)

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

Peter Keller commented on CAMEL-10272:
--

Alex, thank you very much for the analysis. 

You are right: if an exception is thrown then {{oldExchange}} may be {{null}}. 
As this may be the case in our route, it is mysterious why the exception is 
thrown in a non-deterministic way (of course the root cause may be another 
multi-threading issue not directly correlated to Camel).

Note, if {{parallelAggregate()}} is used (as mentioned above we don't use this 
setup), then {{oldExchange}} may also be null. This can be shown using a 
debugger with setting a breakpoint in {{doAggregateInternal}} on the line with 
{{ExchangeHelper.prepareAggregation}}. Shouldn't Camel prevent {{oldExchange}} 
to be {{null}} in this case?

The logging of the (possible) exception caused by the aggregation strategy 
could help to trace down the cause. Of course this could be done in the 
implementation of the aggregation strategy itself with a try/catch clause 
without changing the Camel framework. 

Unwinding the exception to the default error handler may break existing routes 
which is not desirable. That said, I personally would prefer this possibility.


> Aggregation is broken due to race condition in 
> ParallelAggregateTask.doAggregateInternal()
> --
>
> Key: CAMEL-10272
> URL: https://issues.apache.org/jira/browse/CAMEL-10272
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.3, 2.17.3
> Environment: MacOS 10.11.6, JRE 1.7.0_79
>Reporter: Peter Keller
>
> Unfortunately, I am not able to provide a (simple) unit test for 
> comprehending the problem. Furthermore our (complex) unit tests are not 
> deterministic due to the root cause of the problem.
> However I tried to analyze the Camel Java code, to work out the problem. 
> Please find below my findings.
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a 
> recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
>  from("direct:start")
> .to("direct:pre")
> .recipientList().method(new MyRecipientListBuilder())
> .stopOnException()
> .aggregationStrategy(new MyAggregationStrategy())
> .parallelProcessing()
> .end()
> .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange 
> newExchange) {
> if (oldExchange == null) {
> // this is the case more than once which is not expected!
> }
> // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which 
> contradicts the contract with Camel.
> h3. Analysis
> During the processing, Camel invokes {{MulticastProcessor.process()}}. Here 
> the result object {{AtomicExchange}} is created which is shared during the 
> whole processing.
> If the processing should be done in parallel (as it is the case for our 
> route) then {{MulticastProcessor.doProcessParallel()}} is invoked. Here one 
> instance of {{AggregateOnTheFlyTask}} is initialized and 
> {{aggregateOnTheFly()}} is invoked -*asynchronously* via {{run()}}  for 
> *every* target in the recipient list-. via 
> {{aggregateExecutorService.submit}} ({{aggregationTaskSubmitted}} guarantees 
> that this is only be done once)
> In {{aggregateOnTheFly()}}, a new instance of {{ParallelAggregateTask}} is 
> generated, and if aggregation is not done in parallel (as it is the case in 
> our route), {{ParallelAggregateTask.run()}}, 
> {{ParallelAggregateTask.doAggregate()}} (this method is synchronized), and 
> {{ParallelAggregateTask.doAggregateInternal()}} is invoked synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy, 
> AtomicExchange result, Exchange exchange) {
> if (strategy != null) {
> // prepare the exchanges for aggregation
> Exchange oldExchange = result.get();
> ExchangeHelper.prepareAggregation(oldExchange, exchange);
> result.set(strategy.aggregate(oldExchange, exchange));
> }
> } 
> {code}
> However, in {{ParallelAggregateTask.doAggregateInternal()}} there may occur a 
> race condition as {{result}} is shared -by every instance of 
> {{AggregateOnTheFlyTask}}- such that {{oldExchange = result.get()}} may be 
> {{null}} more than once!
> Note: As a new instance of {{ParallelAggregateTask}} for every target in 
> recipient list is created, the {{synchronized}} method 
> {{ParallelAggregateTask.doAggregate()}} does not prevent the race condition!
> Does this sounds 

[jira] [Created] (CAMEL-10548) Converter from List to String is not found when @EnableAutoConfiguration is used

2016-11-30 Thread Luca Burgazzoli (JIRA)
Luca Burgazzoli created CAMEL-10548:
---

 Summary: Converter from List to String is not found when 
@EnableAutoConfiguration is used
 Key: CAMEL-10548
 URL: https://issues.apache.org/jira/browse/CAMEL-10548
 Project: Camel
  Issue Type: Bug
  Components: camel-spring-boot
Reporter: Luca Burgazzoli
Assignee: Luca Burgazzoli
 Fix For: 2.19.0


This very simple spring-boot application :

{code:java}
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}

@Component
public class MyRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from("timer:person")
.setBody().constant(Arrays.asList(
new Person("Peter", 25),
new Person("John", 33)
))
.log("Body is ${body}");
}
}

public static class Person {
private String name;
private int age;

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public int getAge() {
return age;
}

public void setAge(int age) {
this.age = age;
}

@Override
public String toString() {
return "Person{" +
"name='" + name + '\'' +
", age=" + age +
'}';
}
}
}
{code}

Fails to resolve the simple expression ${body} because of the following 
exception:

{code}
org.apache.camel.TypeConversionException: Error during type conversion from 
type: java.lang.String to the required type: java.lang.String with value 
[Person{name='Peter', age=25}, Person{name='John', age=33}] due Failed to 
convert from type [java.util.Arrays$ArrayList] to type [java.lang.String] 
for value '[Person{name='Peter', age=25}, Person{name='John', age=33}]'; nested 
exception is org.springframework.core.convert.ConverterNotFoundException: No 
converter found capable of converting from type [java.util.Arrays$ArrayList] 
to type [java.lang.String]
at 
org.apache.camel.impl.converter.BaseTypeConverterRegistry.createTypeConversionException(BaseTypeConverterRegistry.java:629)
 ~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:150)
 ~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:41) 
~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.builder.ExpressionBuilder$75.evaluate(ExpressionBuilder.java:1795)
 ~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:36) 
~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.processor.LogProcessor.process(LogProcessor.java:53) 
~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)
 ~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:542)
 ~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
 [camel-core-2.18.0.jar:2.18.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:120) 
~[camel-core-2.18.0.jar:2.18.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:83) 
~[camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
 [camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:192)
 [camel-core-2.18.0.jar:2.18.0]
at 
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:76) 
[camel-core-2.18.0.jar:2.18.0]
at java.util.TimerThread.mainLoop(Timer.java:555) [na:1.8.0_112]
at java.util.TimerThread.run(Timer.java:505) [na:1.8.0_112]
Caused by: org.springframework.core.convert.ConversionFailedException: Failed 
to convert from type [java.util.Arrays$ArrayList] to type [java.lang.String] 
for value '[Person{name='Peter', age=25}, Person{name='John', age=33}]'; nested 
exception is org.springframework.core.convert.ConverterNotFoundException: No 
converter found capable of converting from type [java.util.Arrays$ArrayList] 
to type [java.lang.String]
at 
org.springframework.core.convert.support.ConversionUtils.invokeConverter(ConversionUtils.java:42)
 ~[spring-core-4.3.3.RELEASE.jar:4.3.3.RELEASE]
 

[jira] [Commented] (CAMEL-10490) JpaPollingConsumer does not support consumeLockEntity and others

2016-11-30 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CAMEL-10490:


Github user asfgit closed the pull request at:

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


> JpaPollingConsumer does not support consumeLockEntity and others
> 
>
> Key: CAMEL-10490
> URL: https://issues.apache.org/jira/browse/CAMEL-10490
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jpa
>Affects Versions: 2.18.0
>Reporter: Bob Gaudaen
> Fix For: 2.18.2, 2.19.0
>
>
> Since the introduction of JpaPollingConsumer in camel 2.18.0, it is not 
> possible anymore to use some of jpa consumer options (consumeLockEntity, 
> consumeDelete, ...).
> Documentation also lacks some information on which option can be used by the 
> jpa consumer and not by the polling consumer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10490) JpaPollingConsumer does not support consumeLockEntity and others

2016-11-30 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CAMEL-10490:


GitHub user bgaudaen opened a pull request:

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

CAMEL-10490: Implemented consumeLockEntity and lockModeType options on 
JpaPollingConsumer



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

$ git pull https://github.com/bgaudaen/camel master

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

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

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

This closes #1322


commit a972befaa7b27c6af49e40e0e5147939c66a189e
Author: Bob Gaudaen 
Date:   2016-11-18T16:01:12Z

CAMEL-10490 Wrote unit test to illustrate concurrency problem

commit dcdb619e60383105fdafc71fb94aed86c686f588
Author: Bob Gaudaen 
Date:   2016-11-18T16:04:08Z

CAMEL-10490 Added LockModeType in JpaPollingConsumer.

Still doesn't pass the test with the derby jdbc driver, but passes with 
MySQL...

commit 9a5f83f9a8a0d47038aeb16fa09c8db67c1ec6b0
Author: Bob Gaudaen 
Date:   2016-11-28T10:11:00Z

CAMEL-10490 Some code cleanup

commit 6795c114ac825f020b85d2a6929ddf5f200c78d5
Author: Bob Gaudaen 
Date:   2016-11-30T12:39:21Z

CAMEL-10490 Changed to optimistic lock mode type and added test for 
concurrent access without lock

commit f7586ffb04d4d8373856f899b3ed4b8095ad7ed9
Author: Bob Gaudaen 
Date:   2016-11-30T13:17:21Z

CAMEL-10490 CheckStyle warnings




> JpaPollingConsumer does not support consumeLockEntity and others
> 
>
> Key: CAMEL-10490
> URL: https://issues.apache.org/jira/browse/CAMEL-10490
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jpa
>Affects Versions: 2.18.0
>Reporter: Bob Gaudaen
> Fix For: 2.18.2, 2.19.0
>
>
> Since the introduction of JpaPollingConsumer in camel 2.18.0, it is not 
> possible anymore to use some of jpa consumer options (consumeLockEntity, 
> consumeDelete, ...).
> Documentation also lacks some information on which option can be used by the 
> jpa consumer and not by the polling consumer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10452) camel-salesforce: Add an option to simulate SELECT * from

2016-11-30 Thread Zoran Regvart (JIRA)

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

Zoran Regvart commented on CAMEL-10452:
---

I was thinking about metadata supplied by the user if the DTO classes were hand 
coded, and also an option to include (via annotations or properties) metadata 
in the generated DTO classes by the Maven plugin.

The example in that blog post is in Apex programming language, very similar to 
Java, so those methods are only available when run on Salesforce :(

> camel-salesforce: Add an option to simulate SELECT * from
> -
>
> Key: CAMEL-10452
> URL: https://issues.apache.org/jira/browse/CAMEL-10452
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Luca Burgazzoli
>Assignee: Zoran Regvart
>Priority: Minor
> Fix For: 2.19.0
>
>
> As today it is not possible to run a query like SELECT * from but one is 
> forced to list all the field he want.
> It would be nice to auto generate a statement using SObject meta data so one 
> can write:
> from("salesforce:stream?SObjectName=Case=true")
> to get all the fields the SObjectName supports.
> [~dhirajsb] what do you think ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10547) No Exception on invalid charset option

2016-11-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen commented on CAMEL-10547:
-

Ah you wont get any exception on startup as the uri is 100% dynamic, and 
computed on demand. However at runtime it ought to fail with a invalid option 
because charset has an invalid value.

> No Exception on invalid charset option
> --
>
> Key: CAMEL-10547
> URL: https://issues.apache.org/jira/browse/CAMEL-10547
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: windows 7
>Reporter: morten skou nielsen
>Priority: Minor
>
> I get no exception when building this:
> .toD("file://" + outputDirectory + File.separator + 
> "?fileExist=Append=$(header.inputFileEncoding)");
> The code only breaks when i try to write to the file due to 
> NoSuchFileException. 
> I would have expected to get a camel.FailedToCreateRouteException since the 
> charset option is invalid
> see nable
> http://camel.465427.n5.nabble.com/dynamic-endpoint-with-dynamic-encoding-td5790768.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-10519) Disable TLSv1.0 in camel-salesforce

2016-11-30 Thread Zoran Regvart (JIRA)

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

Zoran Regvart resolved CAMEL-10519.
---
Resolution: Fixed

Merged into 2.17.x branch

> Disable TLSv1.0 in camel-salesforce
> ---
>
> Key: CAMEL-10519
> URL: https://issues.apache.org/jira/browse/CAMEL-10519
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
> Fix For: 2.17.5
>
>
> Salesforce is [disabling 
> TLSv1.0|https://help.salesforce.com/HTViewSolution?id=000221207] connections 
> for production organizations on March 4, 2017.
> As a proactive measure for clients not running Java 8 (or newer) we should 
> change the defaults to disable TLSv.1.0 if the runtime supports TLSv1.1 or 
> newer or issue a warning if clients can use only TLSv1.0 (Java 6 before 
> update 111).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-10547) No Exception on invalid charset option

2016-11-30 Thread morten skou nielsen (JIRA)
morten skou nielsen created CAMEL-10547:
---

 Summary: No Exception on invalid charset option
 Key: CAMEL-10547
 URL: https://issues.apache.org/jira/browse/CAMEL-10547
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.18.0
 Environment: windows 7
Reporter: morten skou nielsen
Priority: Minor


I get no exception when building this:

.toD("file://" + outputDirectory + File.separator + 
"?fileExist=Append=$(header.inputFileEncoding)");

The code only breaks when i try to write to the file due to 
NoSuchFileException. 

I would have expected to get a camel.FailedToCreateRouteException since the 
charset option is invalid

see nable
http://camel.465427.n5.nabble.com/dynamic-endpoint-with-dynamic-encoding-td5790768.html




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-10271) camel-jt400 - Failed to resolve endpoint

2016-11-30 Thread JIRA

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

Jean-Baptiste Onofré updated CAMEL-10271:
-
Fix Version/s: 2.15.6
   2.16.5

> camel-jt400 - Failed to resolve endpoint
> 
>
> Key: CAMEL-10271
> URL: https://issues.apache.org/jira/browse/CAMEL-10271
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jt400
>Affects Versions: 2.17.3
>Reporter: Michael Watson
>Assignee: Jean-Baptiste Onofré
> Fix For: 2.15.6, 2.16.5, 2.17.4, 2.18.0
>
>
> Apologies for creating this in core, as there does not seem to be an entry  
> for camel-jt400 (but the jar is distributed with 2.17.3)
> Creating a data queue end point using JT400 as per the documentation crashes 
> out when the endpoint creation starts. This seems identical to the SNMP issue 
> CAMEL-8479 (as it produces identical output other than the component name). 
> Ideally the JT400Endpoint would be updated to return true for isLenient, or 
> the default properties would be cleared prior to 
> DefaultEndpoint.createEndpoint being called. Have not been able to find how 
> the original SNMP issue was corrected and have been unable to find a 
> workaround for it.
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve 
> endpoint: 
> jt400://:x...@alpha8.mdsuk.com/QSYS.LIB/.LIB/SENDJOB.DTAQ?consumer.initialDelay=2000=binary
>  due to: There are 15 parameters that couldn't be set on the endpoint 
> consumer. Check the uri if the parameters are spelt correctly and that they 
> are properties of the endpoint. Unknown consumer 
> parameters=[{backoffMultiplier=0, sendEmptyMessageWhenIdle=false, 
> schedulerProperties=null, initialDelay=2000, backoffIdleThreshold=0, 
> scheduler=null, delay=500, useFixedDelay=true, 
> pollStrategy=org.apache.camel.impl.DefaultPollingConsumerPollStrategy@2172f79b,
>  startScheduler=true, runLoggingLevel=TRACE, backoffErrorThreshold=0, 
> greedy=false, scheduledExecutorService=null, timeUnit=MILLISECONDS}]
>   at 
> org.apache.camel.impl.DefaultEndpoint.configureConsumer(DefaultEndpoint.java:510)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.component.jt400.Jt400Endpoint.createConsumer(Jt400Endpoint.java:92)
>  ~[camel-jt400-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:69)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:103) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at org.apache.camel.impl.RouteService.warmUp(RouteService.java:158) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:3496)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3426)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3203)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3059)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2854)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2850)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2873)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2850)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2819)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:270)
>  ~[camel-spring-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.spring.SpringCamelContext.afterPropertiesSet(SpringCamelContext.java:122)
>  ~[camel-spring-2.17.3.jar!/:2.17.3]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>  ~[spring-beans-4.3.0.RELEASE.jar!/:4.3.0.RELEASE]
>   at 
> 

[jira] [Reopened] (CAMEL-10271) camel-jt400 - Failed to resolve endpoint

2016-11-30 Thread JIRA

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

Jean-Baptiste Onofré reopened CAMEL-10271:
--

I reopen this Jira as camel-jt400 2.15.x and 2.16.x are also impacted (and lot 
of users still use this version).

I will backport the fix on camel-2.15.x and camel-2.16.x branches.

> camel-jt400 - Failed to resolve endpoint
> 
>
> Key: CAMEL-10271
> URL: https://issues.apache.org/jira/browse/CAMEL-10271
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jt400
>Affects Versions: 2.17.3
>Reporter: Michael Watson
>Assignee: Jean-Baptiste Onofré
> Fix For: 2.15.6, 2.16.5, 2.17.4, 2.18.0
>
>
> Apologies for creating this in core, as there does not seem to be an entry  
> for camel-jt400 (but the jar is distributed with 2.17.3)
> Creating a data queue end point using JT400 as per the documentation crashes 
> out when the endpoint creation starts. This seems identical to the SNMP issue 
> CAMEL-8479 (as it produces identical output other than the component name). 
> Ideally the JT400Endpoint would be updated to return true for isLenient, or 
> the default properties would be cleared prior to 
> DefaultEndpoint.createEndpoint being called. Have not been able to find how 
> the original SNMP issue was corrected and have been unable to find a 
> workaround for it.
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve 
> endpoint: 
> jt400://:x...@alpha8.mdsuk.com/QSYS.LIB/.LIB/SENDJOB.DTAQ?consumer.initialDelay=2000=binary
>  due to: There are 15 parameters that couldn't be set on the endpoint 
> consumer. Check the uri if the parameters are spelt correctly and that they 
> are properties of the endpoint. Unknown consumer 
> parameters=[{backoffMultiplier=0, sendEmptyMessageWhenIdle=false, 
> schedulerProperties=null, initialDelay=2000, backoffIdleThreshold=0, 
> scheduler=null, delay=500, useFixedDelay=true, 
> pollStrategy=org.apache.camel.impl.DefaultPollingConsumerPollStrategy@2172f79b,
>  startScheduler=true, runLoggingLevel=TRACE, backoffErrorThreshold=0, 
> greedy=false, scheduledExecutorService=null, timeUnit=MILLISECONDS}]
>   at 
> org.apache.camel.impl.DefaultEndpoint.configureConsumer(DefaultEndpoint.java:510)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.component.jt400.Jt400Endpoint.createConsumer(Jt400Endpoint.java:92)
>  ~[camel-jt400-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:69)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:103) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at org.apache.camel.impl.RouteService.warmUp(RouteService.java:158) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:3496)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3426)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3203)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3059)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2854)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2850)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2873)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2850)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2819)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:270)
>  ~[camel-spring-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.spring.SpringCamelContext.afterPropertiesSet(SpringCamelContext.java:122)
>  ~[camel-spring-2.17.3.jar!/:2.17.3]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>  

[jira] [Assigned] (CAMEL-10271) camel-jt400 - Failed to resolve endpoint

2016-11-30 Thread JIRA

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

Jean-Baptiste Onofré reassigned CAMEL-10271:


Assignee: Jean-Baptiste Onofré  (was: Claus Ibsen)

> camel-jt400 - Failed to resolve endpoint
> 
>
> Key: CAMEL-10271
> URL: https://issues.apache.org/jira/browse/CAMEL-10271
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jt400
>Affects Versions: 2.17.3
>Reporter: Michael Watson
>Assignee: Jean-Baptiste Onofré
> Fix For: 2.17.4, 2.18.0
>
>
> Apologies for creating this in core, as there does not seem to be an entry  
> for camel-jt400 (but the jar is distributed with 2.17.3)
> Creating a data queue end point using JT400 as per the documentation crashes 
> out when the endpoint creation starts. This seems identical to the SNMP issue 
> CAMEL-8479 (as it produces identical output other than the component name). 
> Ideally the JT400Endpoint would be updated to return true for isLenient, or 
> the default properties would be cleared prior to 
> DefaultEndpoint.createEndpoint being called. Have not been able to find how 
> the original SNMP issue was corrected and have been unable to find a 
> workaround for it.
> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve 
> endpoint: 
> jt400://:x...@alpha8.mdsuk.com/QSYS.LIB/.LIB/SENDJOB.DTAQ?consumer.initialDelay=2000=binary
>  due to: There are 15 parameters that couldn't be set on the endpoint 
> consumer. Check the uri if the parameters are spelt correctly and that they 
> are properties of the endpoint. Unknown consumer 
> parameters=[{backoffMultiplier=0, sendEmptyMessageWhenIdle=false, 
> schedulerProperties=null, initialDelay=2000, backoffIdleThreshold=0, 
> scheduler=null, delay=500, useFixedDelay=true, 
> pollStrategy=org.apache.camel.impl.DefaultPollingConsumerPollStrategy@2172f79b,
>  startScheduler=true, runLoggingLevel=TRACE, backoffErrorThreshold=0, 
> greedy=false, scheduledExecutorService=null, timeUnit=MILLISECONDS}]
>   at 
> org.apache.camel.impl.DefaultEndpoint.configureConsumer(DefaultEndpoint.java:510)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.component.jt400.Jt400Endpoint.createConsumer(Jt400Endpoint.java:92)
>  ~[camel-jt400-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:69)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:103) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at org.apache.camel.impl.RouteService.warmUp(RouteService.java:158) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:3496)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3426)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3203)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3059)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2854)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2850)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2873)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2850)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61) 
> ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2819)
>  ~[camel-core-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:270)
>  ~[camel-spring-2.17.3.jar!/:2.17.3]
>   at 
> org.apache.camel.spring.SpringCamelContext.afterPropertiesSet(SpringCamelContext.java:122)
>  ~[camel-spring-2.17.3.jar!/:2.17.3]
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>  ~[spring-beans-4.3.0.RELEASE.jar!/:4.3.0.RELEASE]
>   at 
> 

[jira] [Commented] (CAMEL-1077) tcp client mode / server mode determined by "to" or "from" elements limits usability.

2016-11-30 Thread Willem Jiang (JIRA)

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

Willem Jiang commented on CAMEL-1077:
-

Hi Dima,
Current camel doesn't support to create  a server socket from the "To" endpoint.
If you want to open a socket to listen to port 12345, you need to setup a route 
just like this.
{code}
from("netty4:tcp://0.0.0.0:12345?transferExchange=true=true=false=false")...
{code}

> tcp client mode / server mode determined by "to" or "from" elements limits 
> usability.
> -
>
> Key: CAMEL-1077
> URL: https://issues.apache.org/jira/browse/CAMEL-1077
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-mina
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Jeff Vienneau
>Assignee: Willem Jiang
> Fix For: 2.15.0
>
>
> Internally, 
> MinaProducer is coded to create a Mina connector (client mode socket).
> MinaConsumer is coded to create a Mina acceptor (server mode socket).
> Additionally, it appears a producer (client mode socket) is created for a 
> "to" route mapping and a consumer (server mode socket) is created for a 
> "from" route mapping.
> This means an endpoint cannot be created in which the session is initiated by 
> a client and messages are routed "to" the client. 
> The opposite is also true, an endpoint with a "from" route mapping cannot 
> establish a connection to a tcp server.
> This is a major limitation, as we do not often have control over the systems 
> with which we are interfacing.
> Perhaps, the mina::tcp URI could have a parameter the sets the socket mode: 
> tcp.mode=server or tcp.mode=client.
> Hope this make sense, thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-1077) tcp client mode / server mode determined by "to" or "from" elements limits usability.

2016-11-30 Thread Willem Jiang (JIRA)

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

Willem Jiang commented on CAMEL-1077:
-

Hi Dima,
Current camel doesn't support to create  a server socket from the "To" endpoint.
If you want to open a socket to listen to port 12345, you need to setup a route 
just like this.
{code}
from("netty4:tcp://0.0.0.0:12345?transferExchange=true=true=false=false")...
{code}

> tcp client mode / server mode determined by "to" or "from" elements limits 
> usability.
> -
>
> Key: CAMEL-1077
> URL: https://issues.apache.org/jira/browse/CAMEL-1077
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-mina
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Jeff Vienneau
>Assignee: Willem Jiang
> Fix For: 2.15.0
>
>
> Internally, 
> MinaProducer is coded to create a Mina connector (client mode socket).
> MinaConsumer is coded to create a Mina acceptor (server mode socket).
> Additionally, it appears a producer (client mode socket) is created for a 
> "to" route mapping and a consumer (server mode socket) is created for a 
> "from" route mapping.
> This means an endpoint cannot be created in which the session is initiated by 
> a client and messages are routed "to" the client. 
> The opposite is also true, an endpoint with a "from" route mapping cannot 
> establish a connection to a tcp server.
> This is a major limitation, as we do not often have control over the systems 
> with which we are interfacing.
> Perhaps, the mina::tcp URI could have a parameter the sets the socket mode: 
> tcp.mode=server or tcp.mode=client.
> Hope this make sense, thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CAMEL-10546) CamelContext - Rename getProperties to getConfiguration

2016-11-30 Thread Claus Ibsen (JIRA)
Claus Ibsen created CAMEL-10546:
---

 Summary: CamelContext - Rename getProperties to getConfiguration
 Key: CAMEL-10546
 URL: https://issues.apache.org/jira/browse/CAMEL-10546
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Claus Ibsen
Priority: Minor
 Fix For: 2.19.0


People may mistake this with property placeholders. However its used for 
generic key/value pairs for configuring some global options on CamelContext 
such as max debug log length etc.

An alternative is to change this configuration to be a type safe configuration 
which then adds fluent DSL support in Java and also in XML.

But for 2.x we could add methods called getConfiguration() / setConfiguration() 
and deprecate the older methods so people get more aware of this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CAMEL-10542) DataFormat from registry is used for every dataformat operation (marshal/unmarshal)

2016-11-30 Thread Luca Burgazzoli (JIRA)

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

Luca Burgazzoli edited comment on CAMEL-10542 at 11/30/16 9:03 AM:
---

Yes you don't as in such case the dataformat instance is created using 
"service-loader" style thus a new instance is created each time 
DefaultDataFormatResolver::resolveDataFormat is invoked. I have experimentedd 
with @Scope("prototype") and it solves the issue for Spring Boot, but I do not 
know what could be optimal solution that would cover all the cases and 
containers.


was (Author: lb):
Yes you don't as in such case the dataformat instance is created using 
"service-loader" style thus a new instance is created each time 
DefaultDataFormatResolver::resolveDataFormat is invoked.

> DataFormat from registry is used for every dataformat operation 
> (marshal/unmarshal)
> ---
>
> Key: CAMEL-10542
> URL: https://issues.apache.org/jira/browse/CAMEL-10542
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.2, 2.19.0
>
>
> While working on an issue related to spring-boot I found out that if a data 
> format is registered in camel registry with the same name as the one camel 
> looks-up with the help of DefaultDataFormatResolver, this object is then 
> re-configured for each data format definition so one definition may override 
> previous configuration with an undefined behavior.
> So assume you have an xml route definitions as:
> {code:xml}
> http://camel.apache.org/schema/spring;>
>   
> 
> 
>   
> 
>   
>   
> 
> 
>   
> 
>   
> 
> {code}
> And some code like:
> {code:java}
> InputStream is = getClass().getResourceAsStream("...");
> SimpleRegistry reg = new SimpleRegistry();
> reg.put("csv-dataformat", new CsvDataFormat());
> DefaultCamelContext ctx = new DefaultCamelContext(reg);
> ctx.addRouteDefinitions(ctx.loadRoutesDefinition(is).getRoutes());
> ctx.start();
> ProducerTemplate template = ctx.createProducerTemplate();
> String result = template.requestBody(
> "direct:marshal",
> Arrays.asList(Arrays.asList( "A1", "B1", "C1" )),
> String.class);
> assertEquals("A1,B1,C1", result);
> ctx.stop
> {code}
> Then this test fails with:
> {code}
> Expected :A1,B1,C1
> Actual   :A1;B1;C1
> {code}
> It fails because the object added to the SimpleRegistry is shared among the 
> two csv dataformats  so it is configured to have delimiter = ';' 
> For spring-boot this causes some issues as it registers data formats beans as 
> part of its auto-configuration magic thus if you do not set your own instance 
> of data format, any data format operation like marshal/unmarshal may not work 
> as expected. 
> - for spring-boot a solution would be to annotate auto configured data format 
> beans with prototype scope.
> - a more generic solution would be to make DataFormat Cloneable and clone the 
> bean found in the registry



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10542) DataFormat from registry is used for every dataformat operation (marshal/unmarshal)

2016-11-30 Thread Luca Burgazzoli (JIRA)

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

Luca Burgazzoli commented on CAMEL-10542:
-

Yes you don't as in such case the dataformat instance is created using 
"service-loader" style thus a new instance is created each time 
DefaultDataFormatResolver::resolveDataFormat is invoked.

> DataFormat from registry is used for every dataformat operation 
> (marshal/unmarshal)
> ---
>
> Key: CAMEL-10542
> URL: https://issues.apache.org/jira/browse/CAMEL-10542
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.2, 2.19.0
>
>
> While working on an issue related to spring-boot I found out that if a data 
> format is registered in camel registry with the same name as the one camel 
> looks-up with the help of DefaultDataFormatResolver, this object is then 
> re-configured for each data format definition so one definition may override 
> previous configuration with an undefined behavior.
> So assume you have an xml route definitions as:
> {code:xml}
> http://camel.apache.org/schema/spring;>
>   
> 
> 
>   
> 
>   
>   
> 
> 
>   
> 
>   
> 
> {code}
> And some code like:
> {code:java}
> InputStream is = getClass().getResourceAsStream("...");
> SimpleRegistry reg = new SimpleRegistry();
> reg.put("csv-dataformat", new CsvDataFormat());
> DefaultCamelContext ctx = new DefaultCamelContext(reg);
> ctx.addRouteDefinitions(ctx.loadRoutesDefinition(is).getRoutes());
> ctx.start();
> ProducerTemplate template = ctx.createProducerTemplate();
> String result = template.requestBody(
> "direct:marshal",
> Arrays.asList(Arrays.asList( "A1", "B1", "C1" )),
> String.class);
> assertEquals("A1,B1,C1", result);
> ctx.stop
> {code}
> Then this test fails with:
> {code}
> Expected :A1,B1,C1
> Actual   :A1;B1;C1
> {code}
> It fails because the object added to the SimpleRegistry is shared among the 
> two csv dataformats  so it is configured to have delimiter = ';' 
> For spring-boot this causes some issues as it registers data formats beans as 
> part of its auto-configuration magic thus if you do not set your own instance 
> of data format, any data format operation like marshal/unmarshal may not work 
> as expected. 
> - for spring-boot a solution would be to annotate auto configured data format 
> beans with prototype scope.
> - a more generic solution would be to make DataFormat Cloneable and clone the 
> bean found in the registry



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-10543) New Apache Camel Logo

2016-11-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated CAMEL-10543:

Description: 
The Apache Camel logo is a bit out dated so we have discussed in the Camel PMC 
and community to come up with a new one.
We encourage anyone to participate by submitting a logo proposal and/or share 
thoughts

The logo can be submitted by either:
- a PR on GitHub (preferred)
- file attachment to this JIRA ticket

And each logo should be:
- images should be added to docs/img
- each PR should contains a single logo

We are looking for a new logo that has two parts

- graphical logo
- The name: Apache Camel

So we can use the logo without the word Apache Camel, but also as a combination 
of the two of them, eg as logo on the Camel front page.
Also if the logo can be vector based it would be a benefit, so it can scale up 
and down nicely.

You can find details here how to contribute to the project and how to work on 
the source code. Such as how to do a github PR:
http://camel.apache.org/contributing

  was:
The Apache Camel logo is a bit out dated so we have discussed in the Camel PMC 
and community to come up with a new one.
We encourage anyone to participate by submitting a logo proposal and/or share 
thoughts

The logo can be submitted by either:
- a PR on GitHub (preferred)
- file attachment to this JIRA ticket

And each logo should be:
- images should be added to docs/img
- each PR should contains a single logo

We are looking for a new logo that has two parts

- graphical logo
- The name: Apache Camel

So we can use the logo without the word Apache Camel, but also as a combination 
of the two of them, eg as logo on the Camel front page.
Also if the logo can be vector based it would be a benefit, so it can scale up 
and down nicely.



> New Apache Camel Logo
> -
>
> Key: CAMEL-10543
> URL: https://issues.apache.org/jira/browse/CAMEL-10543
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Luca Burgazzoli
> Fix For: Future
>
>
> The Apache Camel logo is a bit out dated so we have discussed in the Camel 
> PMC and community to come up with a new one.
> We encourage anyone to participate by submitting a logo proposal and/or share 
> thoughts
> The logo can be submitted by either:
> - a PR on GitHub (preferred)
> - file attachment to this JIRA ticket
> And each logo should be:
> - images should be added to docs/img
> - each PR should contains a single logo
> We are looking for a new logo that has two parts
> - graphical logo
> - The name: Apache Camel
> So we can use the logo without the word Apache Camel, but also as a 
> combination of the two of them, eg as logo on the Camel front page.
> Also if the logo can be vector based it would be a benefit, so it can scale 
> up and down nicely.
> You can find details here how to contribute to the project and how to work on 
> the source code. Such as how to do a github PR:
> http://camel.apache.org/contributing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-10543) New Apache Camel Logo

2016-11-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen updated CAMEL-10543:

Description: 
The Apache Camel logo is a bit out dated so we have discussed in the Camel PMC 
and community to come up with a new one.
We encourage anyone to participate by submitting a logo proposal and/or share 
thoughts

The logo can be submitted by either:
- a PR on GitHub (preferred)
- file attachment to this JIRA ticket

And each logo should be:
- images should be added to docs/img
- each PR should contains a single logo

We are looking for a new logo that has two parts

- graphical logo
- The name: Apache Camel

So we can use the logo without the word Apache Camel, but also as a combination 
of the two of them, eg as logo on the Camel front page.
Also if the logo can be vector based it would be a benefit, so it can scale up 
and down nicely.


  was:
The Apache Camel logo is a bit out dated so we have discussed in the community 
to come up with a new one. We encourage anyone to participate by submitting a 
PR on GitHub and share thoughts.

- images should be added to docs/img
- each PR should contains a single logo


> New Apache Camel Logo
> -
>
> Key: CAMEL-10543
> URL: https://issues.apache.org/jira/browse/CAMEL-10543
> Project: Camel
>  Issue Type: Improvement
>  Components: website
>Reporter: Luca Burgazzoli
> Fix For: Future
>
>
> The Apache Camel logo is a bit out dated so we have discussed in the Camel 
> PMC and community to come up with a new one.
> We encourage anyone to participate by submitting a logo proposal and/or share 
> thoughts
> The logo can be submitted by either:
> - a PR on GitHub (preferred)
> - file attachment to this JIRA ticket
> And each logo should be:
> - images should be added to docs/img
> - each PR should contains a single logo
> We are looking for a new logo that has two parts
> - graphical logo
> - The name: Apache Camel
> So we can use the logo without the word Apache Camel, but also as a 
> combination of the two of them, eg as logo on the Camel front page.
> Also if the logo can be vector based it would be a benefit, so it can scale 
> up and down nicely.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

2016-11-30 Thread Antonin Stefanutti (JIRA)

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

Antonin Stefanutti updated CAMEL-10391:
---
Fix Version/s: 2.19.0

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
> Fix For: 2.19.0
>
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CAMEL-10542) DataFormat from registry is used for every dataformat operation (marshal/unmarshal)

2016-11-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen commented on CAMEL-10542:
-

So if you change the name from "csv-dataformat" to "foo" then you dont have 
this problem?

> DataFormat from registry is used for every dataformat operation 
> (marshal/unmarshal)
> ---
>
> Key: CAMEL-10542
> URL: https://issues.apache.org/jira/browse/CAMEL-10542
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
> Fix For: 2.18.2, 2.19.0
>
>
> While working on an issue related to spring-boot I found out that if a data 
> format is registered in camel registry with the same name as the one camel 
> looks-up with the help of DefaultDataFormatResolver, this object is then 
> re-configured for each data format definition so one definition may override 
> previous configuration with an undefined behavior.
> So assume you have an xml route definitions as:
> {code:xml}
> http://camel.apache.org/schema/spring;>
>   
> 
> 
>   
> 
>   
>   
> 
> 
>   
> 
>   
> 
> {code}
> And some code like:
> {code:java}
> InputStream is = getClass().getResourceAsStream("...");
> SimpleRegistry reg = new SimpleRegistry();
> reg.put("csv-dataformat", new CsvDataFormat());
> DefaultCamelContext ctx = new DefaultCamelContext(reg);
> ctx.addRouteDefinitions(ctx.loadRoutesDefinition(is).getRoutes());
> ctx.start();
> ProducerTemplate template = ctx.createProducerTemplate();
> String result = template.requestBody(
> "direct:marshal",
> Arrays.asList(Arrays.asList( "A1", "B1", "C1" )),
> String.class);
> assertEquals("A1,B1,C1", result);
> ctx.stop
> {code}
> Then this test fails with:
> {code}
> Expected :A1,B1,C1
> Actual   :A1;B1;C1
> {code}
> It fails because the object added to the SimpleRegistry is shared among the 
> two csv dataformats  so it is configured to have delimiter = ';' 
> For spring-boot this causes some issues as it registers data formats beans as 
> part of its auto-configuration magic thus if you do not set your own instance 
> of data format, any data format operation like marshal/unmarshal may not work 
> as expected. 
> - for spring-boot a solution would be to annotate auto configured data format 
> beans with prototype scope.
> - a more generic solution would be to make DataFormat Cloneable and clone the 
> bean found in the registry



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CAMEL-10545) Canot start DefaultCamelContext

2016-11-30 Thread Claus Ibsen (JIRA)

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

Claus Ibsen resolved CAMEL-10545.
-
Resolution: Invalid

Please use user forum / user mailing list to get help first
http://camel.apache.org/discussion-forums.html
http://camel.apache.org/mailing-lists.html

> Canot start DefaultCamelContext
> ---
>
> Key: CAMEL-10545
> URL: https://issues.apache.org/jira/browse/CAMEL-10545
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.18.0
>Reporter: Ben Cheng
>
> I simply create DefaultCamelContext and start. 
> public class Appl {
>   public static void main(String[] args) throws Exception{
>   CamelContext context = new DefaultCamelContext();
>   context.start();
> }
> }
> It throws exception:
> Exception in thread "main" java.lang.UnsupportedOperationException
>   at 
> java.util.concurrent.CopyOnWriteArrayList$COWIterator.set(CopyOnWriteArrayList.java:1185)
>   at java.util.Collections.sort(Collections.java:234)
>   at 
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3525)
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3308)
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3162)
>   at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:182)
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2957)
>   at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2953)
>   at 
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2976)
>   at 
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2953)
>   at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
>   at 
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2920)
>   at com.techoffice.example.Appl.main(Appl.java:18)
> If I tested with version: 2.14.4, every thing works fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)