[jira] [Commented] (CAMEL-9182) camel-kafka : Kafka Endpoint executor threadpool is not initialized based on consumercount
[
https://issues.apache.org/jira/browse/CAMEL-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934715#comment-14934715
]
yogananth mahalingam commented on CAMEL-9182:
-
Hi [~davsclaus] -
Correct me if I am wrong. My interpretation of the below code snippet in
KafkaConsumer is,
* ConsumerCount - create multiple connections & consume messages as if there
are multiple endpoints configured.
* consumerSteams - Determines the number of KafkaStreams retrieved by each
KafkaConnection
Number of ConsumerTasks getting created matches consumerCount.
And I expected Executor Threadpool to be initialized based on number of
consumerCounts.
{code}
@Override
protected void doStart() throws Exception {
super.doStart();
log.info("Starting Kafka consumer");
executor = endpoint.createExecutor();
for (int i = 0; i < endpoint.getConsumersCount(); i++) {
ConsumerConnector consumer =
kafka.consumer.Consumer.createJavaConsumerConnector(new
ConsumerConfig(getProps()));
Map topicCountMap = new HashMap();
topicCountMap.put(endpoint.getTopic(),
endpoint.getConsumerStreams());
Map>> consumerMap =
consumer.createMessageStreams(topicCountMap);
List> streams =
consumerMap.get(endpoint.getTopic());
// commit periodically
if (endpoint.isAutoCommitEnable() != null &&
!endpoint.isAutoCommitEnable()) {
if ((endpoint.getConsumerTimeoutMs() == null ||
endpoint.getConsumerTimeoutMs() < 0)
&& endpoint.getConsumerStreams() > 1) {
LOG.warn("consumerTimeoutMs is set to -1 (infinite) while
requested multiple consumer streams.");
}
CyclicBarrier barrier = new
CyclicBarrier(endpoint.getConsumerStreams(), new CommitOffsetTask(consumer));
for (final KafkaStream stream : streams) {
executor.submit(new BatchingConsumerTask(stream, barrier));
}
consumerBarriers.put(consumer, barrier);
} else {
// auto commit
for (final KafkaStream stream : streams) {
executor.submit(new AutoCommitConsumerTask(consumer,
stream));
}
consumerBarriers.put(consumer, null);
}
}
}
{code}
> camel-kafka : Kafka Endpoint executor threadpool is not initialized based on
> consumercount
> --
>
> Key: CAMEL-9182
> URL: https://issues.apache.org/jira/browse/CAMEL-9182
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.0
>Reporter: yogananth mahalingam
>Assignee: Claus Ibsen
>
> Kafka Endpoint's Executor threadpool is expected to be created based on
> consumer count.
> This would have enabled multiple consumers to be running concurrently.
> Instead it is initialized based on ConsumerStreams.
> With a configuration of consumer count = 10, consumer stream = 1, the
> messages are getting consumed sequentially.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9060) Load balancing http endpoints with camel and jetty9 fails to correctly bridge different endpoints (case here: first host is down)
[ https://issues.apache.org/jira/browse/CAMEL-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9060: --- Affects Version/s: (was: 2.16.0) > Load balancing http endpoints with camel and jetty9 fails to correctly bridge > different endpoints (case here: first host is down) > - > > Key: CAMEL-9060 > URL: https://issues.apache.org/jira/browse/CAMEL-9060 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.15.2 > Environment: OS X, java 1.8.0_45-b14 >Reporter: Ioannis Alexandrakis > Attachments: jetty-lb-test.zip > > > While trying to upgrade an existing http loadbalancer (failover scenario in > my case) from camel 2.14.x to 2.15.x (I tried in karaf4, so jetty9 was the > most sensible option instead of 8), I stumbled upon unexpected behavior. > I realized that, while it was working correctly when both nodes where up and > serving requests, when the first node was not available (and should > transparently failover to the second one), I was i) getting the request as > response, then ii) a consequent request was going to the second server and > there was a mix of responses. On my development environment I was frequently > getting "IllegalStateException: AsyncContext completed" between the requests, > too. The problem was intermittent and I was randomly getting the correct > response (every 2 or 3 requests) > If jetty 8 is used, everything is OK. The problem appears with camel-jetty9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9177) combination of JPA-Component, loop and wiretap throws entitymanger cloesd exception
[
https://issues.apache.org/jira/browse/CAMEL-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9177.
Resolution: Fixed
Fix Version/s: 2.15.4
Thanks for reporting and the suggestion.
> combination of JPA-Component, loop and wiretap throws entitymanger cloesd
> exception
> ---
>
> Key: CAMEL-9177
> URL: https://issues.apache.org/jira/browse/CAMEL-9177
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-jpa
>Affects Versions: 2.15.2, 2.15.3
> Environment: Camel 2.15.2 with Spring-Boot 1.2.3.RELEASE (with camel
> xml dsl)
>Reporter: Pascal S.
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.0, 2.15.4
>
>
> Hi,
> I have found a problem regarding a wiretap and the camel-jpa component. I
> have a route with an async split through a wiretap. In each route, I use a
> jpa producer to persist an entity. The problem is, that the entitymanager was
> closed before the async routes can reach the end. The cause is, that the same
> entitymanager is used in the async routes. The main route reaches the end and
> closes the entitymanager.
> E.g. like the following route:
> {code}
>
> ...
>
> ...
>
> ...
>
>
>
>
>
> ...
>
> ...
>
> {code}
> I think a possible fix can be to check that the entitymanager is null or
> closed. If null or closed, create a new entitymanager.
> {code}
> public final class JpaHelper {
> ...
> public static EntityManager getTargetEntityManager(Exchange exchange, ...
> ...
> if (em == null || !em.isOpen()) {
> // create a new entity manager
> em = entityManagerFactory.createEntityManager();
> ...
> }
> }
> ...
> }
> {code}
> Another solution can be in the wiretap. There where the exchange is copied,
> the "CamelEntityManager" property could be removed.
> Currently, my quickfix is: At the beginning of the async route I remove the
> entitymanager from the exchange.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8853) CXF endpoint with a relative address cannot be invoked by a producer template
[
https://issues.apache.org/jira/browse/CAMEL-8853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8853:
---
Priority: Minor (was: Major)
> CXF endpoint with a relative address cannot be invoked by a producer template
> -
>
> Key: CAMEL-8853
> URL: https://issues.apache.org/jira/browse/CAMEL-8853
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.15.2
>Reporter: Tomas Rohovsky
>Priority: Minor
> Fix For: Future
>
> Attachments: cxf-producer-template.zip
>
>
> If you invoke this Camel CXF endpoint by a producer template:
> {code}
> serviceClass="org.example.cxf_producer_template.GreetingService"/>
> {code}
> you will get:
> {code}
> org.apache.camel.CamelExecutionException: Exception occurred during execution
> on the exchange: Exchange[Message: Tom]
> at
> org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1635)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:645)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:471)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:133)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:149)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:301)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:331)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.example.cxf_producer_template.ProducerProcessor.process(ProducerProcessor.java:12)[265:cxf-producer-template:0.0.1.SNAPSHOT]
> at
> org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:103)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:129)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:165)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:73)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_71]
> at java.util.TimerThread.run(Timer.java:505)[:1.7.0_71]
> Caused by: java.lang.IllegalArgumentException: URI is not absolute
> at java.net.URI.toURL(URI.java:1095)[:1.7.0_71]
> at
> org.apache.cxf.transport.http.Address.getURL(Address.java:45)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit.createConnection(URLConnectionHTTPConduit.java:93)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit.setupConnection(URLConnectionHTTPConduit.java:105)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
>
[jira] [Commented] (CAMEL-8830) Upgrade to Saxon HE 9.6
[ https://issues.apache.org/jira/browse/CAMEL-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934765#comment-14934765 ] Claus Ibsen commented on CAMEL-8830: I think they changed some apis in that release onwards that causes trouble for the error listeners. > Upgrade to Saxon HE 9.6 > --- > > Key: CAMEL-8830 > URL: https://issues.apache.org/jira/browse/CAMEL-8830 > Project: Camel > Issue Type: Improvement > Components: camel-saxon >Affects Versions: 2.15.2 >Reporter: Kartik > Fix For: Future > > > Upgrade to Saxon HE 9.6 which uses XQuery 3.0 by default, allowing to use > powerful new XQuery 3.0 features such as 'group by' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8838) Setting HttpConnectionManager Override Property in URI using HttpClientParams is not working
[ https://issues.apache.org/jira/browse/CAMEL-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8838: --- Assignee: (was: Willem Jiang) > Setting HttpConnectionManager Override Property in URI using HttpClientParams > is not working > > > Key: CAMEL-8838 > URL: https://issues.apache.org/jira/browse/CAMEL-8838 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 2.13.4, 2.15.0, 2.15.2 >Reporter: Deepak > Labels: camel, http > > Hi, > When we pass HttpClientParams in EndPoint URI, to override > HttpConnectionManager class, the HttpComponent is not considering the > overridden parameter, > Example URL > https://myapplication.com/myappservice/?bridgeEndpoint=true=false=org.apache.commons.httpclient.SimpleHttpConnectionManager > > In org.apache.camel.component.http.HttpComponent, if there is no bean > injection of httpConnectionManager class, by default a new instance of > MultiThreadedHttpConnectionManager class is created. > In HttpComponent class, while constructing the HttpEndPoint, the same above > HttpConnection Manager class is sent as reference. > In HttpEndPoint class, createHttpClient method, although all the Http client > params are considered, HttpConnectionManager class sent by the HttpClient > Params is not considered. > Please clarify or fix it. > HttpClient answer = new HttpClient(getClientParams()); // Line Number 110 > answer.setHttpConnectionManager(httpConnectionManager); // Line Number 144 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8830) Upgrade to Saxon HE 9.6
[ https://issues.apache.org/jira/browse/CAMEL-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8830: --- Fix Version/s: Future > Upgrade to Saxon HE 9.6 > --- > > Key: CAMEL-8830 > URL: https://issues.apache.org/jira/browse/CAMEL-8830 > Project: Camel > Issue Type: Improvement > Components: camel-saxon >Affects Versions: 2.15.2 >Reporter: Kartik > Fix For: Future > > > Upgrade to Saxon HE 9.6 which uses XQuery 3.0 by default, allowing to use > powerful new XQuery 3.0 features such as 'group by' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8420) Not possible to use inner classes for Dtos in Camel Swagger
[
https://issues.apache.org/jira/browse/CAMEL-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8420.
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 2.16.0
> Not possible to use inner classes for Dtos in Camel Swagger
> ---
>
> Key: CAMEL-8420
> URL: https://issues.apache.org/jira/browse/CAMEL-8420
> Project: Camel
> Issue Type: Improvement
> Components: camel-swagger
>Affects Versions: 2.14.1
>Reporter: Espen Tjonneland
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.0
>
>
> If you inline your Dto classes with your services then Camel fails to load
> them (ClassNotFoundException).
> Can easily be reproduced by modifying the Camel :: Example :: Serlet REST
> example by moving the User class into the UserService and update the
> UserRoute builder to use the moved type.
> {code:title=UserService.java|borderStyle=solid}
> public class UserService {
> // use a tree map so they become sorted
> private final Map
> users = new TreeMap();
> private Random ran = new Random();
> public UserService() {
> users.put("123", new
> org.apache.camel.example.rest.UserService.User(123, "John Doe"));
> users.put("456", new
> org.apache.camel.example.rest.UserService.User(456, "Donald Duck"));
> users.put("789", new
> org.apache.camel.example.rest.UserService.User(789, "Slow Turtle"));
> }
> /**
> * Gets a user by the given id
> *
> * @param id the id of the user
> * @return the user, or null if no user exists
> */
> public org.apache.camel.example.rest.UserService.User getUser(String id) {
>
> }
> /**
> * List all users
> *
> * @return the list of all users
> */
> public Collection
> listUsers() {
>
> }
> /**
> * Updates or creates the given user
> *
> * @param user the user
> */
> public void updateUser(org.apache.camel.example.rest.UserService.User
> user) {
>
> }
> public static class User {
> private int id;
> private String name;
>
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-9182) camel-kafka : Kafka Endpoint executor threadpool is not initialized based on consumercount
[
https://issues.apache.org/jira/browse/CAMEL-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yogananth mahalingam updated CAMEL-9182:
Comment: was deleted
(was: Hi [~davsclaus] -
Correct me if I am wrong. My interpretation of the below code snippet in
KafkaConsumer is,
* ConsumerCount - create multiple connections & consume messages as if there
are multiple endpoints configured.
* consumerSteams - Determines the number of KafkaStreams retrieved by each
KafkaConnection
Number of ConsumerTasks getting created matches consumerCount.
And I expected Executor Threadpool to be initialized based on number of
consumerCounts.
{code}
@Override
protected void doStart() throws Exception {
super.doStart();
log.info("Starting Kafka consumer");
executor = endpoint.createExecutor();
for (int i = 0; i < endpoint.getConsumersCount(); i++) {
ConsumerConnector consumer =
kafka.consumer.Consumer.createJavaConsumerConnector(new
ConsumerConfig(getProps()));
Map topicCountMap = new HashMap();
topicCountMap.put(endpoint.getTopic(),
endpoint.getConsumerStreams());
Map>> consumerMap =
consumer.createMessageStreams(topicCountMap);
List> streams =
consumerMap.get(endpoint.getTopic());
// commit periodically
if (endpoint.isAutoCommitEnable() != null &&
!endpoint.isAutoCommitEnable()) {
if ((endpoint.getConsumerTimeoutMs() == null ||
endpoint.getConsumerTimeoutMs() < 0)
&& endpoint.getConsumerStreams() > 1) {
LOG.warn("consumerTimeoutMs is set to -1 (infinite) while
requested multiple consumer streams.");
}
CyclicBarrier barrier = new
CyclicBarrier(endpoint.getConsumerStreams(), new CommitOffsetTask(consumer));
for (final KafkaStream stream : streams) {
executor.submit(new BatchingConsumerTask(stream, barrier));
}
consumerBarriers.put(consumer, barrier);
} else {
// auto commit
for (final KafkaStream stream : streams) {
executor.submit(new AutoCommitConsumerTask(consumer,
stream));
}
consumerBarriers.put(consumer, null);
}
}
}
{code})
> camel-kafka : Kafka Endpoint executor threadpool is not initialized based on
> consumercount
> --
>
> Key: CAMEL-9182
> URL: https://issues.apache.org/jira/browse/CAMEL-9182
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.0
>Reporter: yogananth mahalingam
>Assignee: Claus Ibsen
>
> Kafka Endpoint's Executor threadpool is expected to be created based on
> consumer count.
> This would have enabled multiple consumers to be running concurrently.
> Instead it is initialized based on ConsumerStreams.
> With a configuration of consumer count = 10, consumer stream = 1, the
> messages are getting consumed sequentially.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8604) [RabbitMQ] Allow Remote procedure call (RPC) in camel-rabbitmq
[
https://issues.apache.org/jira/browse/CAMEL-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8604.
Resolution: Won't Fix
We do not want to endorse RPC over messaging
> [RabbitMQ] Allow Remote procedure call (RPC) in camel-rabbitmq
> --
>
> Key: CAMEL-8604
> URL: https://issues.apache.org/jira/browse/CAMEL-8604
> Project: Camel
> Issue Type: Wish
> Components: camel-rabbitmq
>Affects Versions: 2.15.1
>Reporter: Ramon Rosa da Silva
>Priority: Minor
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> I would like RabbitMQ component knew how to handle messages in RPC format
> more easily.
> RabbitMQ RPC Sample: https://www.rabbitmq.com/tutorials/tutorial-six-java.html
> Currently, to receive and reply in RPC is required (as server):
> {code:title=RouteSample.java|borderStyle=solid}
> from("rabbitmq://rabbit-server:5672/myExc?routingKey=myQueue=myQueue=myVhost=false=true=10=10=true")
> .transacted ()
> .setProperty (RabbitMQConstants.REPLY_TO) .header (RabbitMQConstants.REPLY_TO)
> .to ("sql: ..")
> .setHeader (RabbitMQConstants.ROUTING_KEY) .property
> (RabbitMQConstants.REPLY_TO)
> .setHeader (RabbitMQConstants.EXCHANGE_NAME) .simple ("")
> .to("rabbitmq://rabbit-server:5672/_required_fake_field?routingKey=_required_fake_field=myVhost=1");
> {code}
> So you must save "reply_to" from header to properties, set fake exchange and
> routing key, and overwrite with setHeader.
> Would be simpler:
> - The consumer save the reply_to in properties.
> - Enable exchange and routing key blank.
> - Use reply_to property as routhing key when exchange and key is blank.
> Test unit for improvement:
> {code:title=ProducerTest.java|borderStyle=solid}
> private RabbitMQEndpoint endpoint = Mockito.mock(RabbitMQEndpoint.class);
> private Exchange exchange = Mockito.mock(Exchange.class);
> private Message message = new DefaultMessage();
> private Connection conn = Mockito.mock(Connection.class);
> private Channel channel = Mockito.mock(Channel.class);;
> @Before
> public void before() throws IOException {
> Mockito.when(exchange.getIn()).thenReturn(message);
>
> Mockito.when(endpoint.connect(Matchers.any(ExecutorService.class))).thenReturn(conn);
> Mockito.when(conn.createChannel()).thenReturn(null);
> }
>@Test
>public void testRpcReplyTo() throws Exception {
> message = Mockito.mock(Message.class);
> Mockito.when(exchange.getIn()).thenReturn(message);
> Mockito.when(message.getHeader(RabbitMQConstants.EXCHANGE_NAME,
> String.class)).thenReturn("");
>
> Mockito.when(conn.createChannel()).thenReturn(channel);
> RabbitMQProducer producer = new RabbitMQProducer(endpoint);
> exchange.setFromEndpoint(endpoint);
> exchange.setProperty(RabbitMQConstants.REPLY_TO,
> "queue_to_reply");
>
> producer.process(exchange);
>
> Mockito.verify(channel).basicPublish(Mockito.eq(""),
> Mockito.eq("queue_to_reply"), Mockito.any(BasicProperties.class),
> Mockito.any(byte[].class));
>}
>{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9083) Investigate camel-hazelcast feature failure when installed with other bundles
[
https://issues.apache.org/jira/browse/CAMEL-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934700#comment-14934700
]
Claus Ibsen commented on CAMEL-9083:
Fails with karaf 2.4.3
{code}
davsclaus:/opt/apache-karaf-2.4.3/$ bin/karaf
__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (2.4.3)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'osgi:shutdown' or 'logout' to shutdown Karaf.
karaf@root> features:chooseurl camel 2.16-SNAPSHOT
Adding feature url
mvn:org.apache.camel.karaf/apache-camel/2.16-SNAPSHOT/xml/features
karaf@root> features:install camel-aws
karaf@root> features:install camel-groovy
karaf@root> features:install camel-hazelcast
Error executing command: Can't install feature camel-hazelcast/0.0.0:
Could not start bundle mvn:com.hazelcast/hazelcast/3.5.2 in feature(s)
camel-hazelcast-2.16-SNAPSHOT, camel-vertx-2.16-SNAPSHOT: Activator start error
in bundle com.hazelcast [79].
karaf@root>
{code}
> Investigate camel-hazelcast feature failure when installed with other bundles
> -
>
> Key: CAMEL-9083
> URL: https://issues.apache.org/jira/browse/CAMEL-9083
> Project: Camel
> Issue Type: Task
> Components: camel-osgi
>Affects Versions: 2.16.0
>Reporter: Raúl Kripalani
>
> {code}
> karaf@root> features:install camel-aws
> karaf@root> features:install camel-groovy
> karaf@root> features:install camel-hazelcast
> Error executing command: Can't install feature camel-hazelcast/0.0.0:
> Could not start bundle mvn:com.hazelcast/hazelcast/3.5.1 in feature(s)
> camel-hazelcast-2.16-SNAPSHOT, camel-vertx-2.16-SNAPSHOT: Activator start
> error in bundle com.hazelcast [79].
> {code}
> Where camel-hazelcast throws this exception:
> {code}
> Caused by: org.osgi.framework.BundleException: Activator start error in
> bundle com.hazelcast [188].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2204)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2072)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
> at
> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:51)
> ... 17 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)[:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
> at
> com.hazelcast.internal.osgi.Activator.activateJavaxScripting(Activator.java:70)
> at com.hazelcast.internal.osgi.Activator.start(Activator.java:46)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2154)
> ... 21 more
> Caused by: java.lang.NoSuchMethodError:
> javax.script.ScriptEngineManager.setBindings(Ljavax/script/Bindings;)V
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.createScriptEngineManager(OSGiScriptEngineManager.java:262)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.findManagers(OSGiScriptEngineManager.java:235)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.(OSGiScriptEngineManager.java:87)
> at
> com.hazelcast.internal.osgi.ScriptEngineActivator.registerOsgiScriptEngineManager(ScriptEngineActivator.java:44)
> ... 29 more
> {code}
> This issue only occurs when certain other bundles are installed. In the above
> example, either one of camel-aws or camel-groovy are dragging some
> dependencies related to scripting (likely camel-groovy) that the Hazelcast
> library doesn't like. Probably because Hazelcast doesn't specify a version
> range in their javax.script import:
> {code}
> [...]
> Bundle-Vendor = Hazelcast, Inc.
> Bundle-Activator = com.hazelcast.internal.osgi.Activator
> Bundle-Name = hazelcast
> Bundle-DocURL = http://www.hazelcast.com/
> Bundle-Description = Core Hazelcast Module
> Bundle-SymbolicName = com.hazelcast
> Bundle-Version = 3.5.1
> Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion = 2
> [...]
> Import-Package =
> [...]
> javax.script,
> [...]
> {code}
> We'll have to investigate further and perhaps open a ticket at Hazelcast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8890) camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted field
[
https://issues.apache.org/jira/browse/CAMEL-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8890:
---
Assignee: Dhiraj Bokde
> camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted
> field
> -
>
> Key: CAMEL-8890
> URL: https://issues.apache.org/jira/browse/CAMEL-8890
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.15.2
>Reporter: Simon Delfab
>Assignee: Dhiraj Bokde
>
> The maven plugin is failing to generate the DTOs. It appears that Salesforce
> has recently introduced a new boolean field call encrypted to the
> 'DescribeSObjectResult' object [1,2]
> The fix is to modify the
> org.apache.camel.component.salesforce.api.dto.SObjectField and add the
> following:
> private Boolean encrypted;
>public Boolean getEncrypted() {
> return encrypted;
> }
> public void setEncrypted(Boolean encrypted) {
> this.encrypted = encrypted;
> }
> With this change the DTOs are generated. However, not sure if there is
> anything else which needs to be done.
> Btw, I am surprised that this new field causes a problem because the default
> API version Camel-Salesforce is configured to is 33.0 and this new field
> appears in 34.0.
> [1]
> https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_describesobjects_describesobjectresult.htm#topic-title
> [2]
> http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_platform_encryption.htm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8789) Websocket with jetty 9 is not working due to class name and package name changes
[ https://issues.apache.org/jira/browse/CAMEL-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8789: --- Fix Version/s: 2.17.0 > Websocket with jetty 9 is not working due to class name and package name > changes > - > > Key: CAMEL-8789 > URL: https://issues.apache.org/jira/browse/CAMEL-8789 > Project: Camel > Issue Type: Bug > Components: camel-websocket >Affects Versions: 2.15.2 > Environment: Mac/Window on Jetty 9.x >Reporter: Amit Patel > Fix For: 2.17.0 > > > http://camel.465427.n5.nabble.com/websocket-with-jetty-9-tp5766712p5767217.html > I did try websocket component with jetty 9 and Apache Camel 2.15.2 and i got > same exception due to SslContextFactory class moved in jetty 9 to > org.eclipse.jetty.util.ssl.folder and Apache websocket > reference to org.eclipse.jetty.http.ssl.SslContextFactory that is only > exist in Jetty 8 and below version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8778) Support .mvn folder
[ https://issues.apache.org/jira/browse/CAMEL-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8778. Resolution: Won't Fix > Support .mvn folder > --- > > Key: CAMEL-8778 > URL: https://issues.apache.org/jira/browse/CAMEL-8778 > Project: Camel > Issue Type: Improvement > Components: build system >Reporter: Gareth Healy >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > Maven 3.3.3 has been released and now supports a .mvn folder for any config. > One of those is JVM settings, so instead of having to set the MAVEN_OPTS env > var, you can have it at project level. > http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9083) Investigate camel-hazelcast feature failure when installed with other bundles
[
https://issues.apache.org/jira/browse/CAMEL-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934705#comment-14934705
]
Claus Ibsen commented on CAMEL-9083:
The workaround is to install hazelcast first
{code}
karaf@root> features:chooseurl camel 2.16-SNAPSHOT
Adding feature url
mvn:org.apache.camel.karaf/apache-camel/2.16-SNAPSHOT/xml/features
karaf@root> features:install camel-hazelcast
karaf@root> features:install camel-groovy
karaf@root> features:install camel-aws
{code}
> Investigate camel-hazelcast feature failure when installed with other bundles
> -
>
> Key: CAMEL-9083
> URL: https://issues.apache.org/jira/browse/CAMEL-9083
> Project: Camel
> Issue Type: Task
> Components: camel-hazelcast, osgi
>Affects Versions: 2.16.0
>Reporter: Raúl Kripalani
>
> {code}
> karaf@root> features:install camel-aws
> karaf@root> features:install camel-groovy
> karaf@root> features:install camel-hazelcast
> Error executing command: Can't install feature camel-hazelcast/0.0.0:
> Could not start bundle mvn:com.hazelcast/hazelcast/3.5.1 in feature(s)
> camel-hazelcast-2.16-SNAPSHOT, camel-vertx-2.16-SNAPSHOT: Activator start
> error in bundle com.hazelcast [79].
> {code}
> Where camel-hazelcast throws this exception:
> {code}
> Caused by: org.osgi.framework.BundleException: Activator start error in
> bundle com.hazelcast [188].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2204)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2072)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
> at
> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:51)
> ... 17 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)[:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
> at
> com.hazelcast.internal.osgi.Activator.activateJavaxScripting(Activator.java:70)
> at com.hazelcast.internal.osgi.Activator.start(Activator.java:46)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2154)
> ... 21 more
> Caused by: java.lang.NoSuchMethodError:
> javax.script.ScriptEngineManager.setBindings(Ljavax/script/Bindings;)V
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.createScriptEngineManager(OSGiScriptEngineManager.java:262)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.findManagers(OSGiScriptEngineManager.java:235)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.(OSGiScriptEngineManager.java:87)
> at
> com.hazelcast.internal.osgi.ScriptEngineActivator.registerOsgiScriptEngineManager(ScriptEngineActivator.java:44)
> ... 29 more
> {code}
> This issue only occurs when certain other bundles are installed. In the above
> example, either one of camel-aws or camel-groovy are dragging some
> dependencies related to scripting (likely camel-groovy) that the Hazelcast
> library doesn't like. Probably because Hazelcast doesn't specify a version
> range in their javax.script import:
> {code}
> [...]
> Bundle-Vendor = Hazelcast, Inc.
> Bundle-Activator = com.hazelcast.internal.osgi.Activator
> Bundle-Name = hazelcast
> Bundle-DocURL = http://www.hazelcast.com/
> Bundle-Description = Core Hazelcast Module
> Bundle-SymbolicName = com.hazelcast
> Bundle-Version = 3.5.1
> Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion = 2
> [...]
> Import-Package =
> [...]
> javax.script,
> [...]
> {code}
> We'll have to investigate further and perhaps open a ticket at Hazelcast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9083) Investigate camel-hazelcast feature failure when installed with other bundles
[
https://issues.apache.org/jira/browse/CAMEL-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9083:
---
Priority: Minor (was: Major)
> Investigate camel-hazelcast feature failure when installed with other bundles
> -
>
> Key: CAMEL-9083
> URL: https://issues.apache.org/jira/browse/CAMEL-9083
> Project: Camel
> Issue Type: Task
> Components: camel-hazelcast, osgi
>Affects Versions: 2.16.0
>Reporter: Raúl Kripalani
>Priority: Minor
>
> {code}
> karaf@root> features:install camel-aws
> karaf@root> features:install camel-groovy
> karaf@root> features:install camel-hazelcast
> Error executing command: Can't install feature camel-hazelcast/0.0.0:
> Could not start bundle mvn:com.hazelcast/hazelcast/3.5.1 in feature(s)
> camel-hazelcast-2.16-SNAPSHOT, camel-vertx-2.16-SNAPSHOT: Activator start
> error in bundle com.hazelcast [79].
> {code}
> Where camel-hazelcast throws this exception:
> {code}
> Caused by: org.osgi.framework.BundleException: Activator start error in
> bundle com.hazelcast [188].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2204)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2072)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
> at
> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:51)
> ... 17 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)[:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
> at
> com.hazelcast.internal.osgi.Activator.activateJavaxScripting(Activator.java:70)
> at com.hazelcast.internal.osgi.Activator.start(Activator.java:46)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2154)
> ... 21 more
> Caused by: java.lang.NoSuchMethodError:
> javax.script.ScriptEngineManager.setBindings(Ljavax/script/Bindings;)V
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.createScriptEngineManager(OSGiScriptEngineManager.java:262)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.findManagers(OSGiScriptEngineManager.java:235)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.(OSGiScriptEngineManager.java:87)
> at
> com.hazelcast.internal.osgi.ScriptEngineActivator.registerOsgiScriptEngineManager(ScriptEngineActivator.java:44)
> ... 29 more
> {code}
> This issue only occurs when certain other bundles are installed. In the above
> example, either one of camel-aws or camel-groovy are dragging some
> dependencies related to scripting (likely camel-groovy) that the Hazelcast
> library doesn't like. Probably because Hazelcast doesn't specify a version
> range in their javax.script import:
> {code}
> [...]
> Bundle-Vendor = Hazelcast, Inc.
> Bundle-Activator = com.hazelcast.internal.osgi.Activator
> Bundle-Name = hazelcast
> Bundle-DocURL = http://www.hazelcast.com/
> Bundle-Description = Core Hazelcast Module
> Bundle-SymbolicName = com.hazelcast
> Bundle-Version = 3.5.1
> Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion = 2
> [...]
> Import-Package =
> [...]
> javax.script,
> [...]
> {code}
> We'll have to investigate further and perhaps open a ticket at Hazelcast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9075) 1% of requests get connect exception and are not sent
[
https://issues.apache.org/jira/browse/CAMEL-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9075:
---
Priority: Minor (was: Major)
> 1% of requests get connect exception and are not sent
> -
>
> Key: CAMEL-9075
> URL: https://issues.apache.org/jira/browse/CAMEL-9075
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
>Affects Versions: 2.14.3
>Reporter: Elyran Kogan
>Priority: Minor
>
> I have a shared worker pool that I'm using for all my producers. I have a
> server that sends requests to a single domain - using camel netty4-http
> when running a small load test, no more than 20 requests per sec, I see that
> some of the requests (about 1%) are timed out and then the netty producer
> sends a ConnectException: (code snipped from NettyProducer class
> if (!channelFuture.isDone() || !channelFuture.isSuccess()) {
> ConnectException cause = new ConnectException("Cannot connect to " +
> configuration.getAddress());
> I did a tcp dump and saw that the requests that were timed out were never
> sent from the server - there was no TCP request that was made.
> the request is simply not sent and there is no indication as to why or what
> is the problem - except a timeout on something that causes the
> ConnectException to appear
> I don't know if it is related, but I'm sending the requests using a routing
> slip
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9083) Investigate camel-hazelcast feature failure when installed with other bundles
[
https://issues.apache.org/jira/browse/CAMEL-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9083:
---
Component/s: (was: camel-osgi)
osgi
camel-hazelcast
> Investigate camel-hazelcast feature failure when installed with other bundles
> -
>
> Key: CAMEL-9083
> URL: https://issues.apache.org/jira/browse/CAMEL-9083
> Project: Camel
> Issue Type: Task
> Components: camel-hazelcast, osgi
>Affects Versions: 2.16.0
>Reporter: Raúl Kripalani
>
> {code}
> karaf@root> features:install camel-aws
> karaf@root> features:install camel-groovy
> karaf@root> features:install camel-hazelcast
> Error executing command: Can't install feature camel-hazelcast/0.0.0:
> Could not start bundle mvn:com.hazelcast/hazelcast/3.5.1 in feature(s)
> camel-hazelcast-2.16-SNAPSHOT, camel-vertx-2.16-SNAPSHOT: Activator start
> error in bundle com.hazelcast [79].
> {code}
> Where camel-hazelcast throws this exception:
> {code}
> Caused by: org.osgi.framework.BundleException: Activator start error in
> bundle com.hazelcast [188].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2204)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2072)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
> at
> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:51)
> ... 17 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)[:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
> at
> com.hazelcast.internal.osgi.Activator.activateJavaxScripting(Activator.java:70)
> at com.hazelcast.internal.osgi.Activator.start(Activator.java:46)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2154)
> ... 21 more
> Caused by: java.lang.NoSuchMethodError:
> javax.script.ScriptEngineManager.setBindings(Ljavax/script/Bindings;)V
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.createScriptEngineManager(OSGiScriptEngineManager.java:262)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.findManagers(OSGiScriptEngineManager.java:235)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.(OSGiScriptEngineManager.java:87)
> at
> com.hazelcast.internal.osgi.ScriptEngineActivator.registerOsgiScriptEngineManager(ScriptEngineActivator.java:44)
> ... 29 more
> {code}
> This issue only occurs when certain other bundles are installed. In the above
> example, either one of camel-aws or camel-groovy are dragging some
> dependencies related to scripting (likely camel-groovy) that the Hazelcast
> library doesn't like. Probably because Hazelcast doesn't specify a version
> range in their javax.script import:
> {code}
> [...]
> Bundle-Vendor = Hazelcast, Inc.
> Bundle-Activator = com.hazelcast.internal.osgi.Activator
> Bundle-Name = hazelcast
> Bundle-DocURL = http://www.hazelcast.com/
> Bundle-Description = Core Hazelcast Module
> Bundle-SymbolicName = com.hazelcast
> Bundle-Version = 3.5.1
> Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion = 2
> [...]
> Import-Package =
> [...]
> javax.script,
> [...]
> {code}
> We'll have to investigate further and perhaps open a ticket at Hazelcast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9025) Programatically view properties loaded via properties file
[
https://issues.apache.org/jira/browse/CAMEL-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934725#comment-14934725
]
Claus Ibsen commented on CAMEL-9025:
Some properties are only resolved on runtime, when using ${env} tokens and so
on. So this can only be for static properties from files etc.
This is likely a bit more tricky to implement than at first thought.
> Programatically view properties loaded via properties file
> --
>
> Key: CAMEL-9025
> URL: https://issues.apache.org/jira/browse/CAMEL-9025
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.15.2
> Environment: Any
>Reporter: Shaishav Parekh
>Priority: Minor
> Labels: PropertiesComponent
>
> Currently there is no way to view properties loaded via a file on the
> classpath if one is using the PropertiesComponent. It would be useful if one
> can programatically access the properties loaded via the classpath for
> reporting reasons.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9067) File consumer - Allow to filter by expression and have two options one for directory and another for file name
[
https://issues.apache.org/jira/browse/CAMEL-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9067:
---
Priority: Minor (was: Major)
> File consumer - Allow to filter by expression and have two options one for
> directory and another for file name
> --
>
> Key: CAMEL-9067
> URL: https://issues.apache.org/jira/browse/CAMEL-9067
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: Future
>
>
> See nabble
> http://camel.465427.n5.nabble.com/smb-endpoint-modified-files-not-copied-to-destination-tp5770499p5770521.html
> People who want to consume from a directory using today as timestamp need to
> write a custom filter java impl to do so.
> We have a bunch of include/antInclude etc options today but they are
> regex/ant based.
> We should have a way of using an expression (simple language) so you can
> filter such as
> {code}
> filterDirectory=${date:now:MMdd}=${file:ext} == 'xml' &&
> ${file:size} > 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9069) Add processor to immediately handle exception while in retry loop
[ https://issues.apache.org/jira/browse/CAMEL-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9069: --- Priority: Major (was: Trivial) > Add processor to immediately handle exception while in retry loop > - > > Key: CAMEL-9069 > URL: https://issues.apache.org/jira/browse/CAMEL-9069 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Kevin Telford > Fix For: 2.17.0 > > > We have a recipientList of http4 endpoints. Occasionally an endpoint won't > be available, and will return an exception (whether a ConnectException, or > any other ex and a status code of >=400). To handle these errors we can use > a defaultErrorHandler or leverage onException, and setup redelivery. What we > then would like to do is some custom error handling on each occurrence of an > exception. > Both the defaultErrorHandler and onException support .onRedelivery(). While > this is nice, when a retry delay grows large enough the lag between the > exception and the .onRedelivery() call really begins to grow and so our > custom error handling isn't as much “on error” as it is “on error and after a > wait”. > onException also supports a .process() call, however this only occurs once > all redeliveries have failed. > What would be ideal would be an additional .onExceptionOccur(Processor > processor) method (or some such name) that allows for immediate processing > upon an exception, even if its being handled within a retry loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9069) Add processor to immediately handle exception while in retry loop
[ https://issues.apache.org/jira/browse/CAMEL-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-9069: -- Assignee: Claus Ibsen > Add processor to immediately handle exception while in retry loop > - > > Key: CAMEL-9069 > URL: https://issues.apache.org/jira/browse/CAMEL-9069 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Kevin Telford >Assignee: Claus Ibsen > Fix For: 2.17.0 > > > We have a recipientList of http4 endpoints. Occasionally an endpoint won't > be available, and will return an exception (whether a ConnectException, or > any other ex and a status code of >=400). To handle these errors we can use > a defaultErrorHandler or leverage onException, and setup redelivery. What we > then would like to do is some custom error handling on each occurrence of an > exception. > Both the defaultErrorHandler and onException support .onRedelivery(). While > this is nice, when a retry delay grows large enough the lag between the > exception and the .onRedelivery() call really begins to grow and so our > custom error handling isn't as much “on error” as it is “on error and after a > wait”. > onException also supports a .process() call, however this only occurs once > all redeliveries have failed. > What would be ideal would be an additional .onExceptionOccur(Processor > processor) method (or some such name) that allows for immediate processing > upon an exception, even if its being handled within a retry loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8917) camel-cxfrs doesn't use the resource classes handle the invocation directly
[
https://issues.apache.org/jira/browse/CAMEL-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8917.
Resolution: Won't Fix
> camel-cxfrs doesn't use the resource classes handle the invocation directly
> ---
>
> Key: CAMEL-8917
> URL: https://issues.apache.org/jira/browse/CAMEL-8917
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxfrs
>Reporter: Charles Moulliard
> Labels: camel-cxfrs
>
> Here is the content of our discussion
> As the camel-swagger get the ServiceModule from the Route definition which is
> dumped to XML, it is quit different from the CXF-swagger who builds the
> ServiceModule from the Resource Class.
> As camel-cxfrs doesn't use the resource classes handle the invocation
> directly (it just delegates the request to the camel route), so it causes
> some trouble if the CXF-swagger try to load the resource classes. To fix it,
> we may need to find a way to generate the ServiceModule rightly.
> Issue :
> {code}
> I try now to use Swagger as described here :
> https://github.com/swagger-api/swagger-core/wiki/Java-CXF-Quickstart and
> implemented as such :
> https://github.com/cmoulliard/use-cases/blob/master/fabric-camel-rest/src/main/resources/OSGI-INF/blueprint/camel.xml#L11-L40
> When we launch locally mvn camel:run but I get -->
> "No message body writer has been found for class
> org.apache.cxf.message.MessageContentsList, ContentType:
> application/json;charset=utf-8" at this address
> "http://localhost:8080/cxf/rest/api-docs
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8890) camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted field
[
https://issues.apache.org/jira/browse/CAMEL-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934758#comment-14934758
]
Claus Ibsen commented on CAMEL-8890:
Dhiraj havent we improved this component so it works now?
> camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted
> field
> -
>
> Key: CAMEL-8890
> URL: https://issues.apache.org/jira/browse/CAMEL-8890
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.15.2
>Reporter: Simon Delfab
>Assignee: Dhiraj Bokde
>
> The maven plugin is failing to generate the DTOs. It appears that Salesforce
> has recently introduced a new boolean field call encrypted to the
> 'DescribeSObjectResult' object [1,2]
> The fix is to modify the
> org.apache.camel.component.salesforce.api.dto.SObjectField and add the
> following:
> private Boolean encrypted;
>public Boolean getEncrypted() {
> return encrypted;
> }
> public void setEncrypted(Boolean encrypted) {
> this.encrypted = encrypted;
> }
> With this change the DTOs are generated. However, not sure if there is
> anything else which needs to be done.
> Btw, I am surprised that this new field causes a problem because the default
> API version Camel-Salesforce is configured to is 33.0 and this new field
> appears in 34.0.
> [1]
> https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_describesobjects_describesobjectresult.htm#topic-title
> [2]
> http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_platform_encryption.htm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8917) camel-cxfrs doesn't use the resource classes handle the invocation directly
[
https://issues.apache.org/jira/browse/CAMEL-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934756#comment-14934756
]
Claus Ibsen commented on CAMEL-8917:
There is some work in progress by Sergey to implement rest-dsl to CXF-RS
> camel-cxfrs doesn't use the resource classes handle the invocation directly
> ---
>
> Key: CAMEL-8917
> URL: https://issues.apache.org/jira/browse/CAMEL-8917
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxfrs
>Reporter: Charles Moulliard
> Labels: camel-cxfrs
>
> Here is the content of our discussion
> As the camel-swagger get the ServiceModule from the Route definition which is
> dumped to XML, it is quit different from the CXF-swagger who builds the
> ServiceModule from the Resource Class.
> As camel-cxfrs doesn't use the resource classes handle the invocation
> directly (it just delegates the request to the camel route), so it causes
> some trouble if the CXF-swagger try to load the resource classes. To fix it,
> we may need to find a way to generate the ServiceModule rightly.
> Issue :
> {code}
> I try now to use Swagger as described here :
> https://github.com/swagger-api/swagger-core/wiki/Java-CXF-Quickstart and
> implemented as such :
> https://github.com/cmoulliard/use-cases/blob/master/fabric-camel-rest/src/main/resources/OSGI-INF/blueprint/camel.xml#L11-L40
> When we launch locally mvn camel:run but I get -->
> "No message body writer has been found for class
> org.apache.cxf.message.MessageContentsList, ContentType:
> application/json;charset=utf-8" at this address
> "http://localhost:8080/cxf/rest/api-docs
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8969) Add component for CoAP
[ https://issues.apache.org/jira/browse/CAMEL-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8969. Resolution: Fixed > Add component for CoAP > -- > > Key: CAMEL-8969 > URL: https://issues.apache.org/jira/browse/CAMEL-8969 > Project: Camel > Issue Type: New Feature >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.16.0 > > > For interacting with devices, we currently have an mqtt component, but it > would also be good to have a component that speaks CoAP. > Likely based on http://www.eclipse.org/californium/ as that seems to be the > most complete at this point (plus has OSGi support already). > nCoAP could be another option: https://github.com/okleine/nCoAP which has a > nicer license (BSD), but isn't as complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9085) Create a Camel-Kubernetes/Openshift v3 Component
[ https://issues.apache.org/jira/browse/CAMEL-9085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9085: --- Fix Version/s: 2.17.0 > Create a Camel-Kubernetes/Openshift v3 Component > > > Key: CAMEL-9085 > URL: https://issues.apache.org/jira/browse/CAMEL-9085 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino > Fix For: 2.17.0 > > > Using the Fabric8 Kubernetes/Openshift v3 client. > https://github.com/fabric8io/kubernetes-client -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9083) Investigate camel-hazelcast feature failure when installed with other bundles
[
https://issues.apache.org/jira/browse/CAMEL-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934703#comment-14934703
]
Claus Ibsen commented on CAMEL-9083:
Yes its a bug in hazelcast. Raul, would you report it to them?
> Investigate camel-hazelcast feature failure when installed with other bundles
> -
>
> Key: CAMEL-9083
> URL: https://issues.apache.org/jira/browse/CAMEL-9083
> Project: Camel
> Issue Type: Task
> Components: camel-osgi
>Affects Versions: 2.16.0
>Reporter: Raúl Kripalani
>
> {code}
> karaf@root> features:install camel-aws
> karaf@root> features:install camel-groovy
> karaf@root> features:install camel-hazelcast
> Error executing command: Can't install feature camel-hazelcast/0.0.0:
> Could not start bundle mvn:com.hazelcast/hazelcast/3.5.1 in feature(s)
> camel-hazelcast-2.16-SNAPSHOT, camel-vertx-2.16-SNAPSHOT: Activator start
> error in bundle com.hazelcast [79].
> {code}
> Where camel-hazelcast throws this exception:
> {code}
> Caused by: org.osgi.framework.BundleException: Activator start error in
> bundle com.hazelcast [188].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2204)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2072)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)
> at
> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:51)
> ... 17 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)[:1.7.0_79]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_79]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_79]
> at
> com.hazelcast.internal.osgi.Activator.activateJavaxScripting(Activator.java:70)
> at com.hazelcast.internal.osgi.Activator.start(Activator.java:46)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2154)
> ... 21 more
> Caused by: java.lang.NoSuchMethodError:
> javax.script.ScriptEngineManager.setBindings(Ljavax/script/Bindings;)V
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.createScriptEngineManager(OSGiScriptEngineManager.java:262)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.findManagers(OSGiScriptEngineManager.java:235)
> at
> com.hazelcast.internal.osgi.OSGiScriptEngineManager.(OSGiScriptEngineManager.java:87)
> at
> com.hazelcast.internal.osgi.ScriptEngineActivator.registerOsgiScriptEngineManager(ScriptEngineActivator.java:44)
> ... 29 more
> {code}
> This issue only occurs when certain other bundles are installed. In the above
> example, either one of camel-aws or camel-groovy are dragging some
> dependencies related to scripting (likely camel-groovy) that the Hazelcast
> library doesn't like. Probably because Hazelcast doesn't specify a version
> range in their javax.script import:
> {code}
> [...]
> Bundle-Vendor = Hazelcast, Inc.
> Bundle-Activator = com.hazelcast.internal.osgi.Activator
> Bundle-Name = hazelcast
> Bundle-DocURL = http://www.hazelcast.com/
> Bundle-Description = Core Hazelcast Module
> Bundle-SymbolicName = com.hazelcast
> Bundle-Version = 3.5.1
> Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion = 2
> [...]
> Import-Package =
> [...]
> javax.script,
> [...]
> {code}
> We'll have to investigate further and perhaps open a ticket at Hazelcast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9034) Replace hardcoded JettyRestHttpBinding instantiation in JettyHttpComponent
[
https://issues.apache.org/jira/browse/CAMEL-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9034:
---
Priority: Minor (was: Major)
> Replace hardcoded JettyRestHttpBinding instantiation in JettyHttpComponent
> --
>
> Key: CAMEL-9034
> URL: https://issues.apache.org/jira/browse/CAMEL-9034
> Project: Camel
> Issue Type: Improvement
> Components: camel-jetty
>Affects Versions: 2.15.2
>Reporter: Christian Bauer
>Priority: Minor
>
> The code in JettyHttpComponent seems to ignore any httpBindingRef endpoint
> property, at least if you use the REST DSL. It always creates a consumer with
> this binding if the RestConsumerFactory#createConsumer extension is used:
> {code}
> endpoint.setBinding(new JettyRestHttpBinding(endpoint));
> {code}
> This makes it impossible to configure custom error responses by overriding
> the doWriteExceptionResponse method of the binding, as documented.
> My actual case is an (invalid) Java instance I'm transforming to JSON with
> Jackson. This happens in RestBindingMarshalOnCompletion#onAfterRoute and the
> only way to catch an exception at this stage seems to be in the HttpBinding.
> Note that this means users of the REST DSL will always return 500 errors with
> full stacktraces on marshalling failures.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9034) Replace hardcoded JettyRestHttpBinding instantiation in JettyHttpComponent
[
https://issues.apache.org/jira/browse/CAMEL-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-9034.
Resolution: Won't Fix
This is intended when using rest-dsl. See the link to that other ticket
> Replace hardcoded JettyRestHttpBinding instantiation in JettyHttpComponent
> --
>
> Key: CAMEL-9034
> URL: https://issues.apache.org/jira/browse/CAMEL-9034
> Project: Camel
> Issue Type: Improvement
> Components: camel-jetty
>Affects Versions: 2.15.2
>Reporter: Christian Bauer
>Priority: Minor
>
> The code in JettyHttpComponent seems to ignore any httpBindingRef endpoint
> property, at least if you use the REST DSL. It always creates a consumer with
> this binding if the RestConsumerFactory#createConsumer extension is used:
> {code}
> endpoint.setBinding(new JettyRestHttpBinding(endpoint));
> {code}
> This makes it impossible to configure custom error responses by overriding
> the doWriteExceptionResponse method of the binding, as documented.
> My actual case is an (invalid) Java instance I'm transforming to JSON with
> Jackson. This happens in RestBindingMarshalOnCompletion#onAfterRoute and the
> only way to catch an exception at this stage seems to be in the HttpBinding.
> Note that this means users of the REST DSL will always return 500 errors with
> full stacktraces on marshalling failures.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9008) Contributing GRPC / Thrift support to Camel
[ https://issues.apache.org/jira/browse/CAMEL-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934726#comment-14934726 ] Claus Ibsen commented on CAMEL-9008: Any work on this? > Contributing GRPC / Thrift support to Camel > --- > > Key: CAMEL-9008 > URL: https://issues.apache.org/jira/browse/CAMEL-9008 > Project: Camel > Issue Type: New Feature >Reporter: Andrew Harmel-Law > Fix For: Future > > > Hi, > We're building Microservices with Camel, predominantly producing from REST > DSL components and have got to the point where having an easy way to swap in > GRPC [1] / Thrift [2] endpoints and clients would be of great help. > We wondered if this was already on the cards for a future release, and if we > might be able to work on it, and if not, if it would be something we could > work on and contribute (with guidance to smooth the design and > implementation)? > Kind regards, the Capgemini UK and Indian Camel teams > [1] http://www.grpc.io/ > [2] https://thrift.apache.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8853) CXF endpoint with a relative address cannot be invoked by a producer template
[
https://issues.apache.org/jira/browse/CAMEL-8853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8853:
---
Fix Version/s: Future
> CXF endpoint with a relative address cannot be invoked by a producer template
> -
>
> Key: CAMEL-8853
> URL: https://issues.apache.org/jira/browse/CAMEL-8853
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.15.2
>Reporter: Tomas Rohovsky
> Fix For: Future
>
> Attachments: cxf-producer-template.zip
>
>
> If you invoke this Camel CXF endpoint by a producer template:
> {code}
> serviceClass="org.example.cxf_producer_template.GreetingService"/>
> {code}
> you will get:
> {code}
> org.apache.camel.CamelExecutionException: Exception occurred during execution
> on the exchange: Exchange[Message: Tom]
> at
> org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1635)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:645)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:471)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:133)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:149)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:301)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:331)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.example.cxf_producer_template.ProducerProcessor.process(ProducerProcessor.java:12)[265:cxf-producer-template:0.0.1.SNAPSHOT]
> at
> org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:103)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:129)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:165)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:73)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_71]
> at java.util.TimerThread.run(Timer.java:505)[:1.7.0_71]
> Caused by: java.lang.IllegalArgumentException: URI is not absolute
> at java.net.URI.toURL(URI.java:1095)[:1.7.0_71]
> at
> org.apache.cxf.transport.http.Address.getURL(Address.java:45)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit.createConnection(URLConnectionHTTPConduit.java:93)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit.setupConnection(URLConnectionHTTPConduit.java:105)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
>
[jira] [Commented] (CAMEL-8853) CXF endpoint with a relative address cannot be invoked by a producer template
[
https://issues.apache.org/jira/browse/CAMEL-8853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934762#comment-14934762
]
Claus Ibsen commented on CAMEL-8853:
Yeah if you use cxf:bean then I think we should lookup the endpoint and grab an
absolute url for the http to use.
> CXF endpoint with a relative address cannot be invoked by a producer template
> -
>
> Key: CAMEL-8853
> URL: https://issues.apache.org/jira/browse/CAMEL-8853
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.15.2
>Reporter: Tomas Rohovsky
> Fix For: Future
>
> Attachments: cxf-producer-template.zip
>
>
> If you invoke this Camel CXF endpoint by a producer template:
> {code}
> serviceClass="org.example.cxf_producer_template.GreetingService"/>
> {code}
> you will get:
> {code}
> org.apache.camel.CamelExecutionException: Exception occurred during execution
> on the exchange: Exchange[Message: Tom]
> at
> org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1635)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:645)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:471)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:133)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:149)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:301)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:331)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.example.cxf_producer_template.ProducerProcessor.process(ProducerProcessor.java:12)[265:cxf-producer-template:0.0.1.SNAPSHOT]
> at
> org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:103)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:129)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:77)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:448)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:165)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at
> org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:73)[198:org.apache.camel.camel-core:2.15.1.redhat-620123]
> at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_71]
> at java.util.TimerThread.run(Timer.java:505)[:1.7.0_71]
> Caused by: java.lang.IllegalArgumentException: URI is not absolute
> at java.net.URI.toURL(URI.java:1095)[:1.7.0_71]
> at
> org.apache.cxf.transport.http.Address.getURL(Address.java:45)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
> org.apache.cxf.transport.http.URLConnectionHTTPConduit.createConnection(URLConnectionHTTPConduit.java:93)[123:org.apache.cxf.cxf-rt-transports-http:3.0.4.redhat-620123]
> at
>
[jira] [Resolved] (CAMEL-8442) camel-univocity-parsers - Fails unit test on windows
[ https://issues.apache.org/jira/browse/CAMEL-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8442. Resolution: Later > camel-univocity-parsers - Fails unit test on windows > > > Key: CAMEL-8442 > URL: https://issues.apache.org/jira/browse/CAMEL-8442 > Project: Camel > Issue Type: Test >Affects Versions: 2.15.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > Attachments: console.txt, log.txt > > > Tests in error: > UniVocityCsvDataFormatUnmarshalSpringTest.shouldUnmarshalUsingIterator:117 > » TextParsing > UniVocityCsvDataFormatUnmarshalTest.shouldUnmarshalUsingIterator:119 » > TextParsing > > UniVocityFixedWidthDataFormatUnmarshalSpringTest.shouldUnmarshalUsingIterator:117 > » TextParsing > UniVocityFixedWidthDataFormatUnmarshalTest.shouldUnmarshalUsingIterator:118 > » TextParsing > UniVocityTsvDataFormatUnmarshalSpringTest.shouldUnmarshalUsingIterator:117 > » TextParsing > UniVocityTsvDataFormatUnmarshalTest.shouldUnmarshalUsingIterator:118 » > TextParsing > Tests run: 115, Failures: 0, Errors: 6, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-9177) combination of JPA-Component, loop and wiretap throws entitymanger cloesd exception
[
https://issues.apache.org/jira/browse/CAMEL-9177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-9177:
--
Assignee: Claus Ibsen
> combination of JPA-Component, loop and wiretap throws entitymanger cloesd
> exception
> ---
>
> Key: CAMEL-9177
> URL: https://issues.apache.org/jira/browse/CAMEL-9177
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-jpa
>Affects Versions: 2.15.2, 2.15.3
> Environment: Camel 2.15.2 with Spring-Boot 1.2.3.RELEASE (with camel
> xml dsl)
>Reporter: Pascal S.
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.0
>
>
> Hi,
> I have found a problem regarding a wiretap and the camel-jpa component. I
> have a route with an async split through a wiretap. In each route, I use a
> jpa producer to persist an entity. The problem is, that the entitymanager was
> closed before the async routes can reach the end. The cause is, that the same
> entitymanager is used in the async routes. The main route reaches the end and
> closes the entitymanager.
> E.g. like the following route:
> {code}
>
> ...
>
> ...
>
> ...
>
>
>
>
>
> ...
>
> ...
>
> {code}
> I think a possible fix can be to check that the entitymanager is null or
> closed. If null or closed, create a new entitymanager.
> {code}
> public final class JpaHelper {
> ...
> public static EntityManager getTargetEntityManager(Exchange exchange, ...
> ...
> if (em == null || !em.isOpen()) {
> // create a new entity manager
> em = entityManagerFactory.createEntityManager();
> ...
> }
> }
> ...
> }
> {code}
> Another solution can be in the wiretap. There where the exchange is copied,
> the "CamelEntityManager" property could be removed.
> Currently, my quickfix is: At the beginning of the async route I remove the
> entitymanager from the exchange.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934710#comment-14934710
]
Claus Ibsen commented on CAMEL-9070:
Any update?
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the behavior is
> related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
> following headers:
> {noformat}
> POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
> Accept-Encoding: gzip,deflate
> Content-Type: multipart/related; type="application/xop+xml";
> start=""; start-info="application/soap+xml";
> action="urn:ihe:iti:2007:RetrieveDocumentSet";
> boundary="=_Part_139_1471895036.1439218177147"
> MIME-Version: 1.0
> Content-Length: 6858
> Host: localhost:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
> {noformat}
> The issue pops up at random but not evenly distributed. It either almost
> always happens or hardly ever. Re-installing my bundle or restarting Karaf
> usually triggers a switch between the two scenarios on some machines. On
> others the error is persistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[
https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9070:
---
Priority: Minor (was: Major)
> java.lang.IllegalStateException: SENDING => HEADERS
> ---
>
> Key: CAMEL-9070
> URL: https://issues.apache.org/jira/browse/CAMEL-9070
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.15.2
> Environment: Karaf 3.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> When using the jetty component in a simple reverse proxy route deployed in
> {{Karaf 3.0.3}} I randomly receive the following Stacktrace:
> {noformat}
> 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange
> | 117 - org.eclipse.jetty.aggregate.jetty-all-server -
> 8.1.15.v20140411 | | EXCEPTION
> ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms
> org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING
> => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by:
> [java.lang.IllegalStateException - SENDING => HEADERS]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at java.lang.Thread.run(Thread.java:745)[:1.7.0_60]
> Caused by: java.lang.IllegalStateException: SENDING => HEADERS
> at
> org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> at
> org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
> ... 5 more
> {noformat}
> I have found (rather old) posts on the web that claim that the behavior is
> related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the
> following headers:
> {noformat}
> POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1
> Accept-Encoding: gzip,deflate
> Content-Type: multipart/related; type="application/xop+xml";
> start=""; start-info="application/soap+xml";
> action="urn:ihe:iti:2007:RetrieveDocumentSet";
> boundary="=_Part_139_1471895036.1439218177147"
> MIME-Version: 1.0
> Content-Length: 6858
> Host: localhost:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
> {noformat}
> The issue pops up at random but not evenly distributed. It either almost
> always happens or hardly ever. Re-installing my bundle or restarting Karaf
> usually triggers a switch between the two scenarios on some machines. On
> others the error is persistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9075) 1% of requests get connect exception and are not sent
[
https://issues.apache.org/jira/browse/CAMEL-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934708#comment-14934708
]
Claus Ibsen commented on CAMEL-9075:
Try with latest release and also provide more details what you mean by shared
worker pool, and what you do in that routing slip
> 1% of requests get connect exception and are not sent
> -
>
> Key: CAMEL-9075
> URL: https://issues.apache.org/jira/browse/CAMEL-9075
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
>Affects Versions: 2.14.3
>Reporter: Elyran Kogan
>Priority: Minor
>
> I have a shared worker pool that I'm using for all my producers. I have a
> server that sends requests to a single domain - using camel netty4-http
> when running a small load test, no more than 20 requests per sec, I see that
> some of the requests (about 1%) are timed out and then the netty producer
> sends a ConnectException: (code snipped from NettyProducer class
> if (!channelFuture.isDone() || !channelFuture.isSuccess()) {
> ConnectException cause = new ConnectException("Cannot connect to " +
> configuration.getAddress());
> I did a tcp dump and saw that the requests that were timed out were never
> sent from the server - there was no TCP request that was made.
> the request is simply not sent and there is no indication as to why or what
> is the problem - except a timeout on something that causes the
> ConnectException to appear
> I don't know if it is related, but I'm sending the requests using a routing
> slip
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-9063) Add useGetBytesForBlob option in camel-jdbc
[ https://issues.apache.org/jira/browse/CAMEL-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-9063: -- Assignee: Claus Ibsen > Add useGetBytesForBlob option in camel-jdbc > --- > > Key: CAMEL-9063 > URL: https://issues.apache.org/jira/browse/CAMEL-9063 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc >Affects Versions: 2.15.2 >Reporter: João Antonio da Cruz Júnior >Assignee: Claus Ibsen > Fix For: 2.16.0 > > Attachments: useGetBytesForBlob.patch > > > As described in Oracle documentation(avaliable at > http://docs.oracle.com/cd/E18283_01/java.112/e16548/oralob.htm#CHDCDFAC ): > "The getString and getNString methods cannot be used for retrieving BLOB > column values". So i changed the component to accept an option to use the > getBytes method instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9063) Add useGetBytesForBlob option in camel-jdbc
[ https://issues.apache.org/jira/browse/CAMEL-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9063: --- Fix Version/s: 2.16.0 > Add useGetBytesForBlob option in camel-jdbc > --- > > Key: CAMEL-9063 > URL: https://issues.apache.org/jira/browse/CAMEL-9063 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc >Affects Versions: 2.15.2 >Reporter: João Antonio da Cruz Júnior > Fix For: 2.16.0 > > Attachments: useGetBytesForBlob.patch > > > As described in Oracle documentation(avaliable at > http://docs.oracle.com/cd/E18283_01/java.112/e16548/oralob.htm#CHDCDFAC ): > "The getString and getNString methods cannot be used for retrieving BLOB > column values". So i changed the component to accept an option to use the > getBytes method instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8793) Deadlock between Spring and SpringCamelContext
[
https://issues.apache.org/jira/browse/CAMEL-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8793.
Resolution: Won't Fix
> Deadlock between Spring and SpringCamelContext
> --
>
> Key: CAMEL-8793
> URL: https://issues.apache.org/jira/browse/CAMEL-8793
> Project: Camel
> Issue Type: Bug
> Components: camel-spring
>Affects Versions: 2.15.2
> Environment: Spring 4.1.5.RELEASE
>Reporter: Mateusz Nowakowski
>
> Scenario:
> - used Camel spring with xmlns="http://camel.apache.org/schema/spring; />
> - camelContext is used by some internal bean to expose an api to register
> routes for other thread
> - Spring hasn't finished initializing beans from the spring context contains
> Spring Camel context
> - different thread starts using an api - calling indirectly Spring Camel
> context to register routes
> - Camel context in order to add route get locks: camel context, spring
> singleton lock (due to spring registry), but initial thread starting Spring
> context get lock: spring singleton lock, camel context... causing deadlock.
> Workaround:
> - create and start DefaultCamelContext without Spring Registry.
> {code}
> Found one Java-level deadlock:
> =
> "localhost-startStop-6":
> waiting to lock monitor 0xf350f544 (object 0x7e04a668, a
> org.apache.camel.spring.SpringCamelContext),
> which is held by "lifecycleWorker6"
> "lifecycleWorker6":
> waiting to lock monitor 0xf33ecc84 (object 0x7f01dc70, a
> java.util.concurrent.ConcurrentHashMap),
> which is held by "localhost-startStop-6"
> Java stack information for the threads listed above:
> ===
> "localhost-startStop-6":
> at
> org.apache.camel.impl.DefaultCamelContext.addRouteDefinitions(DefaultCamelContext.java:767)
> - waiting to lock <0x7e04a668> (a
> org.apache.camel.spring.SpringCamelContext)
> at
> org.apache.camel.builder.RouteBuilder.populateRoutes(RouteBuilder.java:397)
> at
> org.apache.camel.builder.RouteBuilder.addRoutesToCamelContext(RouteBuilder.java:311)
> at
> org.apache.camel.impl.DefaultCamelContext$1.call(DefaultCamelContext.java:731)
> at
> org.apache.camel.impl.DefaultCamelContext$1.call(DefaultCamelContext.java:728)
> at
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2486)
> at
> org.apache.camel.impl.DefaultCamelContext.addRoutes(DefaultCamelContext.java:728)
> at
> com.blablabla.BlaBlaRegistrar.registerBlaBlas(BlaBlaRegistrar.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:349)
> at
> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:300)
> at
> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:133)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:408)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1558)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> - locked <0x7f01dc70> (a java.util.concurrent.ConcurrentHashMap)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755)
> at
>
[jira] [Updated] (CAMEL-8789) Websocket with jetty 9 is not working due to class name and package name changes
[ https://issues.apache.org/jira/browse/CAMEL-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8789: --- Assignee: (was: Willem Jiang) > Websocket with jetty 9 is not working due to class name and package name > changes > - > > Key: CAMEL-8789 > URL: https://issues.apache.org/jira/browse/CAMEL-8789 > Project: Camel > Issue Type: Bug > Components: camel-websocket >Affects Versions: 2.15.2 > Environment: Mac/Window on Jetty 9.x >Reporter: Amit Patel > > http://camel.465427.n5.nabble.com/websocket-with-jetty-9-tp5766712p5767217.html > I did try websocket component with jetty 9 and Apache Camel 2.15.2 and i got > same exception due to SslContextFactory class moved in jetty 9 to > org.eclipse.jetty.util.ssl.folder and Apache websocket > reference to org.eclipse.jetty.http.ssl.SslContextFactory that is only > exist in Jetty 8 and below version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8420) Not possible to use inner classes for Dtos in Camel Swagger
[
https://issues.apache.org/jira/browse/CAMEL-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934784#comment-14934784
]
Claus Ibsen commented on CAMEL-8420:
You need to declare the class as
'org.apache.camel.example.rest.UserService$User` and also add the swagger api
model.
It works in the new camel-swagger-java module
> Not possible to use inner classes for Dtos in Camel Swagger
> ---
>
> Key: CAMEL-8420
> URL: https://issues.apache.org/jira/browse/CAMEL-8420
> Project: Camel
> Issue Type: Improvement
> Components: camel-swagger
>Affects Versions: 2.14.1
>Reporter: Espen Tjonneland
>Priority: Minor
>
> If you inline your Dto classes with your services then Camel fails to load
> them (ClassNotFoundException).
> Can easily be reproduced by modifying the Camel :: Example :: Serlet REST
> example by moving the User class into the UserService and update the
> UserRoute builder to use the moved type.
> {code:title=UserService.java|borderStyle=solid}
> public class UserService {
> // use a tree map so they become sorted
> private final Map
> users = new TreeMap();
> private Random ran = new Random();
> public UserService() {
> users.put("123", new
> org.apache.camel.example.rest.UserService.User(123, "John Doe"));
> users.put("456", new
> org.apache.camel.example.rest.UserService.User(456, "Donald Duck"));
> users.put("789", new
> org.apache.camel.example.rest.UserService.User(789, "Slow Turtle"));
> }
> /**
> * Gets a user by the given id
> *
> * @param id the id of the user
> * @return the user, or null if no user exists
> */
> public org.apache.camel.example.rest.UserService.User getUser(String id) {
>
> }
> /**
> * List all users
> *
> * @return the list of all users
> */
> public Collection
> listUsers() {
>
> }
> /**
> * Updates or creates the given user
> *
> * @param user the user
> */
> public void updateUser(org.apache.camel.example.rest.UserService.User
> user) {
>
> }
> public static class User {
> private int id;
> private String name;
>
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9069) Add processor to immediately handle exception while in retry loop
[ https://issues.apache.org/jira/browse/CAMEL-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935031#comment-14935031 ] Kevin Telford commented on CAMEL-9069: -- I can't believe I didn't respond earlier, terribly sorry. What we'd like to have is that on a failure, a near real-time way to gather information and notify (log or call a method) about the failure. It may be as simple as just a notification of a failure and information from a header, or perhaps (if available) more information from the failed HTTP attempt (status code etc). As far as what should happen if a new exception were thrown, or the exchange altered, I think it should remain consistent with the existing .onRedelivery() and .process() methods. > Add processor to immediately handle exception while in retry loop > - > > Key: CAMEL-9069 > URL: https://issues.apache.org/jira/browse/CAMEL-9069 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Kevin Telford >Assignee: Claus Ibsen > Fix For: 2.17.0 > > > We have a recipientList of http4 endpoints. Occasionally an endpoint won't > be available, and will return an exception (whether a ConnectException, or > any other ex and a status code of >=400). To handle these errors we can use > a defaultErrorHandler or leverage onException, and setup redelivery. What we > then would like to do is some custom error handling on each occurrence of an > exception. > Both the defaultErrorHandler and onException support .onRedelivery(). While > this is nice, when a retry delay grows large enough the lag between the > exception and the .onRedelivery() call really begins to grow and so our > custom error handling isn't as much “on error” as it is “on error and after a > wait”. > onException also supports a .process() call, however this only occurs once > all redeliveries have failed. > What would be ideal would be an additional .onExceptionOccur(Processor > processor) method (or some such name) that allows for immediate processing > upon an exception, even if its being handled within a retry loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-9168) CXF - Classpath resource not found when RoutesBuilder exposed as OSGi service
[
https://issues.apache.org/jira/browse/CAMEL-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Markevich closed CAMEL-9168.
---
Resolution: Not A Problem
getClass().getResource("Foo.wsdl").toString()
> CXF - Classpath resource not found when RoutesBuilder exposed as OSGi service
> -
>
> Key: CAMEL-9168
> URL: https://issues.apache.org/jira/browse/CAMEL-9168
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf, osgi
>Affects Versions: 2.15.3
>Reporter: Alexey Markevich
> Attachments: camel-example-cxf.zip, r2-0.2.jar, route.xml
>
>
> 17:11:03,780 | WARN | tenderThread-145 | .apache.cxf.resource.URIResolver
> 375 | 82 - org.apache.cxf.cxf-core - 3.1.2 | Resource classpath:DemoWsdl_0.1
> was not found in the classloaders.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7180) Support multiple onWhen + onOtherwise in onComplete blocks
[
https://issues.apache.org/jira/browse/CAMEL-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935336#comment-14935336
]
Raúl Kripalani commented on CAMEL-7180:
---
You're right. I was going for syntactic sugar, but there has been no further
demand on this ticket so I think the community doesn't need it.
However, I do see this being useful not in the context of a choice where only 1
path would be taken, but in a "condition guards" use-case, e.g.:
{code}
.onCompletion().onCompleteOnly()
.onWhen(xpath("/result = 'ok'"))
.log("All good!")
.onWhen(xpath("/result/code = 'abc-0001'"))
.log("Code abc-0001")
.end()
{code}
Each condition would be satisfied by itself, without interrupting the block if
one matches.
Currently, one doesn't have an easy way of implementing this routing logic if
not using multicast + filters, right?
In this case, we'd obviously drop the {{onOtherwise}} DSL.
> Support multiple onWhen + onOtherwise in onComplete blocks
> --
>
> Key: CAMEL-7180
> URL: https://issues.apache.org/jira/browse/CAMEL-7180
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Affects Versions: 2.12.2
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
>
> Will allow for something like:
> {code}
> .onCompletion().onCompleteOnly()
> .onWhen(xpath("/result = 'ok'"))
> .log("All good!")
> .onWhen(xpath("/result = 'warn'"))
> .log(LoggingLevel.WARN, "Something didn't go quite as right!")
> .onOtherwise()
> .log(LoggingLevel.ERROR, "Something went awfully wrong!")
> .end()
> {code}
> This will specifically benefit route-level onComplete blocks, as only 1 is
> supported per route. Currently, if you want to take decisions, you have to
> create a nested choice() which feels clumsy, given that the onComplete DSL
> already supports some degree of decision-making.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8890) camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted field
[
https://issues.apache.org/jira/browse/CAMEL-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936151#comment-14936151
]
Dhiraj Bokde commented on CAMEL-8890:
-
I will update the affected class.
> camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted
> field
> -
>
> Key: CAMEL-8890
> URL: https://issues.apache.org/jira/browse/CAMEL-8890
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.15.2
>Reporter: Simon Delfab
>Assignee: Dhiraj Bokde
>
> The maven plugin is failing to generate the DTOs. It appears that Salesforce
> has recently introduced a new boolean field call encrypted to the
> 'DescribeSObjectResult' object [1,2]
> The fix is to modify the
> org.apache.camel.component.salesforce.api.dto.SObjectField and add the
> following:
> private Boolean encrypted;
>public Boolean getEncrypted() {
> return encrypted;
> }
> public void setEncrypted(Boolean encrypted) {
> this.encrypted = encrypted;
> }
> With this change the DTOs are generated. However, not sure if there is
> anything else which needs to be done.
> Btw, I am surprised that this new field causes a problem because the default
> API version Camel-Salesforce is configured to is 33.0 and this new field
> appears in 34.0.
> [1]
> https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_describesobjects_describesobjectresult.htm#topic-title
> [2]
> http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_platform_encryption.htm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8890) camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted field
[
https://issues.apache.org/jira/browse/CAMEL-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936184#comment-14936184
]
Dhiraj Bokde commented on CAMEL-8890:
-
[~davsclaus], you are right, the field exists on master and camel-2.15.x
branches.
> camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted
> field
> -
>
> Key: CAMEL-8890
> URL: https://issues.apache.org/jira/browse/CAMEL-8890
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.15.2
>Reporter: Simon Delfab
>Assignee: Dhiraj Bokde
>
> The maven plugin is failing to generate the DTOs. It appears that Salesforce
> has recently introduced a new boolean field call encrypted to the
> 'DescribeSObjectResult' object [1,2]
> The fix is to modify the
> org.apache.camel.component.salesforce.api.dto.SObjectField and add the
> following:
> private Boolean encrypted;
>public Boolean getEncrypted() {
> return encrypted;
> }
> public void setEncrypted(Boolean encrypted) {
> this.encrypted = encrypted;
> }
> With this change the DTOs are generated. However, not sure if there is
> anything else which needs to be done.
> Btw, I am surprised that this new field causes a problem because the default
> API version Camel-Salesforce is configured to is 33.0 and this new field
> appears in 34.0.
> [1]
> https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_describesobjects_describesobjectresult.htm#topic-title
> [2]
> http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_platform_encryption.htm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
