[jira] [Assigned] (CAMEL-15653) Improve SJMS Batch Logging
[
https://issues.apache.org/jira/browse/CAMEL-15653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viral Gohel reassigned CAMEL-15653:
---
Assignee: Viral Gohel
> Improve SJMS Batch Logging
> --
>
> Key: CAMEL-15653
> URL: https://issues.apache.org/jira/browse/CAMEL-15653
> Project: Camel
> Issue Type: Improvement
> Components: camel-sjms
>Affects Versions: 3.4.3
>Reporter: Brad Harvey
>Assignee: Viral Gohel
>Priority: Major
> Attachments: sjmsbatchloggingpatch.txt
>
>
> When there are multiple SJMS-Batch consumers in a camel context it is
> currently very difficult to work out which one some of the log messages apply
> to because many don't include the URI or queue name and happen outside the
> context of a route (so route MDC logging doesn't help).
> Suggested improvements:
> * Thread names should include the destination name. The standard jms
> component consumers already do this.
> * Most log messages (especially error messages) should include the
> destination name.
> It may be appropriate to use the consumer URI without query parameters
> instead of the destination name - I'm not sure if there is a standard
> approach used by other components.
>
> Examples of current log messages from a spring boot app:
> {code:java}
> 2020-10-08 10:38:31.313 WARN ||| 12468 --- [Camel (camel-1) thread #21 -
> AsyncStartStopListener] o.a.c.c.sjms.batch.SjmsBatchConsumer : Error
> starting consumer after 1 attempts. Will try again in 5000 millis.. Caused
> by: [org.apache.qpid.jms.exceptions.JMSSecuritySaslException - Client failed
> to authenticate using SASL: PLAIN]
> 2020-10-07 14:11:44.351 INFO ||| 27720 --- [Camel (camel-1) thread #15 -
> SjmsBatchConsumer] o.a.c.c.sjms.batch.SjmsBatchConsumer : Shutdown signal
> received - rolling back batch
> {code}
>
> Example of current thread name from SJMS-Batch consumer: "Camel (camel-1)
> thread #13 - SjmsBatchConsumer"
>
> Queue name in AsyncStartStopListener might be helpful too - currently: "Camel
> (camel-1) thread #6 - AsyncStartStopListener"
>
> In contrast, the standard JMS component includes the queue name in the thread
> name and in error messages:
> {code:java}
> 2020-10-08 10:38:35.245 WARN ||| 12468 --- [Camel (camel-1) thread #12 -
> JmsConsumer[myQueueName]] c.c.j.DefaultJmsMessageListenerContainer : Setup of
> JMS message listener invoker failed for destination 'myQueueName' - trying to
> recover. Cause: The transport is not running.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-15650) Upgrade to apache spark 3.x
[ https://issues.apache.org/jira/browse/CAMEL-15650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-15650: --- Assignee: Viral Gohel > Upgrade to apache spark 3.x > --- > > Key: CAMEL-15650 > URL: https://issues.apache.org/jira/browse/CAMEL-15650 > Project: Camel > Issue Type: Improvement > Components: camel-spark >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 3.x > > > The camel-spark is using older version of spark. We should upgrade to 3.x and > this also uses hadoop 3.x so we can get rid of the last hadoop 2.x dependency. > There is no apache karaf problem as spark and hadoop are not there as > features (dont work in osgi anyway) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-15580) SJMS Batch Consumer startup race condition
[
https://issues.apache.org/jira/browse/CAMEL-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viral Gohel reassigned CAMEL-15580:
---
Assignee: Viral Gohel
> SJMS Batch Consumer startup race condition
> --
>
> Key: CAMEL-15580
> URL: https://issues.apache.org/jira/browse/CAMEL-15580
> Project: Camel
> Issue Type: Bug
> Components: camel-sjms
>Affects Versions: 3.4.3
>Reporter: Brad Harvey
>Assignee: Viral Gohel
>Priority: Major
> Fix For: 3.6.0, 3.4.5
>
> Attachments: potentialPatch.txt
>
>
> There is a race condition between the SJMS Batch Consumer route start thread
> and the batch consumption loop thread. When it triggers the batch
> consumption loop exits early and the SJMS Batch Consumer does not read any
> JMS messages.
> In short:
> * The AtomicBoolean running is used as a flag to shut down the batch
> consumption loop
> * The batch consumption loop is submitted to another thread and only after
> that running is changed to true
> * This means sometimes the batch consumption loop sees running as false
> during startup
> The easiest way to reproduce it is to add a sleep into
> SJMSBatchConsumer$StartConsumerTask#run
>
> {code:java}
> final List triggers = new ArrayList<>();
> for (int i = 0; i < consumerCount; i++) {
> BatchConsumptionLoop loop = new BatchConsumptionLoop();
> loop.setKeepAliveDelay(keepAliveDelay);
> triggers.add(loop.getCompletionTimeoutTrigger());
> /*
> * Note: Batch consumption loop is submitted to another thread here
> */
> jmsConsumerExecutors.submit(loop);
> }
> if (completionInterval > 0) {
> // trigger completion based on interval
> timeoutCheckerExecutorService.scheduleAtFixedRate(new
> CompletionIntervalTask(triggers), completionInterval, completionInterval,
> TimeUnit.MILLISECONDS);
> }
> if (attempt > 1) {
> LOG.info("Successfully refreshed connection after {} attempts.", attempt);
> }
> /*
> * Note: Add this sleep to reproduce the race condition, simulating
> * this thread being pre-empted by other work
> */
> Thread.sleep(100);
> LOG.info("Started {} consumer(s) for {}:{}", consumerCount, destinationName,
> completionSize);
> /*
> * Note: running is only changed to true here but the batch consumption loop
> * that reads this values was submitted to another thread earlier
> */
> running.set(true);
> return;
> {code}
>
> The batch consumption loop checks the running flag like this:
> {code:java}
> private void consumeBatchesOnLoop(final Session session, final
> MessageConsumer consumer) throws JMSException {
> final boolean usingTimeout = completionTimeout > 0;
> LOG.trace("BatchConsumptionTask +++ start +++");
> while (running.get()) { {code}
>
> Usually there's a second check that would cause everything to loop again - it
> may see running as false but see isStarting() as true.
> {code:java}
> }while (running.get() || isStarting()); {code}
> But with asyncStartListener enabled I think that isStarting() is likely to be
> false as well.
>
> I believe this issue is causing fairly frequent intermittent test failures in
> our CI environment (jenkins slaves in kubernetes, linux). But I've been
> unable to reproduce it on my laptop (windows) without adding the artificial
> delay on the main thread.
> I've been able to get thread dumps from the CI environment showing the
> executor waiting for a task instead of executing the batch consumption loop
> {code:java}
> "Camel (camel-8) thread #125 - SjmsBatchConsumer"
>java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> Usually they should look like this:
> {code:java}
> "Camel (camel-8) thread #123 - SjmsBatchConsumer"
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.FifoMessageDispatchChannel.dequeue(FifoMessageDispatchChannel.java:74)
> at
> org.apache.activemq.ActiveMQMessageConsumer.dequeue(ActiveMQMessageConsumer.java:486)
> at
> org.apache.activemq.ActiveMQMessageCons
[jira] [Assigned] (CAMEL-15503) Apache Camel camel-openapi-java Schema Definitions not generating correctly
[ https://issues.apache.org/jira/browse/CAMEL-15503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-15503: --- Assignee: Viral Gohel > Apache Camel camel-openapi-java Schema Definitions not generating correctly > --- > > Key: CAMEL-15503 > URL: https://issues.apache.org/jira/browse/CAMEL-15503 > Project: Camel > Issue Type: Bug > Components: camel-openapi-java >Affects Versions: 3.4.3 >Reporter: Kate Hennessy >Assignee: Viral Gohel >Priority: Major > Attachments: camelOpenAPITest.zip > > > Classes defined in RestDefinition _type_ and _outType_ are not generating > correctly in openapi schema. This worked in the older older > camel-swagger-java component, the schema was generating with all object > definitions correctly. > > Please see this question on stack overflow for more details. > [https://stackoverflow.com/questions/63691670/apache-camel-camel-openapi-java-schema-definitions-not-generating-correctly] > > Sample project with the issue happening is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15503) Apache Camel camel-openapi-java Schema Definitions not generating correctly
[ https://issues.apache.org/jira/browse/CAMEL-15503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191215#comment-17191215 ] Viral Gohel commented on CAMEL-15503: - I will take a look into this. > Apache Camel camel-openapi-java Schema Definitions not generating correctly > --- > > Key: CAMEL-15503 > URL: https://issues.apache.org/jira/browse/CAMEL-15503 > Project: Camel > Issue Type: Bug > Components: camel-openapi-java >Affects Versions: 3.4.3 >Reporter: Kate Hennessy >Assignee: Viral Gohel >Priority: Major > Attachments: camelOpenAPITest.zip > > > Classes defined in RestDefinition _type_ and _outType_ are not generating > correctly in openapi schema. This worked in the older older > camel-swagger-java component, the schema was generating with all object > definitions correctly. > > Please see this question on stack overflow for more details. > [https://stackoverflow.com/questions/63691670/apache-camel-camel-openapi-java-schema-definitions-not-generating-correctly] > > Sample project with the issue happening is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-14158) camel-microprofile - Reactive Messaging component
[ https://issues.apache.org/jira/browse/CAMEL-14158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-14158: --- Assignee: Viral Gohel > camel-microprofile - Reactive Messaging component > - > > Key: CAMEL-14158 > URL: https://issues.apache.org/jira/browse/CAMEL-14158 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 3.x > > > We should look at adding a new camel component for MP reactive messaging spec > https://github.com/eclipse/microprofile-reactive-messaging -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-15106) KafkaConsumer: Support Suspend & Resume
[ https://issues.apache.org/jira/browse/CAMEL-15106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-15106: --- Assignee: Viral Gohel > KafkaConsumer: Support Suspend & Resume > --- > > Key: CAMEL-15106 > URL: https://issues.apache.org/jira/browse/CAMEL-15106 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Affects Versions: 3.3.0 >Reporter: Adithya Rao >Assignee: Viral Gohel >Priority: Minor > Attachments: SuspendableKafkaConsumer.txt > > > Can KafkaConsumer support suspend and resume using Kafka's consumer.pause() > and consumer.resume(). This keeps consumers alive and avoids recreating > consumers and rebalance. > rough attempt attached. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-15022) Opentracing doesn't work with Kafka Component
[ https://issues.apache.org/jira/browse/CAMEL-15022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-15022: --- Assignee: Viral Gohel > Opentracing doesn't work with Kafka Component > - > > Key: CAMEL-15022 > URL: https://issues.apache.org/jira/browse/CAMEL-15022 > Project: Camel > Issue Type: Bug > Components: camel-opentracing >Affects Versions: 2.23.4 >Reporter: Gerald Nunn >Assignee: Viral Gohel >Priority: Minor > Fix For: 3.x > > > In Kafka the headers are stored as byte arrays rather then string. > OpenTracing with Jaeger inserts a string header uber-trace-id which works. > However when it tries to read it as a string when the message is consumed it > presumably does a toString which doesn't return the actual string since the > header is returned as a byte array. > This can be worked around by using a KafkaHeaderDeserializer as per here: > https://github.com/gnunn1/seating/blob/master/seat-listener/src/main/java/com/redhat/demo/HeaderDeserializer.java > Note you need to deserialize the kafka.TOPIC as well since the > KafkaSpanDecorator tries to cast the header as a string which fails the > header is returned as byte array. > https://github.com/apache/camel/blob/camel-2.23.x/components/camel-opentracing/src/main/java/org/apache/camel/opentracing/decorators/KafkaSpanDecorator.java#L49 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15106) KafkaConsumer: Support Suspend & Resume
[ https://issues.apache.org/jira/browse/CAMEL-15106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129173#comment-17129173 ] Viral Gohel commented on CAMEL-15106: - I am looking into this. > KafkaConsumer: Support Suspend & Resume > --- > > Key: CAMEL-15106 > URL: https://issues.apache.org/jira/browse/CAMEL-15106 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Affects Versions: 3.3.0 >Reporter: Adithya Rao >Priority: Minor > Attachments: SuspendableKafkaConsumer.txt > > > Can KafkaConsumer support suspend and resume using Kafka's consumer.pause() > and consumer.resume(). This keeps consumers alive and avoids recreating > consumers and rebalance. > rough attempt attached. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-15132) Camel default thread pool - Should be allow core threads to timeout
[ https://issues.apache.org/jira/browse/CAMEL-15132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-15132: --- Assignee: Viral Gohel > Camel default thread pool - Should be allow core threads to timeout > --- > > Key: CAMEL-15132 > URL: https://issues.apache.org/jira/browse/CAMEL-15132 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 3.4.0 > > > Lets look at enabling core threads to timeout in the default thread pool > profile setting in Camel. As this allows idle threads to terminate. > For example with EIPs in parallel like splitter then you have 10 threads by > default. And if they become idle, then they stay around. We could allow those > threads to terminate as well. > This is a newer option in JDK but we are 8 as minimum so its safe to use now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-13786) camel-jms - Add option to configure deliveryDelay on JmsTemplate
[ https://issues.apache.org/jira/browse/CAMEL-13786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-13786: --- Assignee: Viral Gohel > camel-jms - Add option to configure deliveryDelay on JmsTemplate > > > Key: CAMEL-13786 > URL: https://issues.apache.org/jira/browse/CAMEL-13786 > Project: Camel > Issue Type: New Feature > Components: camel-jms >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 3.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The spring JmsTemplate has option deliveryDelay which you can set via its > setter. We should make this option in the endpoint/component level of > camel-jms. So users can easily configure it in Camel too. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CAMEL-13786) camel-jms - Add option to configure deliveryDelay on JmsTemplate
[ https://issues.apache.org/jira/browse/CAMEL-13786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891775#comment-16891775 ] Viral Gohel commented on CAMEL-13786: - I will take a look. > camel-jms - Add option to configure deliveryDelay on JmsTemplate > > > Key: CAMEL-13786 > URL: https://issues.apache.org/jira/browse/CAMEL-13786 > Project: Camel > Issue Type: New Feature > Components: camel-jms >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > > The spring JmsTemplate has option deliveryDelay which you can set via its > setter. We should make this option in the endpoint/component level of > camel-jms. So users can easily configure it in Camel too. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (CAMEL-13423) Path or query parameter is not allowed to have "+" character
[ https://issues.apache.org/jira/browse/CAMEL-13423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-13423: --- Assignee: Viral Gohel > Path or query parameter is not allowed to have "+" character > > > Key: CAMEL-13423 > URL: https://issues.apache.org/jira/browse/CAMEL-13423 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Reporter: SUYASH MANI SHARMA >Assignee: Viral Gohel >Priority: Major > > Hi, > > I have a URL like > [https://example.eu/v1/operator/%23%23%23%2B1%210025] > When I pass this URL to camel ahc, it converts the URL to > [https://idissuer.test.de.id-issuer.eu/v1/operator/%23%23%23+1]!0025. > > This is happening in UnsafeUriCharactersEncoder.encodeHttpUri method. > Even though "+" or "!" are not unsafe characters, it should be allowed to > pass them as path parameter or query parameter. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (CAMEL-13057) Upgrade to spring batch 4.1.x
[ https://issues.apache.org/jira/browse/CAMEL-13057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-13057: --- Assignee: Viral Gohel > Upgrade to spring batch 4.1.x > - > > Key: CAMEL-13057 > URL: https://issues.apache.org/jira/browse/CAMEL-13057 > Project: Camel > Issue Type: Task > Components: camel-spring-batch >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > There is a 4.1.x release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12966) camel-netty-http: use relative path by default
[ https://issues.apache.org/jira/browse/CAMEL-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-12966: --- Assignee: Andrea Cosentino (was: Viral Gohel) > camel-netty-http: use relative path by default > -- > > Key: CAMEL-12966 > URL: https://issues.apache.org/jira/browse/CAMEL-12966 > Project: Camel > Issue Type: Task >Reporter: Nicola Ferraro >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Netty-http 4 has a non-standard way of dealing with path, using the full url > on the first line of the HTTP request. E.g. > > GET [http://thehost/thepath] > instead of: > GET /thepath > > This is controlled by the useRelativePath, that should be defaulted to "true" > to be compatible with other components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12966) camel-netty-http: use relative path by default
[ https://issues.apache.org/jira/browse/CAMEL-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728703#comment-16728703 ] Viral Gohel commented on CAMEL-12966: - [~ancosen], my intention was only to help, not to overcome someone :). I had my tickets being reassigned and its fine for me. Anyways, i have reassigned this issue back to you, but i will work on the changes that need to be done. > camel-netty-http: use relative path by default > -- > > Key: CAMEL-12966 > URL: https://issues.apache.org/jira/browse/CAMEL-12966 > Project: Camel > Issue Type: Task >Reporter: Nicola Ferraro >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Netty-http 4 has a non-standard way of dealing with path, using the full url > on the first line of the HTTP request. E.g. > > GET [http://thehost/thepath] > instead of: > GET /thepath > > This is controlled by the useRelativePath, that should be defaulted to "true" > to be compatible with other components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12966) camel-netty-http: use relative path by default
[ https://issues.apache.org/jira/browse/CAMEL-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-12966: --- Assignee: Viral Gohel (was: Andrea Cosentino) > camel-netty-http: use relative path by default > -- > > Key: CAMEL-12966 > URL: https://issues.apache.org/jira/browse/CAMEL-12966 > Project: Camel > Issue Type: Task >Reporter: Nicola Ferraro >Assignee: Viral Gohel >Priority: Major > Fix For: 3.0.0, 2.24.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Netty-http 4 has a non-standard way of dealing with path, using the full url > on the first line of the HTTP request. E.g. > > GET [http://thehost/thepath] > instead of: > GET /thepath > > This is controlled by the useRelativePath, that should be defaulted to "true" > to be compatible with other components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12620) CompletionAwareAggregationStrategy onCompletition method null exchange.
[
https://issues.apache.org/jira/browse/CAMEL-12620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613780#comment-16613780
]
Viral Gohel commented on CAMEL-12620:
-
Hi [~luismospinam], Do you have a reproducer application which you can attach ?
It will be helpful to narrow down the issue and investigate.
> CompletionAwareAggregationStrategy onCompletition method null exchange.
> ---
>
> Key: CAMEL-12620
> URL: https://issues.apache.org/jira/browse/CAMEL-12620
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Luis Miguel
>Priority: Major
>
> Hello.
>
> We have a camel project to process some Csv files, we created a class
> implementing "CompletionAwareAggregationStrategy" in order to aggregate each
> row processed and we override the methods "aggregate" and "onCompletion" from
> it.
> The way we process the Csv file is parallelized with the "parallelProcessing"
> and indicating an "executorService" with 8 concurrently threads.
>
> We are having a weird issue that rarely happens, and is that in the middle of
> the process of the file, the method "onCompletion" is being called (even when
> the file is not complete yet) and it sets the argument "Exchange" as NULL so
> the whole camel route is messed up.
> As I said this rarely happens when we try to reprocess the file the error is
> gone.
>
>
>
> Here's the main route that process the CSV file, notice that for the split
> process we create an instance of "CsvAggregationStrategy"
>
> {code:java}
> @Qualifier("executorServicePublicationItemCsv")
> @Autowired
> private ExecutorService executorService;
> @Override
> public void configure() throws Exception {
> String[] header = Arrays.stream(PublicationItemCsvFields.values())
> .map(PublicationItemCsvFields::getText).toArray(String[]::new);
> Map csvFieldsByEntityAttribute = new HashMap<>();
> mapFields(csvFieldsByEntityAttribute);
> //@formatter:off
> from("file:publicationItemData?delete={{routes.push-csv-to-service.delete-source-file}}")
> .streamCaching()
> .routeId("push-publication-item-csv-to-service")
> .onException(Exception.class)
> .handled(true)
> .log(LoggingLevel.ERROR, "Error in publication item route, sending an email:
> ${exception.message} ${exception.stacktrace}")
> .to("direct:sendImportErrorReport")
> .end()
> .log(LoggingLevel.INFO, "Beginning to import publication item CSV:
> ${file:onlyname}")
> .unmarshal(new CsvDataFormat()
> .setSkipHeaderRecord(true)
> .setNullString(EMPTY)
> .setLazyLoad(true))
> .split(body(), new CsvAggregationStrategy())
> .streaming()
> .parallelProcessing().executorService(executorService)
> .to("direct:publication-item-splitter")
> .end()
> .choice()
> .when(simple("${exchangeProperty.aggregationError} != null"))
> .log("An error occurred when aggregating exchanges, sending an email with the
> error.")
> .setProperty("original_body", body())
> .to("direct:sendAggregationErrorEmail")
> .setBody(exchangeProperty("original_body"))
> .end()
> .choice()
> .when(simple("${exchangeProperty.badCsvData.size()} > 0"))
> .setBody(simple("${exchangeProperty.badCsvData}"))
> .marshal(new CsvDataFormat().setHeader(header))
> .setProperty("badRowsBody").simple("${body}")
> .end()
> .choice()
> .when(simple("${exchangeProperty.successfulRecords.size()} > 0"))
> .setBody(simple("${exchangeProperty.successfulRecords}"))
> .marshal(new CsvDataFormat().setHeader(header))
> .setProperty("successfulRowsBody").simple("${body}")
> .end()
> .to("direct:sendImportReport").end()
> .log("Completed import for publication item CSV: '${file:onlyname}'");
> from("direct:publication-item-splitter")
> .streamCaching()
> .routeId("push-publication-item-splitter")
> .onException(PublicationItemImportException.class)
> .handled(true)
> .log(LoggingLevel.ERROR, "Error importing publication item data:
> ${exception.message} ${exception.stacktrace}")
> .end()
> .onException(HttpHostConnectException.class)
> .handled(true)
> .log(LoggingLevel.ERROR, "Error connecting to publication item service host:
> ${exception.host}. Request body: ${body}")
> .end()
> .onException(HttpOperationFailedException.class)
> .handled(true)
> .log(LoggingLevel.ERROR, "Error received from publication item service: HTTP
> ${exception.statusCode}. Response body: ${exception.responseBody}. Request
> body: ${body}")
> .end()
> .onException(Exception.class)
> .handled(true)
> .log(LoggingLevel.ERROR, "Error: ${exception.message}
> ${exception.stacktrace}")
> .end()
> .setProperty("csvRowData").simple("${body}", List.class)
> .setProperty("csvFieldsByEntityAttribute").constant(csvFieldsByEntityAttribute)
> .bean(publicationItemCSVDataHandler)
> .marshal().json(JsonLibrary.Jackson)
> .setHeader(HttpHeaders.AUTHORIZATION, simple("Basic
> "
[jira] [Assigned] (CAMEL-12783) camel-spring-ws - Should support HeaderFilterStrategy
[ https://issues.apache.org/jira/browse/CAMEL-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-12783: --- Assignee: Viral Gohel > camel-spring-ws - Should support HeaderFilterStrategy > - > > Key: CAMEL-12783 > URL: https://issues.apache.org/jira/browse/CAMEL-12783 > Project: Camel > Issue Type: New Feature > Components: camel-spring-ws >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > > We should add support for HeaderFilterStrategy like some of the other > components do, so you can more easily filter headers in request vs response > use-cases. > Asked on SO: > https://stackoverflow.com/questions/52188019/how-to-filter-http-headers-for-apache-camel-spring-ws-services -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12805) camel-restdsl-swagger-plugin doesn't convert integer default value to string
[
https://issues.apache.org/jira/browse/CAMEL-12805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613047#comment-16613047
]
Viral Gohel commented on CAMEL-12805:
-
Thanks for reporting. Can you attach the complete json file which you are
using? From the snippets you provided, i am not getting the plugin to generate
code,
>> Unable to generate REST DSL Swagger sources from specification:
>> src/spec/example.json, make sure that the specification is available at the
>> given URI,
{code:java}
{
"name": "limit",
"in": "query",
"type": "integer",
"minimum": 1,
"default": 20,
"description": "the limit of the results for the collections query"
}{code}
> camel-restdsl-swagger-plugin doesn't convert integer default value to string
>
>
> Key: CAMEL-12805
> URL: https://issues.apache.org/jira/browse/CAMEL-12805
> Project: Camel
> Issue Type: Bug
> Components: tooling
>Affects Versions: 2.21.0
>Reporter: Jochen Cordes
>Priority: Major
>
> When generating a RouteBuilder from a swagger that defines default parameter
> values of type integer, there is no conversion to a string when setting it:
> Swagger:
> "limit":{
> "name":"limit",
> "in":"query",
> "type":"integer",
> "minimum":1,
> "default":20,
> "description":"the limit of the results for the collections query"
> },
> RouteBuilder:
> .param()
> .name("limit")
> .type(RestParamType.query)
> .dataType("integer")
> .defaultValue(20)
> .required(false)
> .description("the limit of the results for the collections query")
> .endParam()
> defaultValue only accepts parameters of type string and therefore the
> generated code can't be compiled and needs to be corrected manually.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CAMEL-12786) Option readLockLoggingLevel not working for SFTP changed read lock strategy
[
https://issues.apache.org/jira/browse/CAMEL-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viral Gohel reassigned CAMEL-12786:
---
Assignee: Viral Gohel
> Option readLockLoggingLevel not working for SFTP changed read lock strategy
> ---
>
> Key: CAMEL-12786
> URL: https://issues.apache.org/jira/browse/CAMEL-12786
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.19.0, 2.22.0
>Reporter: Seweryn Walendzik
>Assignee: Viral Gohel
>Priority: Trivial
>
> method setReadLockLoggingLevel is not invoked in class
> SftpProcessStrategyFactory so logging level is always set to default (WARN)
>
> {code:java}
> else if ("changed".equals(readLock)) {
> SftpChangedExclusiveReadLockStrategy readLockStrategy = new
> SftpChangedExclusiveReadLockStrategy();
> Long timeout = (Long) params.get("readLockTimeout");
> if (timeout != null) {
> readLockStrategy.setTimeout(timeout);
> }
> Long checkInterval = (Long) params.get("readLockCheckInterval");
> if (checkInterval != null) {
> readLockStrategy.setCheckInterval(checkInterval);
> }
> Long minLength = (Long) params.get("readLockMinLength");
> if (minLength != null) {
> readLockStrategy.setMinLength(minLength);
> }
> Long minAge = (Long) params.get("readLockMinAge");
> if (null != minAge) {
> readLockStrategy.setMinAge(minAge);
> }
> Boolean fastExistsCheck = (Boolean) params.get("fastExistsCheck");
> if (fastExistsCheck != null) {
> readLockStrategy.setFastExistsCheck(fastExistsCheck);
> }
> return readLockStrategy;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12786) Option readLockLoggingLevel not working for SFTP changed read lock strategy
[
https://issues.apache.org/jira/browse/CAMEL-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607012#comment-16607012
]
Viral Gohel commented on CAMEL-12786:
-
Thanks. I will take a look.
> Option readLockLoggingLevel not working for SFTP changed read lock strategy
> ---
>
> Key: CAMEL-12786
> URL: https://issues.apache.org/jira/browse/CAMEL-12786
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.19.0, 2.22.0
>Reporter: Seweryn Walendzik
>Priority: Trivial
>
> method setReadLockLoggingLevel is not invoked in class
> SftpProcessStrategyFactory so logging level is always set to default (WARN)
>
> {code:java}
> else if ("changed".equals(readLock)) {
> SftpChangedExclusiveReadLockStrategy readLockStrategy = new
> SftpChangedExclusiveReadLockStrategy();
> Long timeout = (Long) params.get("readLockTimeout");
> if (timeout != null) {
> readLockStrategy.setTimeout(timeout);
> }
> Long checkInterval = (Long) params.get("readLockCheckInterval");
> if (checkInterval != null) {
> readLockStrategy.setCheckInterval(checkInterval);
> }
> Long minLength = (Long) params.get("readLockMinLength");
> if (minLength != null) {
> readLockStrategy.setMinLength(minLength);
> }
> Long minAge = (Long) params.get("readLockMinAge");
> if (null != minAge) {
> readLockStrategy.setMinAge(minAge);
> }
> Boolean fastExistsCheck = (Boolean) params.get("fastExistsCheck");
> if (fastExistsCheck != null) {
> readLockStrategy.setFastExistsCheck(fastExistsCheck);
> }
> return readLockStrategy;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12786) Option readLockLoggingLevel not working for SFTP changed read lock strategy
[
https://issues.apache.org/jira/browse/CAMEL-12786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16606842#comment-16606842
]
Viral Gohel commented on CAMEL-12786:
-
Thanks for reporting. How are you trying to set the readLockLoggingLevel to
something other than WARN ?
> Option readLockLoggingLevel not working for SFTP changed read lock strategy
> ---
>
> Key: CAMEL-12786
> URL: https://issues.apache.org/jira/browse/CAMEL-12786
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.19.0, 2.22.0
>Reporter: Seweryn Walendzik
>Priority: Trivial
>
> method setReadLockLoggingLevel is not invoked in class
> SftpProcessStrategyFactory so logging level is always set to default (WARN)
>
> {code:java}
> else if ("changed".equals(readLock)) {
> SftpChangedExclusiveReadLockStrategy readLockStrategy = new
> SftpChangedExclusiveReadLockStrategy();
> Long timeout = (Long) params.get("readLockTimeout");
> if (timeout != null) {
> readLockStrategy.setTimeout(timeout);
> }
> Long checkInterval = (Long) params.get("readLockCheckInterval");
> if (checkInterval != null) {
> readLockStrategy.setCheckInterval(checkInterval);
> }
> Long minLength = (Long) params.get("readLockMinLength");
> if (minLength != null) {
> readLockStrategy.setMinLength(minLength);
> }
> Long minAge = (Long) params.get("readLockMinAge");
> if (null != minAge) {
> readLockStrategy.setMinAge(minAge);
> }
> Boolean fastExistsCheck = (Boolean) params.get("fastExistsCheck");
> if (fastExistsCheck != null) {
> readLockStrategy.setFastExistsCheck(fastExistsCheck);
> }
> return readLockStrategy;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CAMEL-12785) ServletComponent ignores httpBinding option
[
https://issues.apache.org/jira/browse/CAMEL-12785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viral Gohel reassigned CAMEL-12785:
---
Assignee: Viral Gohel
> ServletComponent ignores httpBinding option
> ---
>
> Key: CAMEL-12785
> URL: https://issues.apache.org/jira/browse/CAMEL-12785
> Project: Camel
> Issue Type: Bug
> Components: camel-servlet
>Affects Versions: 2.18.3
>Reporter: Paul McCulloch
>Assignee: Viral Gohel
>Priority: Major
>
> ServletComponent.doCreateConsumer() seems to consider the 'httpBindingRef'
> option when deciding whether or not to create a default HttpBinding. However
> this option was removed in 2.17
> (https://github.com/apache/camel/commit/df701cc3776833c98a3e2b53f86dfd8f01eabe4b
> )
> {{}}
> {{ }}
> {{ }}
> {{}}
> Doesn't use the custom binding. Providing a value for httpBindingRef causes
> the endpoint creation to fail (due to unknown parameters being included in
> the servlet:// URI.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12783) camel-spring-ws - Should support HeaderFilterStrategy
[ https://issues.apache.org/jira/browse/CAMEL-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605480#comment-16605480 ] Viral Gohel commented on CAMEL-12783: - will look > camel-spring-ws - Should support HeaderFilterStrategy > - > > Key: CAMEL-12783 > URL: https://issues.apache.org/jira/browse/CAMEL-12783 > Project: Camel > Issue Type: New Feature > Components: camel-spring-ws >Reporter: Claus Ibsen >Priority: Major > > We should add support for HeaderFilterStrategy like some of the other > components do, so you can more easily filter headers in request vs response > use-cases. > Asked on SO: > https://stackoverflow.com/questions/52188019/how-to-filter-http-headers-for-apache-camel-spring-ws-services -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12513) Camel breadcrumb - Consider turning it off by default
[ https://issues.apache.org/jira/browse/CAMEL-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605327#comment-16605327 ] Viral Gohel commented on CAMEL-12513: - I will take a look . > Camel breadcrumb - Consider turning it off by default > - > > Key: CAMEL-12513 > URL: https://issues.apache.org/jira/browse/CAMEL-12513 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > > This was added many years ago with the breadcrumbId header. But today there > is standards with opentracing / zipkin etc. > So ideally we should turn this off by default, and then point people to these > other standards. > [http://camel.apache.org/mdc-logging.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12772) camel-crypto-cms tests fail with OpenJDK
[
https://issues.apache.org/jira/browse/CAMEL-12772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16604263#comment-16604263
]
Viral Gohel commented on CAMEL-12772:
-
It seems to be an openjdk issue:
[https://bugs.openjdk.java.net/browse/JDK-8160342.]
Using Oracle JVM works for me too.
> camel-crypto-cms tests fail with OpenJDK
>
>
> Key: CAMEL-12772
> URL: https://issues.apache.org/jira/browse/CAMEL-12772
> Project: Camel
> Issue Type: Test
> Components: camel-crypto-cms
>Reporter: Tadayoshi Sato
>Priority: Major
> Fix For: 2.23.0
>
>
> I am not certain if it's a test bug or expected behaviour but when I run
> {{mvn clean install}} in {{camel-crypto-cms}} with OpenJDK 8, the tests
> always fail. They pass when I run it with Oracle JDK.
> I found a similar issue with WildFly-Camel as well:
> https://github.com/wildfly-extras/wildfly-camel/issues/2245
> My JDK version:
> {code}
> $ java -version
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> {code}
> Test output:
> {code}
> [ERROR] Tests run: 15, Failures: 0, Errors: 15, Skipped: 0, Time elapsed:
> 1.38 s <<< FAILURE! - in org.apache.camel.component.crypto.cms.ComponentTest
> [ERROR] wrongOperation(org.apache.camel.component.crypto.cms.ComponentTest)
> Time elapsed: 0.292 s <<< ERROR!
> org.apache.camel.component.crypto.cms.exception.CryptoCmsException: Problem
> during generating the keystore
> Caused by: java.security.cert.CertificateParsingException:
> java.io.IOException: Unknown named curve: 1.3.132.0.37
> Caused by: java.io.IOException: Unknown named curve: 1.3.132.0.37
> [ERROR] execute(org.apache.camel.component.crypto.cms.ComponentTest) Time
> elapsed: 0.04 s <<< ERROR!
> org.apache.camel.component.crypto.cms.exception.CryptoCmsException: Problem
> during generating the keystore
> Caused by: java.security.cert.CertificateParsingException:
> java.io.IOException: Unknown named curve: 1.3.132.0.37
> Caused by: java.io.IOException: Unknown named curve: 1.3.132.0.37
> [ERROR]
> orignatorUnprotectedAttributes(org.apache.camel.component.crypto.cms.ComponentTest)
> Time elapsed: 0.107 s <<< ERROR!
> org.apache.camel.component.crypto.cms.exception.CryptoCmsException: Problem
> during generating the keystore
> Caused by: java.security.cert.CertificateParsingException:
> java.io.IOException: Unknown named curve: 1.3.132.0.37
> Caused by: java.io.IOException: Unknown named curve: 1.3.132.0.37
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CAMEL-11325) Upgrade to Apache Spark 2.x
[ https://issues.apache.org/jira/browse/CAMEL-11325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11325: --- Assignee: Viral Gohel > Upgrade to Apache Spark 2.x > --- > > Key: CAMEL-11325 > URL: https://issues.apache.org/jira/browse/CAMEL-11325 > Project: Camel > Issue Type: Task > Components: camel-spark >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 2.23.0 > > > We currently are on 1.x, and there is a newer 2.x release out which we should > upgrade to. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12742) Upgrade maven wrapper to 0.4.2
[ https://issues.apache.org/jira/browse/CAMEL-12742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-12742: --- Assignee: Viral Gohel > Upgrade maven wrapper to 0.4.2 > -- > > Key: CAMEL-12742 > URL: https://issues.apache.org/jira/browse/CAMEL-12742 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 2.23.0 > > > We use 0.4.0 and there is a 0.4.2 release out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12587) camel-zipkin-starter fails mapping service names
[ https://issues.apache.org/jira/browse/CAMEL-12587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel resolved CAMEL-12587. - Resolution: Fixed > camel-zipkin-starter fails mapping service names > > > Key: CAMEL-12587 > URL: https://issues.apache.org/jira/browse/CAMEL-12587 > Project: Camel > Issue Type: Improvement > Components: camel-zipkin >Affects Versions: 2.22.0 >Reporter: Adrian Cole >Assignee: Viral Gohel >Priority: Major > Fix For: 2.22.1, 2.23.0 > > > camel-zipkin-starter uses mapped properties for service names. For example, > the following wildcard properties are used in camel-example-zipkin > camel.zipkin.server-service-mappings.*=service1 > camel.zipkin.client-service-mappings.*=service2 > > trunk is currently broken, as running the service1 part of the example ends > with errors like so unless you comment out the mappings: > > Caused by: org.springframework.core.convert.ConverterNotFoundException: No > converter found capable of converting from type [java.lang.String] to type > [java.util.Map] at > org.springframework.core.convert.support.GenericConversionService.handleConverterNotFound > (GenericConversionService.java:321) at > org.springframework.core.convert.support.GenericConversionService.convert > (GenericConversionService.java:194) at > org.springframework.boot.context.properties.bind.BindConverter$CompositeConversionService.convert > (BindConverter.java:162) at > org.springframework.boot.context.properties.bind.BindConverter.convert > (BindConverter.java:96) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12587) camel-zipkin-starter fails mapping service names
[ https://issues.apache.org/jira/browse/CAMEL-12587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-12587: --- Assignee: Viral Gohel > camel-zipkin-starter fails mapping service names > > > Key: CAMEL-12587 > URL: https://issues.apache.org/jira/browse/CAMEL-12587 > Project: Camel > Issue Type: Improvement > Components: camel-zipkin >Reporter: Adrian Cole >Assignee: Viral Gohel >Priority: Major > > camel-zipkin-starter uses mapped properties for service names. For example, > the following wildcard properties are used in camel-example-zipkin > camel.zipkin.server-service-mappings.*=service1 > camel.zipkin.client-service-mappings.*=service2 > > trunk is currently broken, as running the service1 part of the example ends > with errors like so unless you comment out the mappings: > > Caused by: org.springframework.core.convert.ConverterNotFoundException: No > converter found capable of converting from type [java.lang.String] to type > [java.util.Map] at > org.springframework.core.convert.support.GenericConversionService.handleConverterNotFound > (GenericConversionService.java:321) at > org.springframework.core.convert.support.GenericConversionService.convert > (GenericConversionService.java:194) at > org.springframework.boot.context.properties.bind.BindConverter$CompositeConversionService.convert > (BindConverter.java:162) at > org.springframework.boot.context.properties.bind.BindConverter.convert > (BindConverter.java:96) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-11954) Camel JMX name for cluster service
[ https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel updated CAMEL-11954: Attachment: CAMEL11954-Renamed-HA-packages-to-cluster.patch > Camel JMX name for cluster service > -- > > Key: CAMEL-11954 > URL: https://issues.apache.org/jira/browse/CAMEL-11954 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen >Assignee: Viral Gohel > Fix For: 2.21.0 > > Attachments: CAMEL11954-Renamed-HA-packages-to-cluster.patch > > > We use ha today, which is a bit too short and confusing. > Lets rename this to something better, like cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11954) Camel JMX name for cluster service
[ https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235460#comment-16235460 ] Viral Gohel commented on CAMEL-11954: - Hi Luca, Thanks for your suggestions. I actually already modified the packages to 'clusterservices'. And yes, i will work on the other components to refactor this. > Camel JMX name for cluster service > -- > > Key: CAMEL-11954 > URL: https://issues.apache.org/jira/browse/CAMEL-11954 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen >Assignee: Viral Gohel >Priority: Major > Fix For: 2.21.0 > > > We use ha today, which is a bit too short and confusing. > Lets rename this to something better, like cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11970) JacksonDataFormat does not pickup custom ObjectMapper from Registry
[
https://issues.apache.org/jira/browse/CAMEL-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16233821#comment-16233821
]
Viral Gohel commented on CAMEL-11970:
-
Hello Tim,
Thanks for reporting this. By any chance would you be able to provide us with a
reproducer application so that we can check ?
> JacksonDataFormat does not pickup custom ObjectMapper from Registry
> ---
>
> Key: CAMEL-11970
> URL: https://issues.apache.org/jira/browse/CAMEL-11970
> Project: Camel
> Issue Type: Bug
> Components: camel-jackson
>Affects Versions: 2.19.2, 2.19.3, 2.20.0
> Environment: Spring Boot 1.5.7.RELEASE
> org.apache.camel:*2.19.2
> A SpringRouteBuilder bean:
> {code:java}
> @Component
> public class CustomerCreatedRoutes extends SpringRouteBuilder
> {
> @Value("${spring.application.name}")
> private String groupId;
> private final Helper helper;
> @Autowired
> public CustomerCreatedRoutes(Helper helperParm)
> {
> helper = helperParm;
> }
> @Override
> public void configure() throws Exception
> {
> KafkaTopics.DomainEvent eventType =
> KafkaTopics.DomainEvent.CUSTOMER_CREATED;
> from(eventType.buildConsumerUri(groupId)) //
> .routeId(eventType.getDefaultRouteId()) //
> .unmarshal() //
> .json(JsonLibrary.Jackson, eventType.getPayloadClass()) //
> .id(eventType.getDefaultUnmarshalId()) //
> .bean(helper, "createDefaultPolicy") //
> .end();
> }
> }
> {code}
>Reporter: Tim Lark
>Priority: Major
> Fix For: 2.19.4, 2.20.1
>
>
> When a custom ObjectMapper is properly configured as a Spring bean and exists
> in the Registry, it is ignored when the {{JacksonDataFormat.doStart}} method
> is invoked.
> The beginning of this method does a null check on {{objectMapper}} and simply
> creates one via {{new ObjectMapper()}} if null.
> I've prototyped a more robust solution below, which does pickup our custom
> ObjectMapper bean:
> +Before:+
> {code:java}
> @Override
> protected void doStart() throws Exception {
> if (objectMapper == null) {
> objectMapper = new ObjectMapper();
> }
> ...
> {code}
> +After:+
> {code:java}
> @Override
> protected void doStart() throws Exception {
> if (objectMapper == null) {
> CamelContext context = getCamelContext();
> if (context == null) {
> LOG.error("doStart: No camelContext defined");
> }
> else {
> Map mappersByName = context
> .getRegistry()
> .findByTypeWithName(ObjectMapper.class);
> LOG.debug("doStart: Found objectMappers={}", mappersByName);
> if (mappersByName.size() >= 1) {
> Map.Entry mapperByName =
> mappersByName
> .entrySet()
> .iterator()
> .next();
> objectMapper = mapperByName.getValue();
> LOG.debug("doStart: Using objectMapper=[name:{}, {}]",
> mapperByName.getKey(), objectMapper);
> }
> }
> if (objectMapper == null) {
> objectMapper = new ObjectMapper();
> LOG.warn("doStart: Using new default objectMapper={}",
> objectMapper);
> }
> }
> ...
> {code}
> An enhancement to this would be to allow the *bean name* to be specified
> instead of simply choosing the first one found.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11954) Camel JMX name for cluster service
[ https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11954: --- Assignee: Viral Gohel > Camel JMX name for cluster service > -- > > Key: CAMEL-11954 > URL: https://issues.apache.org/jira/browse/CAMEL-11954 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen >Assignee: Viral Gohel > Fix For: 2.21.0 > > > We use ha today, which is a bit too short and confusing. > Lets rename this to something better, like cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11954) Camel JMX name for cluster service
[ https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225246#comment-16225246 ] Viral Gohel commented on CAMEL-11954: - I will take a look at this. Do we also rename the packages to say: org.apache.camel.ha to org.apache.camel.clusterservices and org.apache.camel.impl.ha to org.apache.camel.impl.clusterservices ? > Camel JMX name for cluster service > -- > > Key: CAMEL-11954 > URL: https://issues.apache.org/jira/browse/CAMEL-11954 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen > Fix For: 2.21.0 > > > We use ha today, which is a bit too short and confusing. > Lets rename this to something better, like cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11951) Uri matching does not match request type
[
https://issues.apache.org/jira/browse/CAMEL-11951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225174#comment-16225174
]
Viral Gohel commented on CAMEL-11951:
-
Hi Robert,
Your attached reproducer is missing, mandatory 'location' attribute in
in your route file. Can you make the changes and upload
the reproducer so that we can check ? Which is the property file you are
referring in the reproducer ?
{code:java}
{code}
> Uri matching does not match request type
>
>
> Key: CAMEL-11951
> URL: https://issues.apache.org/jira/browse/CAMEL-11951
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common
>Affects Versions: 2.20.0
> Environment: camel-spring, camel-jetty
> OS - RHEL
>Reporter: Robert Hillier
> Attachments: camel-bug-demo.zip
>
>
> I had previously described the problem here:
> https://stackoverflow.com/questions/46936348/apache-camel-rest-dsl-405-method-not-allowed
> It appears that the problem is down to a possible bug in the way URIs are
> matched (not to mention my rather obscure use-case)
> I have a number of REST-DSL endpoints with the same URI but different request
> types (POST, PUT, GET, DELETE). In my case, the URI is getting selected by
> HttpServletResolveConsumerStrategy.resolve (in addition to these, I have some
> specific endpoints with wildcards in them)
> This method matches the URI, but not the request type. When I send a GET
> request, it returns the first consumer candidate it finds which, in my case,
> always seems to be PUT. Later, when CamelContinuationServlet.doService
> checks that the request type and cadidate type match, they don't. It then
> returns 405 Method Not Allowed.
> I believe that the HttpServletResolveConsumerStrategy.resolve method IN
> camel-hhtp-common should check the request type as well as the URI.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11780) camel-amqp - SSL Transport configuration
[ https://issues.apache.org/jira/browse/CAMEL-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11780: --- Assignee: Viral Gohel > camel-amqp - SSL Transport configuration > > > Key: CAMEL-11780 > URL: https://issues.apache.org/jira/browse/CAMEL-11780 > Project: Camel > Issue Type: Improvement > Components: camel-amqp >Affects Versions: 2.19.2 >Reporter: Cyril EDME >Assignee: Viral Gohel > Fix For: 2.21.0 > > > Hi, > i'm using camel and specially the amqp component to consume a topic. > Everything is working well but I'm confused regarding the SSL configuration. > It's not clear in the documentation, I don't want to use the default JVM > certificate storage so I tried to configure the connection factory with the > [qpid > documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options] > but the qpid-jms-client version used by amqp component (0.11.1) doesn't > handle the amqps schema URI. > There is another way to configure the SSL transport like the key store > location and password without a qpid upgrade ? > Thanks ! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11878) BlueprintCamelContext should use Filter for serviceevents
[
https://issues.apache.org/jira/browse/CAMEL-11878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viral Gohel updated CAMEL-11878:
Description:
Currently BlueprintCamelContext registers for all ServcieEvents in fact it is
only interrested in a very specific event type
(objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
Beside geting and testing more vents as neccesary, since it also logs each
event received if enabled Debug logging ALL Osgi-Service events are logged
(which might be much in a larger OSGi-App) making reading the logs really hard.
was:
{color:red}colored text{color}Currently BlueprintCamelContext registers for all
ServcieEvents in fact it is only interrested in a very specific event type
(objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
Beside geting and testing more vents as neccesary, since it also logs each
event received if enabled Debug logging ALL Osgi-Service events are logged
(which might be much in a larger OSGi-App) making reading the logs really hard.
> BlueprintCamelContext should use Filter for serviceevents
> -
>
> Key: CAMEL-11878
> URL: https://issues.apache.org/jira/browse/CAMEL-11878
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
>Reporter: Christoph Läubrich
>Priority: Minor
>
> Currently BlueprintCamelContext registers for all ServcieEvents in fact it is
> only interrested in a very specific event type
> (objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
> Beside geting and testing more vents as neccesary, since it also logs each
> event received if enabled Debug logging ALL Osgi-Service events are logged
> (which might be much in a larger OSGi-App) making reading the logs really
> hard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11878) BlueprintCamelContext should use Filter for serviceevents
[
https://issues.apache.org/jira/browse/CAMEL-11878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viral Gohel updated CAMEL-11878:
Description:
{color:red}colored text{color}Currently BlueprintCamelContext registers for all
ServcieEvents in fact it is only interrested in a very specific event type
(objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
Beside geting and testing more vents as neccesary, since it also logs each
event received if enabled Debug logging ALL Osgi-Service events are logged
(which might be much in a larger OSGi-App) making reading the logs really hard.
was:
Currently BlueprintCamelContext registers for all ServcieEvents in fact it is
only interrested in a very specific event type
(objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
Beside geting and testing more vents as neccesary, since it also logs each
event received if enabled Debug logging ALL Osgi-Service events are logged
(which might be much in a larger OSGi-App) making reading the logs really hard.
> BlueprintCamelContext should use Filter for serviceevents
> -
>
> Key: CAMEL-11878
> URL: https://issues.apache.org/jira/browse/CAMEL-11878
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
>Reporter: Christoph Läubrich
>Priority: Minor
>
> {color:red}colored text{color}Currently BlueprintCamelContext registers for
> all ServcieEvents in fact it is only interrested in a very specific event
> type (objectClass=org.osgi.service.blueprint.container.BlueprintContainer)
> Beside geting and testing more vents as neccesary, since it also logs each
> event received if enabled Debug logging ALL Osgi-Service events are logged
> (which might be much in a larger OSGi-App) making reading the logs really
> hard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11891) XML2JSON Data Format and empty requests
[
https://issues.apache.org/jira/browse/CAMEL-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198992#comment-16198992
]
Viral Gohel commented on CAMEL-11891:
-
Hi,
Would you be able to attach a test case reproducer for this ?
> XML2JSON Data Format and empty requests
> ---
>
> Key: CAMEL-11891
> URL: https://issues.apache.org/jira/browse/CAMEL-11891
> Project: Camel
> Issue Type: Improvement
> Components: camel-xmljson
>Affects Versions: 2.19.3
>Reporter: Richard Groote
>
> It would be nice if the XmlJsonDataFormat can handle empty body.
> In our project we upgraded from 2.14.0 to 2.19.3.
> The below code no longer works in 2.19.3 when a GET request is made to a
> servlet component. In our situation the body contains a stream cache and the
> xml2json will fail.
> A possible solution is to check the http method before doing the
> unmarshalling.
>
>
> ${body} != null
>
>
>
> The current solution in our project is a extension of the XmlJsonDataFormat.
> In the extension the method unmarshall is overriden
> {code:java}
> @Override
> public Object unmarshal(Exchange exchange, InputStream stream) throws
> Exception {
> Object inBody = exchange.getIn().getBody();
>
> if(inBody == null) {
> return null;
> }
>
> if(inBody instanceof StreamCache) {
> long length = ((StreamCache) inBody).length();
> if(length <= 0) {
> return null;
> }
> } else {
> if(!(inBody instanceof JSON)) {
> String jsonString =
> exchange.getContext().getTypeConverter().convertTo(String.class, exchange,
> inBody);
> if(StringUtils.isEmpty(jsonString)) {
> return null;
> }
> }
> }
>
>
>
> return super.unmarshal(exchange, stream);
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11860) camel-oling4 - Upgrade to olingo 4.4
[ https://issues.apache.org/jira/browse/CAMEL-11860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11860: --- Assignee: Viral Gohel > camel-oling4 - Upgrade to olingo 4.4 > > > Key: CAMEL-11860 > URL: https://issues.apache.org/jira/browse/CAMEL-11860 > Project: Camel > Issue Type: Improvement > Components: camel-olingo4 >Reporter: Claus Ibsen >Assignee: Viral Gohel > Fix For: 2.21.0 > > > There is a slight API change that causes a parser method to require a base > path as well, which isn't obvious what to provide -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11616) Zookeeper : upgrade to curator 4.0
[ https://issues.apache.org/jira/browse/CAMEL-11616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11616: --- Assignee: Viral Gohel > Zookeeper : upgrade to curator 4.0 > -- > > Key: CAMEL-11616 > URL: https://issues.apache.org/jira/browse/CAMEL-11616 > Project: Camel > Issue Type: Task > Components: camel-zookeeper >Reporter: Luca Burgazzoli >Assignee: Viral Gohel >Priority: Minor > Fix For: Future > > > Curator 4.0.0 is out and should support both ZooKeeper 3.4 and 3.5 > http://curator.apache.org/zk-compatibility.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11879) Upgrade to lucene 7
[ https://issues.apache.org/jira/browse/CAMEL-11879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11879: --- Assignee: Viral Gohel > Upgrade to lucene 7 > --- > > Key: CAMEL-11879 > URL: https://issues.apache.org/jira/browse/CAMEL-11879 > Project: Camel > Issue Type: Improvement > Components: camel-lucene >Reporter: Claus Ibsen >Assignee: Viral Gohel > Fix For: 2.21.0 > > > We should upgrade lucene and solr to newer versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11751) Dropbox Component - Update to APIv2
[ https://issues.apache.org/jira/browse/CAMEL-11751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel reassigned CAMEL-11751: --- Assignee: Viral Gohel > Dropbox Component - Update to APIv2 > --- > > Key: CAMEL-11751 > URL: https://issues.apache.org/jira/browse/CAMEL-11751 > Project: Camel > Issue Type: Task > Components: camel-dropbox >Affects Versions: 2.19.2 >Reporter: Giovanni Marigi >Assignee: Viral Gohel > Fix For: 2.21.0 > > > According to this > https://blogs.dropbox.com/developers/2017/06/updated-api-v1-deprecation-timeline > Dropbox will no longer support APIv1 endpoints. > Camel component is based on SDK 1.x and must be updated to use APIv2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11879) Upgrade to lucene 7
[ https://issues.apache.org/jira/browse/CAMEL-11879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189721#comment-16189721 ] Viral Gohel commented on CAMEL-11879: - Working on this... > Upgrade to lucene 7 > --- > > Key: CAMEL-11879 > URL: https://issues.apache.org/jira/browse/CAMEL-11879 > Project: Camel > Issue Type: Improvement > Components: camel-lucene >Reporter: Claus Ibsen > Fix For: 2.21.0 > > > We should upgrade lucene and solr to newer versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CAMEL-11879) Upgrade to lucene 7
[ https://issues.apache.org/jira/browse/CAMEL-11879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189721#comment-16189721 ] Viral Gohel edited comment on CAMEL-11879 at 10/3/17 1:41 PM: -- Working on this... I will submit a PR soon. was (Author: vrlgohel): Working on this... > Upgrade to lucene 7 > --- > > Key: CAMEL-11879 > URL: https://issues.apache.org/jira/browse/CAMEL-11879 > Project: Camel > Issue Type: Improvement > Components: camel-lucene >Reporter: Claus Ibsen > Fix For: 2.21.0 > > > We should upgrade lucene and solr to newer versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE
[ https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189550#comment-16189550 ] Viral Gohel commented on CAMEL-11846: - Hi Robert, Do you have any example or a reproducer application test case, by which you test this ? Since the changes would not involve a single file fix, it would be more helpful if you can attach a reproducer on how you are seeing the results. > xtokenize and apply xslt to a string does not work with UTF-16BE > - > > Key: CAMEL-11846 > URL: https://issues.apache.org/jira/browse/CAMEL-11846 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.17.5 >Reporter: Robert Half > > In XML, encoding is often provided inside tag. In general, you > cannot read the tag, if you don't know the encoding, but XML Parsers support > the detection of several encodings which allows them to read the tag. With > that information they can read the whole file without knowing the "charset" > in first place. > xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by > providing a reader Camel tells, that it knows the encoding, so it won't be > detected by the XML parser. > Also Camel sets the charset to UTF-8 if it is not provided inside a header. > This makes the underlying reader fail reading UTF-16. > Using XmlInputFactory#createXmlStreamReader(InputStream) inside > XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps > fails again because it again uses a Reader. > See Stackoverflow Question for reference: > [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11876) OsgiCamelContextPublisher might leak Service-References
[
https://issues.apache.org/jira/browse/CAMEL-11876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189492#comment-16189492
]
Viral Gohel commented on CAMEL-11876:
-
Hi,
Thanks for reporting this. Do you have an application reproducer to test this ?
or how are you observing this? Can you attach a snapshot of the memory leak
suspects you have identified and attached it to the ticket ?
> OsgiCamelContextPublisher might leak Service-References
> ---
>
> Key: CAMEL-11876
> URL: https://issues.apache.org/jira/browse/CAMEL-11876
> Project: Camel
> Issue Type: Bug
> Components: osgi
>Reporter: Christoph Läubrich
>
> OsgiCamelContextPublisher holds a Map of Service-References in its doShutdown
> method this map is cleared.
> This could lead to problem when there are still items in the map.
> Instead of clearing the map, it should be iterate+remove
> {code:java}
> Iterator> it = registrations.values().iterator();
> while (it.hasNext()) {
> it.next().unregister();
> it.remove();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11771) Remove commons-logging import
[
https://issues.apache.org/jira/browse/CAMEL-11771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162486#comment-16162486
]
Viral Gohel commented on CAMEL-11771:
-
Working on this..
> Remove commons-logging import
> -
>
> Key: CAMEL-11771
> URL: https://issues.apache.org/jira/browse/CAMEL-11771
> Project: Camel
> Issue Type: Test
>Reporter: Claus Ibsen
> Fix For: 2.20.0
>
>
> We should use slf4j-api instead as there is a few unit test that uses
> commons-logging api directly.
> {code}
> davsclaus:/Users/davsclaus/workspace/camel (boot2)/$ git grep
> "commons\.logging"
> components/camel-cxf/src/test/java/org/apache/camel/component/cxf/mtom/MtomTestHelper.java:
> static boolean isAwtHeadless(org.apache.commons.logging.Log log,
> org.slf4j.Logger logger) {
> components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/SpringHttpsRouteTest.java:import
> org.apache.commons.logging.Log;
> components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/SpringHttpsRouteTest.java:import
> org.apache.commons.logging.LogFactory;
> components/camel-zookeeper-master/src/test/java/org/apache/camel/component/zookeepermaster/CuratorFactoryBean.java:import
> org.apache.commons.logging.Log;
> components/camel-zookeeper-master/src/test/java/org/apache/camel/component/zookeepermaster/CuratorFactoryBean.java:import
> org.apache.commons.logging.LogFactory;
> components/camel-zookeeper/src/test/java/org/apache/camel/component/zookeeper/policy/FailoverCuratorLeaderRoutePolicyTest.java:import
> org.apache.commons.logging.LogFactory;
> components/camel-zookeeper/src/test/java/org/apache/camel/component/zookeeper/policy/FailoverRoutePolicyTest.java:import
> org.apache.commons.logging.LogFactory;
> components/camel-zookeeper/src/test/java/org/apache/camel/component/zookeeper/policy/MultiMasterCuratorLeaderRoutePolicyTest.java:import
> org.apache.commons.logging.LogFactory;
> parent/pom.xml: org.apache.commons.logging.*;version="[1.1,2)",
> tests/camel-itest-karaf/src/test/resources/commons-logging.properties:#org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
> tests/camel-itest-karaf/src/test/resources/commons-logging.properties:org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
> tests/camel-itest/src/test/resources/commons-logging.properties:#org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
> tests/camel-itest/src/test/resources/commons-logging.properties:org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11757) Upgrade CometD library
Viral Gohel created CAMEL-11757: --- Summary: Upgrade CometD library Key: CAMEL-11757 URL: https://issues.apache.org/jira/browse/CAMEL-11757 Project: Camel Issue Type: Task Components: camel-cometd, camel-salesforce Affects Versions: 2.20.0 Reporter: Viral Gohel Priority: Minor We can look to upgrade the CometD library version to the latest version available. There is a Salesforce 18 release around the corner, https://help.salesforce.com/articleView?id=000265558&language=en_US&type=1. Hence, if users may want to connect to the latest SF release, then we may want to upgrade this lib to make sure the new features of Streaming API's can be covered. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11757) Upgrade CometD library
[ https://issues.apache.org/jira/browse/CAMEL-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viral Gohel updated CAMEL-11757: Fix Version/s: 2.20.0 > Upgrade CometD library > -- > > Key: CAMEL-11757 > URL: https://issues.apache.org/jira/browse/CAMEL-11757 > Project: Camel > Issue Type: Task > Components: camel-cometd, camel-salesforce >Affects Versions: 2.20.0 >Reporter: Viral Gohel >Priority: Minor > Fix For: 2.20.0 > > > We can look to upgrade the CometD library version to the latest version > available. > There is a Salesforce 18 release around the corner, > https://help.salesforce.com/articleView?id=000265558&language=en_US&type=1. > Hence, if users may want to connect to the latest SF release, then we may > want to upgrade this lib to make sure the new features of Streaming API's can > be covered. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11616) Zookeeper : upgrade to curator 4.0
[ https://issues.apache.org/jira/browse/CAMEL-11616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114194#comment-16114194 ] Viral Gohel commented on CAMEL-11616: - Apache Curator 4.0.0 seems to be having a hard dependency on Zookeeper version 3.5.3, https://github.com/apache/curator/blob/4194c07aa72c2c05f1c11cabc1af25e0c5c3fedd/pom.xml#L62. Zookeeper version 3.5.3 Beta is available here, https://blog.cloudera.com/blog/2017/05/apache-zookeeper-3-5-3-beta-has-been-released/. As Zk 3.5.x is a Beta release, and the GA version of Zk is not released yet, I will look at this issue when Zk GA 3.5.3 is released. > Zookeeper : upgrade to curator 4.0 > -- > > Key: CAMEL-11616 > URL: https://issues.apache.org/jira/browse/CAMEL-11616 > Project: Camel > Issue Type: Task > Components: camel-zookeeper >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: Future > > > Curator 4.0.0 is out and should support both ZooKeeper 3.4 and 3.5 > http://curator.apache.org/zk-compatibility.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
