[jira] [Work started] (CAMEL-7274) Support roles in the camel-shiro component
[ https://issues.apache.org/jira/browse/CAMEL-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-7274 started by Raul Kripalani. Support roles in the camel-shiro component -- Key: CAMEL-7274 URL: https://issues.apache.org/jira/browse/CAMEL-7274 Project: Camel Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Raul Kripalani Fix For: 2.13.0 Attachments: camel-7274.patch The Camel-shiro component allows the ability to perform authorization based on permissions. However, it does not allow using straight-forward roles for authorization. While using permissions is more flexible, we should also support authorization using roles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7274) Support roles in the camel-shiro component
[ https://issues.apache.org/jira/browse/CAMEL-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-7274. --- Resolution: Fixed Patch applied on master (2.13.x) with thanks to [~coheigea]. Support roles in the camel-shiro component -- Key: CAMEL-7274 URL: https://issues.apache.org/jira/browse/CAMEL-7274 Project: Camel Issue Type: Bug Reporter: Colm O hEigeartaigh Assignee: Raul Kripalani Fix For: 2.13.0 Attachments: camel-7274.patch The Camel-shiro component allows the ability to perform authorization based on permissions. However, it does not allow using straight-forward roles for authorization. While using permissions is more flexible, we should also support authorization using roles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7274) Support roles in the camel-shiro component
[ https://issues.apache.org/jira/browse/CAMEL-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani updated CAMEL-7274: -- Component/s: camel-shiro Support roles in the camel-shiro component -- Key: CAMEL-7274 URL: https://issues.apache.org/jira/browse/CAMEL-7274 Project: Camel Issue Type: Bug Components: camel-shiro Reporter: Colm O hEigeartaigh Assignee: Raul Kripalani Fix For: 2.13.0 Attachments: camel-7274.patch The Camel-shiro component allows the ability to perform authorization based on permissions. However, it does not allow using straight-forward roles for authorization. While using permissions is more flexible, we should also support authorization using roles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7270) New ListAggregationStrategy
[ https://issues.apache.org/jira/browse/CAMEL-7270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920324#comment-13920324 ] Raul Kripalani commented on CAMEL-7270: --- Hi [~jan], Thanks for the contribution. However, this is already possible with the FlexibleAggregationStrategy. Take a look at https://github.com/apache/camel/blob/8ace0ebc09287a9d84f008d546ef87ce4eaa7dc0/camel-core/src/test/java/org/apache/camel/util/toolbox/FlexibleAggregationStrategiesTest.java#L271. Documentation on Wiki is needed. Regards, Raúl. New ListAggregationStrategy --- Key: CAMEL-7270 URL: https://issues.apache.org/jira/browse/CAMEL-7270 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Jan Matèrne Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CAMEL-7258) org.apache.camel.model.dataformat.XmlJsonDataFormat settings assignments are misplaced.
[ https://issues.apache.org/jira/browse/CAMEL-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani reassigned CAMEL-7258: - Assignee: Raul Kripalani org.apache.camel.model.dataformat.XmlJsonDataFormat settings assignments are misplaced. --- Key: CAMEL-7258 URL: https://issues.apache.org/jira/browse/CAMEL-7258 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.12.2, 2.12.3 Environment: Any Reporter: Alexander Lomov Assignee: Raul Kripalani Priority: Minor Labels: patch Fix For: 2.12.4, 2.13.0 elementName value is assigned to encoding field, arrayName is assigned to elementName field when using XmlJsonDataFormat(MapString, String options) constructor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7258) org.apache.camel.model.dataformat.XmlJsonDataFormat settings assignments are misplaced.
[ https://issues.apache.org/jira/browse/CAMEL-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13916228#comment-13916228 ] Raul Kripalani commented on CAMEL-7258: --- Also added 2 unit tests for JSON arrays marshalling and unmarshalling. org.apache.camel.model.dataformat.XmlJsonDataFormat settings assignments are misplaced. --- Key: CAMEL-7258 URL: https://issues.apache.org/jira/browse/CAMEL-7258 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.12.2, 2.12.3 Environment: Any Reporter: Alexander Lomov Assignee: Raul Kripalani Priority: Minor Labels: patch Fix For: 2.12.4, 2.13.0, 2.11.5 elementName value is assigned to encoding field, arrayName is assigned to elementName field when using XmlJsonDataFormat(MapString, String options) constructor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CAMEL-7258) org.apache.camel.model.dataformat.XmlJsonDataFormat settings assignments are misplaced.
[ https://issues.apache.org/jira/browse/CAMEL-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-7258. --- Resolution: Fixed Fix Version/s: 2.11.5 org.apache.camel.model.dataformat.XmlJsonDataFormat settings assignments are misplaced. --- Key: CAMEL-7258 URL: https://issues.apache.org/jira/browse/CAMEL-7258 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.12.2, 2.12.3 Environment: Any Reporter: Alexander Lomov Assignee: Raul Kripalani Priority: Minor Labels: patch Fix For: 2.12.4, 2.13.0, 2.11.5 elementName value is assigned to encoding field, arrayName is assigned to elementName field when using XmlJsonDataFormat(MapString, String options) constructor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7196) [cxfrs] Consumer don't set exchange header from query (like camel-jetty does)
[ https://issues.apache.org/jira/browse/CAMEL-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914451#comment-13914451 ] Raul Kripalani commented on CAMEL-7196: --- [~sergeyb] - AFAIK all the default binding does is chuck the MessageContentsList into the body and set a number of additional headers, none of which are the JAX-RS \@...Params from the JAX-RS method signature. Take a look at DefaultCxfRsBinding#populateExchangeFromCxfRsRequest. [~amarkevich] - please use the users@camel mailing list for questions. [cxfrs] Consumer don't set exchange header from query (like camel-jetty does) - Key: CAMEL-7196 URL: https://issues.apache.org/jira/browse/CAMEL-7196 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.12.2 Reporter: Alexey Markevich Assignee: Raul Kripalani Attachments: CxfRsConsumerTest.java, camel-7196.zip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7196) [cxfrs] Consumer don't set exchange header from query (like camel-jetty does)
[
https://issues.apache.org/jira/browse/CAMEL-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900545#comment-13900545
]
Raul Kripalani commented on CAMEL-7196:
---
[~amarkevich] – as I said above, use the Simple Consumer Binding Style (link to
documentation above).
If you add this option to the consumer URL: {{bindingStyle=SimpleConsumer}},
your query parameters get mapped as Camel headers.
With this consumer URL:
{code}
from(cxfrs://http://127.0.0.1:8088?resourceClasses=org.apache.camel.bug.ServicebindingStyle=SimpleConsumer;)
{code}
I get the following log statement.:
{code}
[0694806-15] bugINFO Exchange[ExchangePattern:
InOut, BodyType: org.apache.cxf.message.MessageContentsList, Body: value1]
{..., param2=value2, ..., CamelHttpQuery=param1=value1param2=value2, ...,
param1=value1, ...}
{code}
As you can see, the headers are there.
Regards,
Raúl.
[cxfrs] Consumer don't set exchange header from query (like camel-jetty does)
-
Key: CAMEL-7196
URL: https://issues.apache.org/jira/browse/CAMEL-7196
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.12.2
Reporter: Alexey Markevich
Attachments: CxfRsConsumerTest.java, camel-7196.zip
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CAMEL-7196) [cxfrs] Consumer don't set exchange header from query (like camel-jetty does)
[ https://issues.apache.org/jira/browse/CAMEL-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-7196. --- Resolution: Cannot Reproduce Assignee: Raul Kripalani [cxfrs] Consumer don't set exchange header from query (like camel-jetty does) - Key: CAMEL-7196 URL: https://issues.apache.org/jira/browse/CAMEL-7196 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.12.2 Reporter: Alexey Markevich Assignee: Raul Kripalani Attachments: CxfRsConsumerTest.java, camel-7196.zip -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7196) [cxfrs] Consumer don't set exchange header from query (like camel-jetty does)
[ https://issues.apache.org/jira/browse/CAMEL-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899019#comment-13899019 ] Raul Kripalani commented on CAMEL-7196: --- [~amarkevich] - did you try using the Simple Consumer binding style of Camel CXFRS? See http://camel.apache.org/cxfrs.html#CXFRS-ConsumingaRESTRequest-SimpleBindingStyle. [cxfrs] Consumer don't set exchange header from query (like camel-jetty does) - Key: CAMEL-7196 URL: https://issues.apache.org/jira/browse/CAMEL-7196 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.12.2 Reporter: Alexey Markevich Attachments: CxfRsConsumerTest.java -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7196) [cxfrs] Consumer don't set exchange header from query (like camel-jetty does)
[ https://issues.apache.org/jira/browse/CAMEL-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899033#comment-13899033 ] Raul Kripalani commented on CAMEL-7196: --- [~amarkevich] - can you post your test code using the Simple Consumer binding style, please? The one you attached doesn't use it. Thanks. [cxfrs] Consumer don't set exchange header from query (like camel-jetty does) - Key: CAMEL-7196 URL: https://issues.apache.org/jira/browse/CAMEL-7196 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.12.2 Reporter: Alexey Markevich Attachments: CxfRsConsumerTest.java -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CAMEL-7180) Support multiple onWhen + onOtherwise in onComplete blocks
Raul Kripalani created CAMEL-7180:
-
Summary: 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: Raul Kripalani
Assignee: Raul 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. So 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.1.5#6160)
[jira] [Updated] (CAMEL-7180) Support multiple onWhen + onOtherwise in onComplete blocks
[
https://issues.apache.org/jira/browse/CAMEL-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-7180:
--
Description:
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.
was:
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. So 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.
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: Raul Kripalani
Assignee: Raul 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.1.5#6160)
[jira] [Commented] (CAMEL-6694) Make Log component and EIP compatible with log4j MDC Sift Appender
[ https://issues.apache.org/jira/browse/CAMEL-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827142#comment-13827142 ] Raul Kripalani commented on CAMEL-6694: --- [~hadrian] - yes. I'm trying to get it ready for 2.12.2. I've been snowed under with work these days. Do we have a ballpark for a release date? Make Log component and EIP compatible with log4j MDC Sift Appender -- Key: CAMEL-6694 URL: https://issues.apache.org/jira/browse/CAMEL-6694 Project: Camel Issue Type: Bug Affects Versions: 2.12.0 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.12.2, 2.13.0 Refer to http://camel.465427.n5.nabble.com/Logging-into-the-bundle-log-file-via-to-log-tp5738205p5738413.html for more info. We should use the Camel Context's Classloader to initialize the Logger instance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6950) camel-sjms: Lacks reconnection logic in case of exception
Raul Kripalani created CAMEL-6950: - Summary: camel-sjms: Lacks reconnection logic in case of exception Key: CAMEL-6950 URL: https://issues.apache.org/jira/browse/CAMEL-6950 Project: Camel Issue Type: Bug Components: camel-sjms Affects Versions: 2.12.1 Reporter: Raul Kripalani Assignee: Raul Kripalani See this thread: http://camel.465427.n5.nabble.com/SJMS-failure-with-stale-reply-queue-tp5742833.html. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6838) JMX Notification Trace Event Handler has no implementation for traceExchangeIn and traceExchangeOut
Raul Kripalani created CAMEL-6838: - Summary: JMX Notification Trace Event Handler has no implementation for traceExchangeIn and traceExchangeOut Key: CAMEL-6838 URL: https://issues.apache.org/jira/browse/CAMEL-6838 Project: Camel Issue Type: Bug Affects Versions: 2.12.1 Reporter: Raul Kripalani Assignee: Raul Kripalani Priority: Minor Fix For: 2.12.2, 2.13.0 This leads to absolutely no JMX Notifications being recorded when the Tracer's traceOutExchanges option is enabled. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6831) Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4)
[ https://issues.apache.org/jira/browse/CAMEL-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788648#comment-13788648 ] Raul Kripalani commented on CAMEL-6831: --- Hey Christian, Thanks for the report. Looking into it! Regards, Raúl. Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4) - Key: CAMEL-6831 URL: https://issues.apache.org/jira/browse/CAMEL-6831 Project: Camel Issue Type: Task Components: camel-http4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6806) Upgrade org.apache.httpcomponents to 4.3
[ https://issues.apache.org/jira/browse/CAMEL-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6806. --- Resolution: Fixed Fixed in commit 3e2dedf by upgrading to Apache HTTP Client 4.3.1 which was just released today, including the fixes for HTTPCLIENT-1398 and HTTPCLIENT-1400. Upgrade org.apache.httpcomponents to 4.3 Key: CAMEL-6806 URL: https://issues.apache.org/jira/browse/CAMEL-6806 Project: Camel Issue Type: Task Components: camel-aws, camel-couchdb, camel-http4, camel-solr Affects Versions: 2.12.1 Reporter: Christian Müller Assignee: Christian Müller Priority: Minor Fix For: 2.13.0 Attachments: CAMEL-6806.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6831) Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4)
[ https://issues.apache.org/jira/browse/CAMEL-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6831. --- Resolution: Fixed Fixed in commit 3e2dedf by upgrading to Apache HTTP Client 4.3.1 which was just released today, including the fixes for HTTPCLIENT-1398 and HTTPCLIENT-1400. Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4) - Key: CAMEL-6831 URL: https://issues.apache.org/jira/browse/CAMEL-6831 Project: Camel Issue Type: Task Components: camel-http4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Work started] (CAMEL-6831) Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4)
[ https://issues.apache.org/jira/browse/CAMEL-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-6831 started by Raul Kripalani. Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4) - Key: CAMEL-6831 URL: https://issues.apache.org/jira/browse/CAMEL-6831 Project: Camel Issue Type: Task Components: camel-http4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6831) Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4)
Raul Kripalani created CAMEL-6831: - Summary: Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4) Key: CAMEL-6831 URL: https://issues.apache.org/jira/browse/CAMEL-6831 Project: Camel Issue Type: Task Components: camel-http4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CAMEL-6831) Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4)
[ https://issues.apache.org/jira/browse/CAMEL-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6831. --- Resolution: Fixed Upgrade Apache HTTP Client 4.2.5 to 4.3 (camel-http4) - Key: CAMEL-6831 URL: https://issues.apache.org/jira/browse/CAMEL-6831 Project: Camel Issue Type: Task Components: camel-http4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.13.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6802) Using stopOnException in splitter should not copy result back as we should preserve original exchange
[ https://issues.apache.org/jira/browse/CAMEL-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781751#comment-13781751 ] Raul Kripalani commented on CAMEL-6802: --- Hey Claus, For me, this is not a black or white situation. When an exception occurs with stopOnException, it understandable that the user may require the (partial) aggregation result as an output + the appropriate Exception set on the exchange. That way, they get the best of both worlds: (1) knowing that an Exception happened (and triggering any error handlers as a consequence) and (2) the output of the aggregation so far. Perhaps we could introduce an option 'exchangeOnException' taking the values 'original' and 'aggregated_partial'? Regards, Raúl. Using stopOnException in splitter should not copy result back as we should preserve original exchange - Key: CAMEL-6802 URL: https://issues.apache.org/jira/browse/CAMEL-6802 Project: Camel Issue Type: Bug Components: camel-core, eip Affects Versions: 2.11.2, 2.12.1 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.11.3, 2.12.2, 2.13.0 If you use stopOnException on splitter then when an exception occurs then changes to eg exchange.properties should not override the input exchange, as that would not be expected. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-6466) Log component URI parameters should be able to override custom formatter properties
[
https://issues.apache.org/jira/browse/CAMEL-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759018#comment-13759018
]
Raul Kripalani commented on CAMEL-6466:
---
Hi,
Making the log formatter mutable is okay if you use the convention over
configuration path, i.e. you define the logFormatter in the Spring registry
and mark it with scope=prototype – as Spring hands out a new instance every
time it's requested.
But take into account that the logFormatter can also be injected into the
LogComponent as a standard bean property, and in this case it needs to be
immutable as it will be shared across all log endpoints...
So perhaps we should (a) clone the LogFormatter when creating a new endpoint or
(b) remove the exchangeFormatter from the component level and push it down to
the endpoint level...
Regards,
Raúl.
Log component URI parameters should be able to override custom formatter
properties
---
Key: CAMEL-6466
URL: https://issues.apache.org/jira/browse/CAMEL-6466
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.11.0
Reporter: Nathan Jensen
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.11.2, 2.12.0
Our project uses a custom log formatter of type
org.apache.camel.component.log.LogFormatter, the only difference is we have
changed the defaults from camel's standard defaults. Unfortunately, by
registering a custom formatter we can no longer have a route specifically
diverge from the system wide formatter for special cases.
For example, the following works when we don't have a custom formatter but
fails when do have a custom formatter:
touri=log:pluginName?level=ERRORamp;showBody=falseamp;showCaughtException=trueamp;showStackTrace=true/
It fails with a FailedToCreateRouteException with the message There are 3
parameters that couldn't be set on the endpoint. Check the uri if the
parameters are spelt correctly and that they are properties of the endpoint.
Unknown parameters=[{showBody=false, showCaughtException=true,
showStackTrace=true}].
The root of the problem is that the logic in LogComponent.createEndpoint()
only sets the URI parameters on the localFormatter if there is no custom
formatter already registered, otherwise it tries to set the parameters on the
endpoint itself and not the formatter.
It would be nice if the log route URIs were able to override parameters on
the custom formatter for routes that need special cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757339#comment-13757339
]
Raul Kripalani commented on CAMEL-6648:
---
Looks promising! I'll take a look as soon as I get a chance. Thanks for
contributing.
On 3 Sep 2013 08:19, Jan Matèrne (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Jan Matèrne updated CAMEL-6648:
---
Attachment: CAMEL-6648.zip
I worked further on this and did a rework:
1. Instead of only focussing of a *ProducerTemplate I thought, that Claus
wants to have an API that allows the communication with Camel. So I thought
of a a building dealing with that whole communication.
2. While writing I thought it would be good to have more options to a build
the body. Finally this ends in a BodyBuilder (and I lought after appending
the object to build (body) and the name of the pattern (builder) ;)
3. While more thinking about the BodyBuilder I refactored that for use of
its own (and better testability).
FluentProducerTemplateTest.java, ProducerTemplateBuilder.java,
ProducerTemplateBuilderTest.java
following manner:
FluentProducerTemplate(activemq:queue:foo);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.13.0
Attachments: CAMEL-6648.zip, FluentProducerTemplate.java,
FluentProducerTemplateTest.java, ProducerTemplateBuilder.java,
ProducerTemplateBuilderTest.java
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6542) Camel Toolbox: Useful Aggregation Strategies
[ https://issues.apache.org/jira/browse/CAMEL-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani updated CAMEL-6542: -- Fix Version/s: (was: 2.12.1) 2.12.0 Summary: Camel Toolbox: Useful Aggregation Strategies (was: Camel Toolbox: Useful AggregationStrategies, OnPrepare processors, etc.) Camel Toolbox: Useful Aggregation Strategies Key: CAMEL-6542 URL: https://issues.apache.org/jira/browse/CAMEL-6542 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.12.0 Camel is a highly pluggable and configurable framework that allows you inject custom logic at many points along the route, e.g. Aggregation Strategies, On Prepare strategies, Exchange Notifiers, etc. We provide the interfaces for developers to implement, but we hardly supply any out-of-the-box strategies for common use cases. Let's be collectively [DRY|http://en.wikipedia.org/wiki/Don't_repeat_yourself], and provide a series of Camel Toolbox utility clases to cover typical use cases. For example: *Class AggregationStrategies:* - storeInProperty(String propertyName) - storeInProperty(String propertyName, Class? castAs) - accumulateBodiesInList() - accumulateBodiesInList(Class? listType) - filterIncoming(AggregationStrategy aggregationStrategy) - ... (Processors, OnPrepareProcessors, etc.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6542) Camel Toolbox: Useful Aggregation Strategies
[ https://issues.apache.org/jira/browse/CAMEL-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754543#comment-13754543 ] Raul Kripalani commented on CAMEL-6542: --- Documentation on the way! Camel Toolbox: Useful Aggregation Strategies Key: CAMEL-6542 URL: https://issues.apache.org/jira/browse/CAMEL-6542 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.12.0 Camel is a highly pluggable and configurable framework that allows you inject custom logic at many points along the route, e.g. Aggregation Strategies, On Prepare strategies, Exchange Notifiers, etc. We provide the interfaces for developers to implement, but we hardly supply any out-of-the-box strategies for common use cases. Let's be collectively [DRY|http://en.wikipedia.org/wiki/Don't_repeat_yourself], and provide a series of Camel Toolbox utility clases to cover typical use cases. For example: *Class AggregationStrategies:* - storeInProperty(String propertyName) - storeInProperty(String propertyName, Class? castAs) - accumulateBodiesInList() - accumulateBodiesInList(Class? listType) - filterIncoming(AggregationStrategy aggregationStrategy) - ... (Processors, OnPrepareProcessors, etc.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6542) Camel Toolbox: Useful Aggregation Strategies
[ https://issues.apache.org/jira/browse/CAMEL-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6542. --- Resolution: Fixed Camel Toolbox: Useful Aggregation Strategies Key: CAMEL-6542 URL: https://issues.apache.org/jira/browse/CAMEL-6542 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.12.0 Camel is a highly pluggable and configurable framework that allows you inject custom logic at many points along the route, e.g. Aggregation Strategies, On Prepare strategies, Exchange Notifiers, etc. We provide the interfaces for developers to implement, but we hardly supply any out-of-the-box strategies for common use cases. Let's be collectively [DRY|http://en.wikipedia.org/wiki/Don't_repeat_yourself], and provide a series of Camel Toolbox utility clases to cover typical use cases. For example: *Class AggregationStrategies:* - storeInProperty(String propertyName) - storeInProperty(String propertyName, Class? castAs) - accumulateBodiesInList() - accumulateBodiesInList(Class? listType) - filterIncoming(AggregationStrategy aggregationStrategy) - ... (Processors, OnPrepareProcessors, etc.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749950#comment-13749950
]
Raul Kripalani commented on CAMEL-6648:
---
[~jhm] – perfect! Give it a go and let me know if you need help. I'll try to
check into #camel these days.
In terms of the asyncStyle/request/send/inOut/etc. methods, in my head there
are only two actions: request and send, whereas asyncStyle is a modifier or
switch.
However, at this point I also agree with you both, [~davsclaus] [~jhm], we
should keep it as simple and familiar as possible in this first implementation.
So let's use asyncSend, send and request for the method names that trigger the
dispatch.
Regarding Futures, they are useful when doing complex routing from within a
bean inside a Camel route, so I'd like to see them in the 1st implementation.
Also, it would be useful to extend the @EndpointInject annotation so that it
injects a FluentProducerTemplate if the variable is defined with such a type.
Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Attachments: ProducerTemplateBuilder.java,
ProducerTemplateBuilderTest.java
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749629#comment-13749629
]
Raul Kripalani commented on CAMEL-6648:
---
[~jan] - thanks for your great work! I'll take a look today.
Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Attachments: ProducerTemplateBuilder.java,
ProducerTemplateBuilderTest.java
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6667) Loop EIP doesn't honour copy option in some circumstances
Raul Kripalani created CAMEL-6667:
-
Summary: Loop EIP doesn't honour copy option in some circumstances
Key: CAMEL-6667
URL: https://issues.apache.org/jira/browse/CAMEL-6667
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.0
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.12.0
Happens when the Async Routing Engine variant of the Loop logic kicks in, and
there are more than two processors in the loop body, e.g.
\\
\\
{code:java}
.loop(3)
.to(activemq:queue:abc?exchangePattern=InOut)
.to(activemq:queue:def?exchangePattern=InOut)
.end()
{code}
The wrong inflight Exchange is copied (instead of the original one), and since
the implicit Pipeline has copied the OUT message from the 1st endpoint to the
IN message, the original IN message is lost fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-6667) Loop EIP doesn't honour copy option in some circumstances
[
https://issues.apache.org/jira/browse/CAMEL-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-6667 started by Raul Kripalani.
Loop EIP doesn't honour copy option in some circumstances
-
Key: CAMEL-6667
URL: https://issues.apache.org/jira/browse/CAMEL-6667
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.0
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Labels: loop
Fix For: 2.12.0
Happens when the Async Routing Engine variant of the Loop logic kicks in, and
there are more than two processors in the loop body, e.g.
\\
\\
{code:java}
.loop(3)
.to(activemq:queue:abc?exchangePattern=InOut)
.to(activemq:queue:def?exchangePattern=InOut)
.end()
{code}
The wrong inflight Exchange is copied (instead of the original one), and
since the implicit Pipeline has copied the OUT message from the 1st endpoint
to the IN message, the original IN message is lost fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6667) Loop EIP doesn't honour copy option in some circumstances
[
https://issues.apache.org/jira/browse/CAMEL-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-6667.
---
Resolution: Fixed
Fix Version/s: 2.11.2
2.10.7
Loop EIP doesn't honour copy option in some circumstances
-
Key: CAMEL-6667
URL: https://issues.apache.org/jira/browse/CAMEL-6667
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.0
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Labels: loop
Fix For: 2.10.7, 2.11.2, 2.12.0
Happens when the Async Routing Engine variant of the Loop logic kicks in, and
there are more than two processors in the loop body, e.g.
\\
\\
{code:java}
.loop(3)
.to(activemq:queue:abc?exchangePattern=InOut)
.to(activemq:queue:def?exchangePattern=InOut)
.end()
{code}
The wrong inflight Exchange is copied (instead of the original one), and
since the implicit Pipeline has copied the OUT message from the 1st endpoint
to the IN message, the original IN message is lost fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6667) Loop EIP doesn't honour copy option in some circumstances
[
https://issues.apache.org/jira/browse/CAMEL-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-6667.
---
Resolution: Fixed
Fix Version/s: 2.11.2
2.10.7
Loop EIP doesn't honour copy option in some circumstances
-
Key: CAMEL-6667
URL: https://issues.apache.org/jira/browse/CAMEL-6667
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.12.0
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Labels: loop
Fix For: 2.10.7, 2.11.2, 2.12.0
Happens when the Async Routing Engine variant of the Loop logic kicks in, and
there are more than two processors in the loop body, e.g.
\\
\\
{code:java}
.loop(3)
.to(activemq:queue:abc?exchangePattern=InOut)
.to(activemq:queue:def?exchangePattern=InOut)
.end()
{code}
The wrong inflight Exchange is copied (instead of the original one), and
since the implicit Pipeline has copied the OUT message from the 1st endpoint
to the IN message, the original IN message is lost fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749763#comment-13749763
]
Raul Kripalani commented on CAMEL-6648:
---
Hi [~jhm],
I checked out the implementation and IMHO we should go for a second iteration
with a slightly different approach.
A ProducerTemplate instance is designed to be a long-term, thread-safe object:
created once in the application lifetime and reused thereon. However, if I
understood properly, this implementation relies on creating a new
ProducerTemplate for each Exchange sent, which may cause unnecessary overhead.
Rather than creating a builder pattern for the ProducerTemplate (PT), I'd
rather us focus on providing fluency for creating and dispatching new
interactions around an existing PT:
- New FluentProducerTemplate class which wraps a ProducerTemplate inside.
- The implementation is stateless = the newExchange() method returns a new
FluentProducerTemplateInteractionBuilder object extending ExchangeBuilder.
- asyncStyle, dispatchInOut, dispatchInOnly, etc. methods invoke the
appropriate send/request/sendAsync methods in the wrapped PT.
What do you think? I already started working on this, but please do let me know
if you'd like to give it a go yourself.
Regards,
Raúl.
Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Attachments: ProducerTemplateBuilder.java,
ProducerTemplateBuilderTest.java
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749763#comment-13749763
]
Raul Kripalani edited comment on CAMEL-6648 at 8/25/13 11:15 PM:
-
Hi [~jhm],
I checked out the implementation and IMHO we should go for a second iteration
with a slightly different approach.
A ProducerTemplate instance is designed to be a long-term, thread-safe object:
created once in the application lifetime and reused thereon. However, if I
understood properly, this implementation relies on creating a new
ProducerTemplate for each Exchange sent, which may cause unnecessary overhead.
Rather than creating a builder pattern for the ProducerTemplate (PT), I'd
rather us focus on providing fluency for creating and dispatching new
interactions around an existing PT:
- New FluentProducerTemplate class which wraps a ProducerTemplate inside.
- The implementation is stateless = the newExchange() method is a factory for
new FluentProducerTemplateInteractionBuilder objects extending ExchangeBuilder.
The state is maintained in this separate object.
- asyncStyle, dispatchInOut, dispatchInOnly, etc. methods conclude the building
by invoking the appropriate send/request/sendAsync methods in the wrapped PT,
passing in the generated Exchange.
What do you think? I already started working on this, but please do let me know
if you'd like to give it a go yourself.
Regards,
Raúl.
was (Author: raulvk):
Hi [~jhm],
I checked out the implementation and IMHO we should go for a second iteration
with a slightly different approach.
A ProducerTemplate instance is designed to be a long-term, thread-safe object:
created once in the application lifetime and reused thereon. However, if I
understood properly, this implementation relies on creating a new
ProducerTemplate for each Exchange sent, which may cause unnecessary overhead.
Rather than creating a builder pattern for the ProducerTemplate (PT), I'd
rather us focus on providing fluency for creating and dispatching new
interactions around an existing PT:
- New FluentProducerTemplate class which wraps a ProducerTemplate inside.
- The implementation is stateless = the newExchange() method returns a new
FluentProducerTemplateInteractionBuilder object extending ExchangeBuilder.
- asyncStyle, dispatchInOut, dispatchInOnly, etc. methods invoke the
appropriate send/request/sendAsync methods in the wrapped PT.
What do you think? I already started working on this, but please do let me know
if you'd like to give it a go yourself.
Regards,
Raúl.
Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Attachments: ProducerTemplateBuilder.java,
ProducerTemplateBuilderTest.java
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6228) CXFRS: Consumer - Inject Resource instance into message
[ https://issues.apache.org/jira/browse/CAMEL-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13743361#comment-13743361 ] Raul Kripalani commented on CAMEL-6228: --- Looking into it. CXFRS: Consumer - Inject Resource instance into message --- Key: CAMEL-6228 URL: https://issues.apache.org/jira/browse/CAMEL-6228 Project: Camel Issue Type: Improvement Components: camel-cxf Affects Versions: 2.10.4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.12.0 CxfRsInvoker#asyncInvoke and CxfRsInvoker#syncInvoke forsake the Service Object. Instead it should be passed on to the CxfRsBinding. Will try and fix for 2.11 as it implies API changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6646) Support static method calls on OGNL expressions
Raul Kripalani created CAMEL-6646:
-
Summary: Support static method calls on OGNL expressions
Key: CAMEL-6646
URL: https://issues.apache.org/jira/browse/CAMEL-6646
Project: Camel
Issue Type: Improvement
Components: camel-ognl
Reporter: Raul Kripalani
Assignee: Raul Kripalani
In OgnlInvokeProcessor, we currently don't support static method calls as we
always require a bean instance.
See this block of code in 2.10.3, starting on OgnlInvokeProcessor:247:
{code}
// loop and invoke each method
Object beanToCall = beanHolder.getBean();
// there must be a bean to call with, we currently does not support OGNL
expressions on using purely static methods
if (beanToCall == null) {
throw new IllegalArgumentException(Bean instance is null. OGNL bean
expressions requires bean instances.);
}
{code}
Add support for these cases, especially handy if you use the method()
expression frequently.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6647) LevelDb Aggregation Repository: add support for persisting user properties
Raul Kripalani created CAMEL-6647:
-
Summary: LevelDb Aggregation Repository: add support for
persisting user properties
Key: CAMEL-6647
URL: https://issues.apache.org/jira/browse/CAMEL-6647
Project: Camel
Issue Type: Improvement
Components: camel-leveldb
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Currently, only a limited number of control properties relevant to the
Aggregator EIP are stored. Extend the {{LevelDbCamelCodec}} to allow storing
user-specified properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6648) Create a Fluent ProducerTemplate
Raul Kripalani created CAMEL-6648:
-
Summary: Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader1, HeaderValue)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-6648:
--
Description:
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
was:
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader1, HeaderValue)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
Create a Fluent ProducerTemplate
Key: CAMEL-6648
URL: https://issues.apache.org/jira/browse/CAMEL-6648
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Create a Fluent ProducerTemplate so that users can use it in the following
manner:
\\
\\
{code}
// initialize ProducerTemplate with a default endpoint
FluentProducerTemplate template = new
FluentProducerTemplate(activemq:queue:foo);
MyResponse response =
template.newExchange().toDefaultEndpoint()
.withBody(this is slick)
.withHeader(MyHeader1, HeaderValue)
.withHeader(MyHeader2, HeaderValue2)
.resultAs(MyResponse.class)
.dispatchInOut(); // or inOnly(), asyncInOut()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6528) Upgrade net.sf.saxon:Saxon-HE to 9.5.0.2
[ https://issues.apache.org/jira/browse/CAMEL-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703617#comment-13703617 ] Raul Kripalani commented on CAMEL-6528: --- Nice one, [~muellerc]! Upgrade net.sf.saxon:Saxon-HE to 9.5.0.2 Key: CAMEL-6528 URL: https://issues.apache.org/jira/browse/CAMEL-6528 Project: Camel Issue Type: Task Components: camel-saxon Affects Versions: 2.11.0 Reporter: Christian Müller Assignee: Christian Müller Priority: Minor Fix For: 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6515) camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2
[ https://issues.apache.org/jira/browse/CAMEL-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701880#comment-13701880 ] Raul Kripalani commented on CAMEL-6515: --- [~bvahdat] – many thanks ;-) 2.12 release notes updated. We were 2 minor versions behind and as a result Camel wasn't able to leverage security features introduced in newer versions of MongoDB which are vital in enterprise environments. The NPE from the driver is not offensive, it simply isn't a nice exception for an API to throw. An InterruptedException or similar would be less misleading (https://jira.mongodb.org/browse/JAVA-605), but I'm not sure it has much priority on their side as the ticket is 10 months old now. Holding off on our side wouldn't have benefitted our users. Regards, Raúl. camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2 -- Key: CAMEL-6515 URL: https://issues.apache.org/jira/browse/CAMEL-6515 Project: Camel Issue Type: Improvement Components: camel-mongodb Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.7, 2.11.1, 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6515) camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2
Raul Kripalani created CAMEL-6515: - Summary: camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2 Key: CAMEL-6515 URL: https://issues.apache.org/jira/browse/CAMEL-6515 Project: Camel Issue Type: Improvement Components: camel-mongodb Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.7, 2.11.2, 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6507) Add aggregat ability to camel_mongodb
[
https://issues.apache.org/jira/browse/CAMEL-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani reassigned CAMEL-6507:
-
Assignee: Raul Kripalani (was: Willem Jiang)
Add aggregat ability to camel_mongodb
-
Key: CAMEL-6507
URL: https://issues.apache.org/jira/browse/CAMEL-6507
Project: Camel
Issue Type: New Feature
Components: camel-mongodb
Affects Versions: 2.11.0
Reporter: Pierre-Alban DEWITTE
Assignee: Raul Kripalani
Labels: patch
Fix For: 2.10.7, 2.11.1, 2.12.0
Hi,
I just add the ability to use aggregat in camel-mongo-db route.
Now you can declare a route to aggregate :
from(...).to(mongodb:myDb?database=testcollection=testoperation=aggregatdynamicity=true);
The body should contain a valid Mongo pipeline for example { $match : {name
: my product}},{ $group: { _id: $name ,total: { $sum: $price } } }
P-Alban
PS : I just create a pull request on github
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6507) Add aggregat ability to camel_mongodb
[
https://issues.apache.org/jira/browse/CAMEL-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-6507:
--
Fix Version/s: 2.12.0
2.11.1
2.10.7
Add aggregat ability to camel_mongodb
-
Key: CAMEL-6507
URL: https://issues.apache.org/jira/browse/CAMEL-6507
Project: Camel
Issue Type: New Feature
Components: camel-mongodb
Affects Versions: 2.11.0
Reporter: Pierre-Alban DEWITTE
Assignee: Willem Jiang
Labels: patch
Fix For: 2.10.7, 2.11.1, 2.12.0
Hi,
I just add the ability to use aggregat in camel-mongo-db route.
Now you can declare a route to aggregate :
from(...).to(mongodb:myDb?database=testcollection=testoperation=aggregatdynamicity=true);
The body should contain a valid Mongo pipeline for example { $match : {name
: my product}},{ $group: { _id: $name ,total: { $sum: $price } } }
P-Alban
PS : I just create a pull request on github
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6507) Add aggregate ability to camel-mongodb
[
https://issues.apache.org/jira/browse/CAMEL-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-6507:
--
Summary: Add aggregate ability to camel-mongodb (was: Add aggregat ability
to camel_mongodb)
Backported to 2.10 and 2.11 branches.
Add aggregate ability to camel-mongodb
--
Key: CAMEL-6507
URL: https://issues.apache.org/jira/browse/CAMEL-6507
Project: Camel
Issue Type: New Feature
Components: camel-mongodb
Affects Versions: 2.11.0
Reporter: Pierre-Alban DEWITTE
Assignee: Raul Kripalani
Labels: patch
Fix For: 2.10.7, 2.11.1, 2.12.0
Hi,
I just add the ability to use aggregat in camel-mongo-db route.
Now you can declare a route to aggregate :
from(...).to(mongodb:myDb?database=testcollection=testoperation=aggregatdynamicity=true);
The body should contain a valid Mongo pipeline for example { $match : {name
: my product}},{ $group: { _id: $name ,total: { $sum: $price } } }
P-Alban
PS : I just create a pull request on github
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6515) camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2
[ https://issues.apache.org/jira/browse/CAMEL-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6515. --- Resolution: Fixed Fix Version/s: (was: 2.11.2) 2.11.1 Upgraded in trunk (2.12) and 2.11.x and 2.10.x branches. camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2 -- Key: CAMEL-6515 URL: https://issues.apache.org/jira/browse/CAMEL-6515 Project: Camel Issue Type: Improvement Components: camel-mongodb Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.7, 2.11.1, 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6515) camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2
[ https://issues.apache.org/jira/browse/CAMEL-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701696#comment-13701696 ] Raul Kripalani commented on CAMEL-6515: --- [~muellerc] - Sorry, I only just saw your comment now! We can revert the change on 2.10.x and 2.11.x if needed. But I think this upgrade will be welcome as it allows Camel to interact with higher versions of MongoDB and to use the new security features in MongoDB 2.4. My opinion is that upgrading drivers is generally OK – as they are just lightweight elements that simply provide a connection layer. A different story would be to upgrade a library that incorporates/embeds functionality into Camel (e.g. Saxon, Jackson, Spring, etc.). Those upgrades can be more harmful and we should control them more tightly as you outlined above, IMHO. camel-mongodb: Upgrade MongoDB driver from 2.9.1 to 2.11.2 -- Key: CAMEL-6515 URL: https://issues.apache.org/jira/browse/CAMEL-6515 Project: Camel Issue Type: Improvement Components: camel-mongodb Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.7, 2.11.1, 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6507) Add aggregat ability to camel_mongodb
[
https://issues.apache.org/jira/browse/CAMEL-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701090#comment-13701090
]
Raul Kripalani commented on CAMEL-6507:
---
[~padewitte] – You can edit the Wiki page here:
https://cwiki.apache.org/confluence/display/CAMEL/MongoDB.
To be granted Wiki Edit karma, please read the instructions here:
http://camel.apache.org/contributing.html.
Thanks a lot for your contribution, it's really appreciated!
Add aggregat ability to camel_mongodb
-
Key: CAMEL-6507
URL: https://issues.apache.org/jira/browse/CAMEL-6507
Project: Camel
Issue Type: New Feature
Components: camel-mongodb
Affects Versions: 2.11.0
Reporter: Pierre-Alban DEWITTE
Assignee: Willem Jiang
Labels: patch
Hi,
I just add the ability to use aggregat in camel-mongo-db route.
Now you can declare a route to aggregate :
from(...).to(mongodb:myDb?database=testcollection=testoperation=aggregatdynamicity=true);
The body should contain a valid Mongo pipeline for example { $match : {name
: my product}},{ $group: { _id: $name ,total: { $sum: $price } } }
P-Alban
PS : I just create a pull request on github
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CAMEL-6507) Add aggregat ability to camel_mongodb
[
https://issues.apache.org/jira/browse/CAMEL-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani reopened CAMEL-6507:
---
Hi Willem,
If you have time, could you change the operation name to 'aggregate'?
It appears as 'aggregat' everywhere – it seems to be a typo that crept into the
source.
Many thanks,
Raúl.
Add aggregat ability to camel_mongodb
-
Key: CAMEL-6507
URL: https://issues.apache.org/jira/browse/CAMEL-6507
Project: Camel
Issue Type: New Feature
Components: camel-mongodb
Affects Versions: 2.11.0
Reporter: Pierre-Alban DEWITTE
Assignee: Willem Jiang
Labels: patch
Hi,
I just add the ability to use aggregat in camel-mongo-db route.
Now you can declare a route to aggregate :
from(...).to(mongodb:myDb?database=testcollection=testoperation=aggregatdynamicity=true);
The body should contain a valid Mongo pipeline for example { $match : {name
: my product}},{ $group: { _id: $name ,total: { $sum: $price } } }
P-Alban
PS : I just create a pull request on github
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6486) Upgrade camel-bean-validator to JSR349 (Bean Validation 1.1)
[
https://issues.apache.org/jira/browse/CAMEL-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-6486:
--
Fix Version/s: (was: 2.10.5)
2.10.6
Removed 2.10.5 from fix version, as release vote is taking place already.
Upgrade camel-bean-validator to JSR349 (Bean Validation 1.1)
Key: CAMEL-6486
URL: https://issues.apache.org/jira/browse/CAMEL-6486
Project: Camel
Issue Type: Bug
Affects Versions: 2.10.4, 2.11.0
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.6, 2.11.1, 2.12.0
SMX bundle no longer necessary as version 1.1 of the API seems to carry OSGi
exports:
{code}
karaf@root install -s mvn:javax.validation/validation-api/1.1.0.Final
Bundle ID: 254
karaf@root exports 254
ID Packages
254 javax.validation.groups; version=1.1.0.Final
254 javax.validation.metadata; version=1.1.0.Final
254 javax.validation; version=1.1.0.Final
254 javax.validation.executable; version=1.1.0.Final
254 javax.validation.constraintvalidation; version=1.1.0.Final
254 javax.validation.spi; version=1.1.0.Final
254 javax.validation.bootstrap; version=1.1.0.Final
254 javax.validation.constraints; version=1.1.0.Final
karaf@root
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6377) Optimize routing engine to reduce stack frames in use during routing and reduce callbacks
[ https://issues.apache.org/jira/browse/CAMEL-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13663960#comment-13663960 ] Raul Kripalani commented on CAMEL-6377: --- After syncing up with [~davsclaus] on IRC, I'll contribute to the following tasks from the to-do list above: 1-3, 7. Additional places where to hunt for wrapping: - Policy / Transaction Definition - Inline processors are currently wrapped in WrapProcessor for JMX registration. Can be optimised by offering an abstract ProcessorSupport class for processors to extend. - EIP processors that wrap logic in a UnitOfWorkProcessor: Wire Tap, Aggregator, Splitter, etc. Optimisable. Optimize routing engine to reduce stack frames in use during routing and reduce callbacks - Key: CAMEL-6377 URL: https://issues.apache.org/jira/browse/CAMEL-6377 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.12.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.0 We can optimize the Camel routing engine internally, and redue the need for wrapping processors (those internally used for cross cutting functionality) where they would wrap each other one by one; which then results in larger call stacks during routing. This also shows to end users when stacktraces is being logged etc, as they tend to be a bit longer with many internal calls. Though the JVM optimizes this at runtime as it can inline the calls and whatnot. But the stacktraces is still shown expanded. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6218) TransferExchage InOut ActiveMQ Exception
[
https://issues.apache.org/jira/browse/CAMEL-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani reassigned CAMEL-6218:
-
Assignee: Raul Kripalani
TransferExchage InOut ActiveMQ Exception
Key: CAMEL-6218
URL: https://issues.apache.org/jira/browse/CAMEL-6218
Project: Camel
Issue Type: Bug
Affects Versions: 2.10.4
Reporter: Alan Foster
Assignee: Raul Kripalani
Fix For: 2.11.0
Attachments: camel-6214-transferExchange.java,
camel-6218-test-project.rar, org.apache.cmueller.camel.zip
The scnearios are :
- when using the transferExchange option only on the producer, I don't
get the body back, but not the header.
- When I use the transferExchange option on both producer and consumer, I
get the headers back, but not the body. And instead I get the following
exception
{code:java}
[ryQueueReplyManager[temporary]] TemporaryQueueReplyManager WARN
Execution of JMS message listener failed. Caused by:
[java.lang.NullPointerException - null]
java.lang.NullPointerException
at
org.apache.camel.impl.DefaultExchangeHolder.unmarshal(DefaultExchangeHolder.java:107)
at
org.apache.camel.component.jms.JmsBinding.extractBodyFromJms(JmsBinding.java:128)
at
org.apache.camel.component.jms.JmsMessage.createBody(JmsMessage.java:214)
at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:41)
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.processReply(ReplyManagerSupport.java:136)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyHandler.onReply(TemporaryQueueReplyHandler.java:54)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyManager.handleReplyMessage(TemporaryQueueReplyManager.java:71)
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.onMessage(ReplyManagerSupport.java:113)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:560)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:498)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:662)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6218) TransferExchage InOut ActiveMQ Exception
[
https://issues.apache.org/jira/browse/CAMEL-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-6218.
---
Resolution: Fixed
Resolved in r1463799.
The JmsBinding is designed to be pull-based, but the Exchange = OUT Message
relationship was being set too late: after invoking the JmsBinding. Therefore,
the latter wasn't able to populate body, headers and properties from the
DefaultExchangeHolder in time.
As a side-effect, we now also set the OUT message when the
{{transferException}} option is enabled (aside from also setting the Exception,
of course). Before we only used to set the exception, but it's a chicken-or-egg
situation to be honest.
This is harmless – and even better than before if you ask me – because now
there's more context information in the Exchange. All JMS tests pass locally.
TransferExchage InOut ActiveMQ Exception
Key: CAMEL-6218
URL: https://issues.apache.org/jira/browse/CAMEL-6218
Project: Camel
Issue Type: Bug
Affects Versions: 2.10.4
Reporter: Alan Foster
Assignee: Raul Kripalani
Fix For: 2.11.0
Attachments: camel-6214-transferExchange.java,
camel-6218-test-project.rar, org.apache.cmueller.camel.zip
The scnearios are :
- when using the transferExchange option only on the producer, I don't
get the body back, but not the header.
- When I use the transferExchange option on both producer and consumer, I
get the headers back, but not the body. And instead I get the following
exception
{code:java}
[ryQueueReplyManager[temporary]] TemporaryQueueReplyManager WARN
Execution of JMS message listener failed. Caused by:
[java.lang.NullPointerException - null]
java.lang.NullPointerException
at
org.apache.camel.impl.DefaultExchangeHolder.unmarshal(DefaultExchangeHolder.java:107)
at
org.apache.camel.component.jms.JmsBinding.extractBodyFromJms(JmsBinding.java:128)
at
org.apache.camel.component.jms.JmsMessage.createBody(JmsMessage.java:214)
at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:41)
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.processReply(ReplyManagerSupport.java:136)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyHandler.onReply(TemporaryQueueReplyHandler.java:54)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyManager.handleReplyMessage(TemporaryQueueReplyManager.java:71)
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.onMessage(ReplyManagerSupport.java:113)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:560)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:498)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:662)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6229) InOut ActiveMQ exception Cannot publish to a deleted Destination
[
https://issues.apache.org/jira/browse/CAMEL-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618698#comment-13618698
]
Raul Kripalani commented on CAMEL-6229:
---
[~alanfoster] - I've reproduced this situation in the past when using the VM
Transport and SMX 4.5.0 or above. In my case, the culprit was the
activemq-broker.xml hotdeploy feature, which was redeploying the broker soon
after the Camel routes started, therefore leaving them in an inconsistent
state.
Try removing this file: SMX_HOME/etc/org.apache.felix.fileinstall-activemq.cfg,
deleting the data/ directory and starting afresh.
Also, installing bundles by copying them to the deploy/ directory could be
another cause, as Karaf refreshes all linked bundles during the process
(possibly the broker too). How do you perform the deployment?
InOut ActiveMQ exception Cannot publish to a deleted Destination
Key: CAMEL-6229
URL: https://issues.apache.org/jira/browse/CAMEL-6229
Project: Camel
Issue Type: Bug
Reporter: Alan Foster
Assignee: Raul Kripalani
Attachments: camel-6229.rar
When exposing a cxf-rs webservice and attempting to talk to another route,
using InOut MEP + ActiveMQ the following exception occurs
{code}
22:18:14,813 | INFO | tp1882786420-364 | route1 |
147 - org.apache.camel.camel-core - 2.10.0.fuse-71-047 | Received a request
::
22:18:14,838 | WARN | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'temporary' - trying to recover. Cause: The
Consumer is closed
22:18:14,849 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:3
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:4
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:5
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:6
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:7
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:8
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:2
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:1
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:9
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:10
on closing pooled connection: The connection is already closed
22:18:14,857 | WARN | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker
[jira] [Updated] (CAMEL-5916) CXFRS: Inject @Params as IN message headers and handle Subresources
[ https://issues.apache.org/jira/browse/CAMEL-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani updated CAMEL-5916: -- Issue Type: New Feature (was: Bug) CXFRS: Inject @Params as IN message headers and handle Subresources --- Key: CAMEL-5916 URL: https://issues.apache.org/jira/browse/CAMEL-5916 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.11.1 See http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html for context. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6228) CXFRS: Consumer - Inject Resource instance into message
Raul Kripalani created CAMEL-6228: - Summary: CXFRS: Consumer - Inject Resource instance into message Key: CAMEL-6228 URL: https://issues.apache.org/jira/browse/CAMEL-6228 Project: Camel Issue Type: Improvement Components: camel-cxf Affects Versions: 2.10.4 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.11.1 CxfRsInvoker#asyncInvoke and CxfRsInvoker#syncInvoke forsake the Service Object. Instead it should be passed on to the CxfRsBinding. Will try and fix for 2.11 as it implies API changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5916) CXFRS: Inject @Params as IN message headers and handle Subresources
[
https://issues.apache.org/jira/browse/CAMEL-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-5916:
--
Description:
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming from
the CXF stack into the Message body.
We should offer a CxfRsBinding that is more user-friendly and makes the request
data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
was:See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
CXFRS: Inject @Params as IN message headers and handle Subresources
---
Key: CAMEL-5916
URL: https://issues.apache.org/jira/browse/CAMEL-5916
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.1
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming
from the CXF stack into the Message body.
We should offer a CxfRsBinding that is more user-friendly and makes the
request data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5916) CXFRS: Inject @Params as IN message headers and handle Subresources
[
https://issues.apache.org/jira/browse/CAMEL-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-5916:
--
Description:
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming from
the CXF stack into the Message body. The route then has to do much lower-level
processing than usual, and is tightly coupled with the method signature of the
JAX-RS operation.
We should offer a CxfRsBinding that is more user-friendly and makes the request
data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
was:
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming from
the CXF stack into the Message body.
We should offer a CxfRsBinding that is more user-friendly and makes the request
data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
CXFRS: Inject @Params as IN message headers and handle Subresources
---
Key: CAMEL-5916
URL: https://issues.apache.org/jira/browse/CAMEL-5916
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.1
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming
from the CXF stack into the Message body. The route then has to do much
lower-level processing than usual, and is tightly coupled with the method
signature of the JAX-RS operation.
We should offer a CxfRsBinding that is more user-friendly and makes the
request data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5916) CXFRS: Simpler, higher-level binding style injecting headers, attachements and entity
[
https://issues.apache.org/jira/browse/CAMEL-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-5916:
--
Summary: CXFRS: Simpler, higher-level binding style injecting headers,
attachements and entity (was: CXFRS: Inject @Params as IN message headers and
handle Subresources)
CXFRS: Simpler, higher-level binding style injecting headers, attachements
and entity
-
Key: CAMEL-5916
URL: https://issues.apache.org/jira/browse/CAMEL-5916
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.1
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming
from the CXF stack into the Message body. The route then has to do much
lower-level processing than usual, and is tightly coupled with the method
signature of the JAX-RS operation.
We should offer a CxfRsBinding that is more user-friendly and makes the
request data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5916) CXFRS: Simpler, higher-level binding style injecting headers, attachments and entity
[
https://issues.apache.org/jira/browse/CAMEL-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-5916:
--
Fix Version/s: (was: 2.11.1)
2.11.0
Summary: CXFRS: Simpler, higher-level binding style injecting
headers, attachments and entity (was: CXFRS: Simpler, higher-level binding
style injecting headers, attachements and entity)
CXFRS: Simpler, higher-level binding style injecting headers, attachments and
entity
Key: CAMEL-5916
URL: https://issues.apache.org/jira/browse/CAMEL-5916
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.0
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming
from the CXF stack into the Message body. The route then has to do much
lower-level processing than usual, and is tightly coupled with the method
signature of the JAX-RS operation.
We should offer a CxfRsBinding that is more user-friendly and makes the
request data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5916) CXFRS: Simpler, higher-level binding style injecting headers, attachments and entity
[
https://issues.apache.org/jira/browse/CAMEL-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-5916.
---
Resolution: Fixed
Created a {{SimpleCxfRsBinding}} CXFRS Binding which can be enabled by setting
the {{bindingStyle}} parameter to {{SimpleConsumer}}. This is a fully backwards
compatible change, as the old behaviour is still the default one.
CXFRS: Simpler, higher-level binding style injecting headers, attachments and
entity
Key: CAMEL-5916
URL: https://issues.apache.org/jira/browse/CAMEL-5916
Project: Camel
Issue Type: New Feature
Components: camel-cxf
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.0
The camel-cxfrs consumer currently dumps the {{MessageContentList}} coming
from the CXF stack into the Message body. The route then has to do much
lower-level processing than usual, and is tightly coupled with the method
signature of the JAX-RS operation.
We should offer a CxfRsBinding that is more user-friendly and makes the
request data more accesible to the route. Aim for the following:
- Map JAX-RS parameters (@HeaderParam, @QueryParam, etc.) as Camel IN message
headers.
- Set the request entity as the IN message body.
- Inject binary @Multipart attachments as Camel IN message attachments.
Additionally, path parameters along the Subresource locator chain should be
mapped as headers too. See
http://camel.465427.n5.nabble.com/camel-cxfrs-Handling-of-Subresources-td5724615.html
for context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6218) TransferExchage InOut ActiveMQ Exception
[
https://issues.apache.org/jira/browse/CAMEL-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618422#comment-13618422
]
Raul Kripalani commented on CAMEL-6218:
---
[~alanfoster], I fixed a few bugs and race conditions in camel-jms recently.
Take a look if any of [these
issues|https://issues.apache.org/jira/issues/?jql=project%20%3D%20CAMEL%20AND%20component%20%3D%20camel-jms%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20assignee%20in%20(currentUser())]
could match your findings.
TransferExchage InOut ActiveMQ Exception
Key: CAMEL-6218
URL: https://issues.apache.org/jira/browse/CAMEL-6218
Project: Camel
Issue Type: Bug
Affects Versions: 2.10.4
Reporter: Alan Foster
Fix For: 2.11.0
Attachments: camel-6214-transferExchange.java,
camel-6218-test-project.rar, org.apache.cmueller.camel.zip
The scnearios are :
- when using the transferExchange option only on the producer, I don't
get the body back, but not the header.
- When I use the transferExchange option on both producer and consumer, I
get the headers back, but not the body. And instead I get the following
exception
{code:java}
[ryQueueReplyManager[temporary]] TemporaryQueueReplyManager WARN
Execution of JMS message listener failed. Caused by:
[java.lang.NullPointerException - null]
java.lang.NullPointerException
at
org.apache.camel.impl.DefaultExchangeHolder.unmarshal(DefaultExchangeHolder.java:107)
at
org.apache.camel.component.jms.JmsBinding.extractBodyFromJms(JmsBinding.java:128)
at
org.apache.camel.component.jms.JmsMessage.createBody(JmsMessage.java:214)
at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:41)
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.processReply(ReplyManagerSupport.java:136)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyHandler.onReply(TemporaryQueueReplyHandler.java:54)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyManager.handleReplyMessage(TemporaryQueueReplyManager.java:71)
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.onMessage(ReplyManagerSupport.java:113)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:560)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:498)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:662)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6229) InOut ActiveMQ exception Cannot publish to a deleted Destination
[
https://issues.apache.org/jira/browse/CAMEL-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618496#comment-13618496
]
Raul Kripalani commented on CAMEL-6229:
---
Two things:
# Could be related to CAMEL-5865. The InOut logic was a bit rough around the
edges and was much improved in that ticket. Please try your code with Camel
2.10.4 and give us some feedback.
# Please post your route logic. In particular, I'd like to see your AMQ
component configuration (JmsConfiguration) and the AMQ endpoint options, of
both the producer and the consumer.
Thanks.
InOut ActiveMQ exception Cannot publish to a deleted Destination
Key: CAMEL-6229
URL: https://issues.apache.org/jira/browse/CAMEL-6229
Project: Camel
Issue Type: Bug
Reporter: Alan Foster
Attachments: camel-6229.rar
When exposing a cxf-rs webservice and attempting to talk to another route,
using InOut MEP + ActiveMQ the following exception occurs
{code}
22:18:14,813 | INFO | tp1882786420-364 | route1 |
147 - org.apache.camel.camel-core - 2.10.0.fuse-71-047 | Received a request
::
22:18:14,838 | WARN | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'temporary' - trying to recover. Cause: The
Consumer is closed
22:18:14,849 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:3
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:4
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:5
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:6
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:7
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:8
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:2
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:1
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:9
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:10
on closing pooled connection: The connection is already closed
22:18:14,857 | WARN | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'responseHandler' - trying to recover. Cause:
The Consumer is closed
22:18:14,919 | INFO | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Successfully refreshed JMS
Connection
22:18:14,927 | INFO |
[jira] [Assigned] (CAMEL-6229) InOut ActiveMQ exception Cannot publish to a deleted Destination
[
https://issues.apache.org/jira/browse/CAMEL-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani reassigned CAMEL-6229:
-
Assignee: Raul Kripalani
InOut ActiveMQ exception Cannot publish to a deleted Destination
Key: CAMEL-6229
URL: https://issues.apache.org/jira/browse/CAMEL-6229
Project: Camel
Issue Type: Bug
Reporter: Alan Foster
Assignee: Raul Kripalani
Attachments: camel-6229.rar
When exposing a cxf-rs webservice and attempting to talk to another route,
using InOut MEP + ActiveMQ the following exception occurs
{code}
22:18:14,813 | INFO | tp1882786420-364 | route1 |
147 - org.apache.camel.camel-core - 2.10.0.fuse-71-047 | Received a request
::
22:18:14,838 | WARN | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'temporary' - trying to recover. Cause: The
Consumer is closed
22:18:14,849 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:3
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:4
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:5
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:6
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:7
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:8
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:2
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:1
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:9
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:10
on closing pooled connection: The connection is already closed
22:18:14,857 | WARN | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'responseHandler' - trying to recover. Cause:
The Consumer is closed
22:18:14,919 | INFO | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Successfully refreshed JMS
Connection
22:18:14,927 | INFO | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Successfully refreshed JMS
Connection
22:18:14,939 | INFO | responseHandler] | route2 |
147 - org.apache.camel.camel-core - 2.10.0.fuse-71-047 | Response handler
successfully received a request!
22:18:14,943 | WARN | responseHandler] | EndpointMessageListener
[jira] [Commented] (CAMEL-6229) InOut ActiveMQ exception Cannot publish to a deleted Destination
[
https://issues.apache.org/jira/browse/CAMEL-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618508#comment-13618508
]
Raul Kripalani commented on CAMEL-6229:
---
Thanks. Can you try with Camel JMS 2.10.4?
Also, when you say you are on Camel 2.10, you mean Camel 2.10.0? What micro
version exactly?
InOut ActiveMQ exception Cannot publish to a deleted Destination
Key: CAMEL-6229
URL: https://issues.apache.org/jira/browse/CAMEL-6229
Project: Camel
Issue Type: Bug
Reporter: Alan Foster
Assignee: Raul Kripalani
Attachments: camel-6229.rar
When exposing a cxf-rs webservice and attempting to talk to another route,
using InOut MEP + ActiveMQ the following exception occurs
{code}
22:18:14,813 | INFO | tp1882786420-364 | route1 |
147 - org.apache.camel.camel-core - 2.10.0.fuse-71-047 | Received a request
::
22:18:14,838 | WARN | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'temporary' - trying to recover. Cause: The
Consumer is closed
22:18:14,849 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:3
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:4
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:5
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:6
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:7
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:8
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:2
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:1
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:9
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:10
on closing pooled connection: The connection is already closed
22:18:14,857 | WARN | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'responseHandler' - trying to recover. Cause:
The Consumer is closed
22:18:14,919 | INFO | responseHandler] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Successfully refreshed JMS
Connection
22:18:14,927 | INFO | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Successfully refreshed JMS
Connection
22:18:14,939 | INFO | responseHandler] | route2 |
147
[jira] [Commented] (CAMEL-6229) InOut ActiveMQ exception Cannot publish to a deleted Destination
[
https://issues.apache.org/jira/browse/CAMEL-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618511#comment-13618511
]
Raul Kripalani commented on CAMEL-6229:
---
Ok, never mind, I see the Camel version in the logs ;)
I don't know if FuseSource/Red Hat have backmerged some important JMS patches
onto their 2.10.0.fuse-71-047 release.
From the logs, it looks like they backmerged the initial support for
concurrentConsumers on temp reply queues from Camel 2.10.3, but they didn't
merge the latest fixes which actually make this feature useable (CAMEL-5865)
in Camel 2.10.4. My reasoning is that I see 10 different temp queues being
created for the same request queue, which is exactly what CAMEL-5865 resolves.
Please give it a shot with Camel 2.10.4. You should be able to uninstall the
current camel-jms component and install 2.10.4 with:
{code}
install -s mvn:org.apache.camel/camel-jms/2.10.4
{code}
Hopefully no more dependency upgrades will be necessary.
InOut ActiveMQ exception Cannot publish to a deleted Destination
Key: CAMEL-6229
URL: https://issues.apache.org/jira/browse/CAMEL-6229
Project: Camel
Issue Type: Bug
Reporter: Alan Foster
Assignee: Raul Kripalani
Attachments: camel-6229.rar
When exposing a cxf-rs webservice and attempting to talk to another route,
using InOut MEP + ActiveMQ the following exception occurs
{code}
22:18:14,813 | INFO | tp1882786420-364 | route1 |
147 - org.apache.camel.camel-core - 2.10.0.fuse-71-047 | Received a request
::
22:18:14,838 | WARN | nager[temporary] | faultJmsMessageListenerContainer |
153 - org.springframework.jms - 3.0.7.RELEASE | Setup of JMS message listener
invoker failed for destination 'temporary' - trying to recover. Cause: The
Consumer is closed
22:18:14,849 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:3
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:4
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:5
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:6
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:7
on closing pooled connection: The connection is already closed
22:18:14,850 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:8
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:2
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:1
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:9
on closing pooled connection: The connection is already closed
22:18:14,851 | INFO | nager[temporary] | PooledConnection |
122 - org.apache.activemq.activemq-pool - 5.7.0.fuse-71-047 | failed to
delete Temporary Queue temp-queue://ID:alan-dell-49913-1364764601861-3:3:10
on closing pooled connection: The connection is already closed
[jira] [Commented] (CAMEL-5698) Allow to set a custom LogFormatter in the Log component
[ https://issues.apache.org/jira/browse/CAMEL-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616162#comment-13616162 ] Raul Kripalani commented on CAMEL-5698: --- Hi [~davsclaus], Yes, I know. But I don't see the benefit of setting formatters are the endpoint level. The goal was to provide a hook for users to customise all output from the Log component in one shot. Users may pursue this for any one of the reasons outlined in the ticket description. To write a one-off custom log message, you are better off using the Log EIP, which was designed specifically for that purpose. But hey, my views are personal. Regards, Raúl. Allow to set a custom LogFormatter in the Log component --- Key: CAMEL-5698 URL: https://issues.apache.org/jira/browse/CAMEL-5698 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.9.3, 2.10.1 Reporter: Raul Kripalani Assignee: Raul Kripalani Priority: Minor Fix For: 2.11.0 The LogFormatter should be configurable. Then one can: - filter the headers and properties that are printed (try logging with showHeaders=true after an InOut CXF invocation and you get information overdose) - adjust the log message to whatever they deem most readable - tailor log messages for processing by log mining systems, e.g. Splunk - print specific body types differently - etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-5698) Allow to set a custom LogFormatter in the Log component
[ https://issues.apache.org/jira/browse/CAMEL-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-5698 started by Raul Kripalani. Allow to set a custom LogFormatter in the Log component --- Key: CAMEL-5698 URL: https://issues.apache.org/jira/browse/CAMEL-5698 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.9.3, 2.10.1 Reporter: Raul Kripalani Assignee: Raul Kripalani Priority: Minor Fix For: 2.11.1 The LogFormatter should be configurable. Then one can: - filter the headers and properties that are printed (try logging with showHeaders=true after an InOut CXF invocation and you get information overdose) - adjust the log message to whatever they deem most readable - tailor log messages for processing by log mining systems, e.g. Splunk - print specific body types differently - etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5698) Allow to set a custom LogFormatter in the Log component
[ https://issues.apache.org/jira/browse/CAMEL-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-5698. --- Resolution: Fixed Fix Version/s: (was: 2.11.1) 2.11.0 Allow to set a custom LogFormatter in the Log component --- Key: CAMEL-5698 URL: https://issues.apache.org/jira/browse/CAMEL-5698 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.9.3, 2.10.1 Reporter: Raul Kripalani Assignee: Raul Kripalani Priority: Minor Fix For: 2.11.0 The LogFormatter should be configurable. Then one can: - filter the headers and properties that are printed (try logging with showHeaders=true after an InOut CXF invocation and you get information overdose) - adjust the log message to whatever they deem most readable - tailor log messages for processing by log mining systems, e.g. Splunk - print specific body types differently - etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6214) ActiveMq InOut MEP headers lost during
[
https://issues.apache.org/jira/browse/CAMEL-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614744#comment-13614744
]
Raul Kripalani commented on CAMEL-6214:
---
Good call, [~muellerc]. I got misled by the existence of the
{{Message.setObjectProperty(Object)}} method.
But the [{{javax.jms.Message}}
Javadoc|http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html] states
the following:
{quote}
The setObjectProperty method accepts values of class Boolean, Byte, Short,
Integer, Long, Float, Double, and String. An attempt to use any other class
must throw a JMSException.
{quote}
So it's clear that this use case is unsupported by the underlying spec.
ActiveMq InOut MEP headers lost during
---
Key: CAMEL-6214
URL: https://issues.apache.org/jira/browse/CAMEL-6214
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-core
Environment: Windows server 2008 r2
Reporter: Alan Foster
Attachments: camel-6214-testCase.java
I seem to be losing complex type headers when I send them as InOut over
activemq for some reason.
It seems to work works fine using the InOut MEP for the 'direct' component
though
The complex body is transferred fine, but the header is lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6123) camel-jms: InOut exchange can time out even if response was received
[
https://issues.apache.org/jira/browse/CAMEL-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-6123:
--
Description:
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present since
mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.inOut(activemq:test?requestTimeout=500)
.delay(constant(1000));
from(activemq:test)
.log(test);
}
};
}
{code}
was:
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present since
mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.to(activemq:inexistent?requestTimeout=500)
.delay(constant(600));
}
};
}
{code}
camel-jms: InOut exchange can time out even if response was received
Key: CAMEL-6123
URL: https://issues.apache.org/jira/browse/CAMEL-6123
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.9.5, 2.10.3
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Priority: Critical
Fix For: 2.9.6, 2.10.5, 2.11.0
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present
since mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.inOut(activemq:test?requestTimeout=500)
.delay(constant(1000));
from(activemq:test)
.log(test);
}
};
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6123) camel-jms: InOut exchange can time out even if response was received
[
https://issues.apache.org/jira/browse/CAMEL-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-6123.
---
Resolution: Fixed
camel-jms: InOut exchange can time out even if response was received
Key: CAMEL-6123
URL: https://issues.apache.org/jira/browse/CAMEL-6123
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.9.5, 2.10.3
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Priority: Critical
Fix For: 2.10.5, 2.11.0, 2.9.6
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present
since mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.inOut(activemq:test?requestTimeout=500)
.delay(constant(1000));
from(activemq:test)
.log(test);
}
};
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6123) camel-jms: InOut exchange can time out even if response was received
[
https://issues.apache.org/jira/browse/CAMEL-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609747#comment-13609747
]
Raul Kripalani commented on CAMEL-6123:
---
Fixed in trunk, 2.10.x and 2.9.x branches.
camel-jms: InOut exchange can time out even if response was received
Key: CAMEL-6123
URL: https://issues.apache.org/jira/browse/CAMEL-6123
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.9.5, 2.10.3
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Priority: Critical
Fix For: 2.9.6, 2.10.5, 2.11.0
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present
since mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.inOut(activemq:test?requestTimeout=500)
.delay(constant(1000));
from(activemq:test)
.log(test);
}
};
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6180) SJMS Component behavior suggestions to improve upon the standard JMS component
[ https://issues.apache.org/jira/browse/CAMEL-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606651#comment-13606651 ] Raul Kripalani commented on CAMEL-6180: --- Hi Matt, Regarding point #3, would you mind elaborating a bit further? Providing a small example may help. Thanks, Raúl. SJMS Component behavior suggestions to improve upon the standard JMS component -- Key: CAMEL-6180 URL: https://issues.apache.org/jira/browse/CAMEL-6180 Project: Camel Issue Type: Improvement Components: camel-sjms Reporter: Matt Pavlovich Assignee: Scott England-Sullivan The SJMS component should not suffer any feature loss from the standard JMS component, for best user experience in 3.0. A random mix of suggested behavior changes/enhancements: 1. Supporting things like consume from multiple destinations using wildcards... from jms:queue:US_TICKETS_* 2. Support dynamic destination on a to uri=.. by using the same header from the existing JMS component. CamelJmsDestination javax.jms.DestinationA destination object. CamelJmsDestinationName String The destination name. 3. I suggest making 'request-reply' be explicit, since implicit is really painful for new users. The magic temp destination listener is not confusing and the user has nothing in the route to go on as to why that is happening. 4. Along w/ #3, don't kill the QoS headers by default. It makes setting up proxies really complicated. 5. Support MQ Series 'weirdness' that current component handles.. see 'Setting JMS provider options on the destination' here: http://camel.apache.org/jms.html Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-1479) Remove inheritErrorHandler option
[ https://issues.apache.org/jira/browse/CAMEL-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13596980#comment-13596980 ] Raul Kripalani commented on CAMEL-1479: --- This issue was fixed a long time ago, but the constructs linger in all DSLs and they indeed manipulate things underneath, i.e. they are not noops. It all seems a bit contradictory. Are they simple leftovers? Can we remove the DSL constructs in Camel 3.0? Remove inheritErrorHandler option - Key: CAMEL-1479 URL: https://issues.apache.org/jira/browse/CAMEL-1479 Project: Camel Issue Type: Task Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.0-M2 Its an unused feature and really just complicates if you can on per. individual route set some other error handling strategy than what applies normally with - global error handler - per route error handler -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6123) camel-jms: InOut exchange can time out even if response was received
Raul Kripalani created CAMEL-6123:
-
Summary: camel-jms: InOut exchange can time out even if response
was received
Key: CAMEL-6123
URL: https://issues.apache.org/jira/browse/CAMEL-6123
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.10.3, 2.9.5
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Priority: Critical
Fix For: 2.9.6, 2.10.4, 2.11.0
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present since
mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.to(activemq:inexistent?requestTimeout=500)
.delay(constant(600));
}
};
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6123) camel-jms: InOut exchange can time out even if response was received
[
https://issues.apache.org/jira/browse/CAMEL-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592162#comment-13592162
]
Raul Kripalani commented on CAMEL-6123:
---
This happens because the entry is removed from the CorrelationTimeoutMap too
late, after the subsequent processing has been invoked and returns.
camel-jms: InOut exchange can time out even if response was received
Key: CAMEL-6123
URL: https://issues.apache.org/jira/browse/CAMEL-6123
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.9.5, 2.10.3
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Priority: Critical
Fix For: 2.9.6, 2.10.4, 2.11.0
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present
since mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.to(activemq:inexistent?requestTimeout=500)
.delay(constant(600));
}
};
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-6123) camel-jms: InOut exchange can time out even if response was received
[
https://issues.apache.org/jira/browse/CAMEL-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-6123 started by Raul Kripalani.
camel-jms: InOut exchange can time out even if response was received
Key: CAMEL-6123
URL: https://issues.apache.org/jira/browse/CAMEL-6123
Project: Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 2.9.5, 2.10.3
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Priority: Critical
Fix For: 2.9.6, 2.10.4, 2.11.0
When performing an InOut JMS exchange with a certain requestTimeout, if the
reply message is received in time, but the following formula stands true:
{{T0 + T1 = T!}}, where:
T0 = JMS response time
T1 = remaining route processing time following the reply
T! = requestTimeout
Then camel-jms will throw an {{ExchangeTimedOutException}} regardless of the
fact that the reply was truly received in time.
I'm surprised this bug has gone unnoticed until now, as it's been present
since mid-2010.
*Example unit test:*
{code:java}
@Test
public void testTimeoutNotTriggered() throws Exception {
getMockEndpoint(mock:exception).expectedMessageCount(0);
template.requestBody(activemq:test, hello /);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
onException(ExchangeTimedOutException.class)
.handled(true)
.to(mock:exception);
from(activemq:test)
.to(activemq:inexistent?requestTimeout=500)
.delay(constant(600));
}
};
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6118) Allow to combine predicates applying logical operators
[
https://issues.apache.org/jira/browse/CAMEL-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592168#comment-13592168
]
Raul Kripalani commented on CAMEL-6118:
---
[~pax], agree that it's gone unnoticed for a long time. Buried in a doc page
that's not very popular, as when one is browsing references, they tend to jump
from [Architecture|http://camel.apache.org/architecture.html] straight to the
expression language of choice.
I'll add a notice to all Expression Language pages to advertise this powerful
feature.
It's not available for Blueprint/Spring AFAIK.
Allow to combine predicates applying logical operators
--
Key: CAMEL-6118
URL: https://issues.apache.org/jira/browse/CAMEL-6118
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.1
I can see something like this being very useful in many cases:
{code}
from(foo:bar)
.filter(and(xpath(//weather = 'cloudy'), simple(${property.skyColor} !=
'dark grey')))
.setBody(constant(It's gonna rain...))
.end();
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6108) Refactor JMS Component to use JTA Transactions instead of Spring Transactions
[ https://issues.apache.org/jira/browse/CAMEL-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592471#comment-13592471 ] Raul Kripalani commented on CAMEL-6108: --- Camel JMS is a true veteran and one of the most widely used components alongside camel-cxf, camel-http and the ones embedded in camel-core. Given its installation base, I don't think it's wise to refactor it into a whole different technology base. That said, I'd expect us (the Camel team) to encourage camel-sjms as the first choice for JMS integration as soon as it's been more extensively tested in the trenches, as Scott ES explains. And perhaps do a few renames once that happens: - camel-jms = camel-springjms - camel-sjms = camel-jms But it'd have to happen on a major release, so it's a very long-term vision. Refactor JMS Component to use JTA Transactions instead of Spring Transactions - Key: CAMEL-6108 URL: https://issues.apache.org/jira/browse/CAMEL-6108 Project: Camel Issue Type: Improvement Components: camel-jms Reporter: Chris Geer Fix For: 3.0.0 We love contributions as you know. May you find time to work on it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6118) Allow to combine predicates applying logical operators
[
https://issues.apache.org/jira/browse/CAMEL-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-6118.
---
Resolution: Invalid
Sweet! I wondered how come no one had requested this before, as it's quite a
life-saver. This feature needs better documentation - I'll take care of that.
Allow to combine predicates applying logical operators
--
Key: CAMEL-6118
URL: https://issues.apache.org/jira/browse/CAMEL-6118
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.11.1
I can see something like this being very useful in many cases:
{code}
from(foo:bar)
.filter(and(xpath(//weather = 'cloudy'), simple(${property.skyColor} !=
'dark grey')))
.setBody(constant(It's gonna rain...))
.end();
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6072) Service Shutdown logic may execute N times
Raul Kripalani created CAMEL-6072: - Summary: Service Shutdown logic may execute N times Key: CAMEL-6072 URL: https://issues.apache.org/jira/browse/CAMEL-6072 Project: Camel Issue Type: Bug Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.4, 2.11.0 ServiceSupport#shutdown should return immediately to avoid executing service shutdown logic twice, which could easily cause problems in the state of components, endpoints, consumers, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6073) Pairs of VM producer-consumer disconnect when OSGi bundle is restarted
Raul Kripalani created CAMEL-6073: - Summary: Pairs of VM producer-consumer disconnect when OSGi bundle is restarted Key: CAMEL-6073 URL: https://issues.apache.org/jira/browse/CAMEL-6073 Project: Camel Issue Type: Bug Affects Versions: 2.10.3 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.4, 2.11.0 See http://camel.465427.n5.nabble.com/VM-Queues-Disconnected-after-Karaf-Bundle-Update-tt5727205.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6072) Service Shutdown logic may execute N times
[ https://issues.apache.org/jira/browse/CAMEL-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani updated CAMEL-6072: -- Affects Version/s: 2.9.5 2.10.3 Service Shutdown logic may execute N times -- Key: CAMEL-6072 URL: https://issues.apache.org/jira/browse/CAMEL-6072 Project: Camel Issue Type: Bug Affects Versions: 2.9.5, 2.10.3 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.4, 2.11.0 ServiceSupport#shutdown should return immediately to avoid executing service shutdown logic twice, which could easily cause problems in the state of components, endpoints, consumers, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6073) Pairs of VM producer-consumer disconnect when OSGi bundle is restarted
[ https://issues.apache.org/jira/browse/CAMEL-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6073. --- Resolution: Fixed Committed in r1445263 (trunk), r1445265 (2.10.x branch), 1445266 (2.9.x branch). Pairs of VM producer-consumer disconnect when OSGi bundle is restarted -- Key: CAMEL-6073 URL: https://issues.apache.org/jira/browse/CAMEL-6073 Project: Camel Issue Type: Bug Affects Versions: 2.9.5, 2.10.3 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.9.6, 2.10.4, 2.11.0 See http://camel.465427.n5.nabble.com/VM-Queues-Disconnected-after-Karaf-Bundle-Update-tt5727205.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6072) Service Shutdown logic may execute N times
[ https://issues.apache.org/jira/browse/CAMEL-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani resolved CAMEL-6072. --- Resolution: Fixed Fix Version/s: 2.9.6 Committed in r1445263 (trunk), r1445265 (2.10.x branch), 1445266 (2.9.x branch). Service Shutdown logic may execute N times -- Key: CAMEL-6072 URL: https://issues.apache.org/jira/browse/CAMEL-6072 Project: Camel Issue Type: Bug Affects Versions: 2.9.5, 2.10.3 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.9.6, 2.10.4, 2.11.0 ServiceSupport#shutdown should return immediately to avoid executing service shutdown logic twice, which could easily cause problems in the state of components, endpoints, consumers, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5974) camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
[
https://issues.apache.org/jira/browse/CAMEL-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558230#comment-13558230
]
Raul Kripalani commented on CAMEL-5974:
---
I reverted the changes on both branches while I drill into what's going on.
[~davsclaus], I'd like to investigate further before we take a decision. With
the current Task Executor, 8 hours of operation with very little messaging
traffic gave us a thread thrash of around 40.000 JMS threads created/destroyed
- crazy! That's why I believe this enhancement to be beneficial for folks
running on 2.10.x too.
I'll keep you updated on the next few days.
camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
Key: CAMEL-5974
URL: https://issues.apache.org/jira/browse/CAMEL-5974
Project: Camel
Issue Type: Improvement
Components: camel-jms
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.4, 2.11.0
{{DefaultJmsMessageListenerContainer}} uses
{{org.springframework.core.task.SimpleAsyncTaskExecutor}} as the default task
executor.
This causes a lot of thread thrash when setting a positive
idleTaskExecutionLimit. New threads are created every time the consumers are
refreshed, i.e. closed down and started again to keep the minimum number of
them around (= concurrentConsumers).
Replace with
{{org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor}} instead,
with the following config:
* corePoolSize = concurrentConsumers
* maxPoolSize = maxConcurrentConsumers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5865) camel-jms: concurrent consumers on Temp Reply Queue requires more work
[ https://issues.apache.org/jira/browse/CAMEL-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554548#comment-13554548 ] Raul Kripalani commented on CAMEL-5865: --- Claus - done. And now we also honour replyToCacheLevelName if set. camel-jms: concurrent consumers on Temp Reply Queue requires more work -- Key: CAMEL-5865 URL: https://issues.apache.org/jira/browse/CAMEL-5865 Project: Camel Issue Type: Bug Components: camel-jms Affects Versions: 2.10.3 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.4, 2.11.0 This feature requires a bit more work to get right. Currently it's a bit buggy. Here are the reasons: - every time the DLMC initialises a new consumer task (AsyncMessageListenerInvoker), it invokes the Destination Resolver. The current code ends up creating a new temp queue and overwriting the reply queue in the Reply Manager every time. - temp queues can only be consumed from by the same JMS connection that created the queue. If you use a connection pool and maxConsumers 1, there's no way to guarantee that the same JMS connection is used to create the subsequent consumers, as concurrency expands. We should explicitly set cacheLevel=CACHE_CONSUMER which activates sharing the connection in the DLMC across consumers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5974) camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
Raul Kripalani created CAMEL-5974:
-
Summary: camel-jms: Make ThreadPoolTaskExecutor the default Task
Executor
Key: CAMEL-5974
URL: https://issues.apache.org/jira/browse/CAMEL-5974
Project: Camel
Issue Type: Improvement
Components: camel-jms
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.9.6, 2.10.4, 2.11.0
{{DefaultJmsMessageListenerContainer}} uses
{{org.springframework.core.task.SimpleAsyncTaskExecutor}} as the default task
executor.
This causes a lot of thread thrash when setting a positive
idleTaskExecutionLimit. New threads are created every time the consumers are
refreshed, i.e. closed down and started again to keep the minimum number of
them around (= concurrentConsumers).
Replace with
{{org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor}} instead,
with the following config:
* corePoolSize = concurrentConsumers
* maxPoolSize = maxConcurrentConsumers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5974) camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
[
https://issues.apache.org/jira/browse/CAMEL-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CAMEL-5974:
--
Fix Version/s: (was: 2.9.6)
camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
Key: CAMEL-5974
URL: https://issues.apache.org/jira/browse/CAMEL-5974
Project: Camel
Issue Type: Improvement
Components: camel-jms
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.4, 2.11.0
{{DefaultJmsMessageListenerContainer}} uses
{{org.springframework.core.task.SimpleAsyncTaskExecutor}} as the default task
executor.
This causes a lot of thread thrash when setting a positive
idleTaskExecutionLimit. New threads are created every time the consumers are
refreshed, i.e. closed down and started again to keep the minimum number of
them around (= concurrentConsumers).
Replace with
{{org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor}} instead,
with the following config:
* corePoolSize = concurrentConsumers
* maxPoolSize = maxConcurrentConsumers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5974) camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
[
https://issues.apache.org/jira/browse/CAMEL-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani resolved CAMEL-5974.
---
Resolution: Fixed
camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
Key: CAMEL-5974
URL: https://issues.apache.org/jira/browse/CAMEL-5974
Project: Camel
Issue Type: Improvement
Components: camel-jms
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.4, 2.11.0
{{DefaultJmsMessageListenerContainer}} uses
{{org.springframework.core.task.SimpleAsyncTaskExecutor}} as the default task
executor.
This causes a lot of thread thrash when setting a positive
idleTaskExecutionLimit. New threads are created every time the consumers are
refreshed, i.e. closed down and started again to keep the minimum number of
them around (= concurrentConsumers).
Replace with
{{org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor}} instead,
with the following config:
* corePoolSize = concurrentConsumers
* maxPoolSize = maxConcurrentConsumers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5974) camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
[
https://issues.apache.org/jira/browse/CAMEL-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554571#comment-13554571
]
Raul Kripalani commented on CAMEL-5974:
---
Fixed in trunk in r1433767, and 2.10.x branch in r1433765.
camel-jms: Make ThreadPoolTaskExecutor the default Task Executor
Key: CAMEL-5974
URL: https://issues.apache.org/jira/browse/CAMEL-5974
Project: Camel
Issue Type: Improvement
Components: camel-jms
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.4, 2.11.0
{{DefaultJmsMessageListenerContainer}} uses
{{org.springframework.core.task.SimpleAsyncTaskExecutor}} as the default task
executor.
This causes a lot of thread thrash when setting a positive
idleTaskExecutionLimit. New threads are created every time the consumers are
refreshed, i.e. closed down and started again to keep the minimum number of
them around (= concurrentConsumers).
Replace with
{{org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor}} instead,
with the following config:
* corePoolSize = concurrentConsumers
* maxPoolSize = maxConcurrentConsumers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5953) Java DSL: unmarshal() inside choice() blocks adding more conditions
Raul Kripalani created CAMEL-5953:
-
Summary: Java DSL: unmarshal() inside choice() blocks adding more
conditions
Key: CAMEL-5953
URL: https://issues.apache.org/jira/browse/CAMEL-5953
Project: Camel
Issue Type: Bug
Affects Versions: 2.10.3
Reporter: Raul Kripalani
This routing code leads to the exception below:
{code}
from(direct:abc)
.choice()
.when(simple(${body} == 'Please do not fail'))
.to(log:test)
.unmarshal().xstream().endChoice()
.otherwise()
.to(log:test)
.end();
{code}
Exception:
{code}
Caused by: java.lang.ClassCastException: org.apache.camel.model.RouteDefinition
cannot be cast to org.apache.camel.model.ChoiceDefinition
at
org.apache.camel.model.ProcessorDefinition.endChoice(ProcessorDefinition.java:1256)
at com.mycompany.MyRoute.configure(MyRoute.java:40)
at
org.apache.camel.builder.RouteBuilder.checkInitialized(RouteBuilder.java:322)
at
org.apache.camel.builder.RouteBuilder.configureRoutes(RouteBuilder.java:276)
at
org.apache.camel.builder.RouteBuilder.addRoutesToCamelContext(RouteBuilder.java:262)
[...]
{code}
Also happens if we try to add another when instead of an otherwise.
Tried using end(), endParent(), but they all lead to the same exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5946) Stream caching cannot be disabled on per-route basis with Java DSL
Raul Kripalani created CAMEL-5946: - Summary: Stream caching cannot be disabled on per-route basis with Java DSL Key: CAMEL-5946 URL: https://issues.apache.org/jira/browse/CAMEL-5946 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.10.3 Reporter: Raul Kripalani If you enable stream caching on the Camel context, you cannot disable it on a per-route basis with Java DSL. It is possible with Spring DSL, nevertheless. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5946) Stream caching cannot be disabled on per-route basis with Java DSL
[ https://issues.apache.org/jira/browse/CAMEL-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13548799#comment-13548799 ] Raul Kripalani commented on CAMEL-5946: --- [~bvahdat] Thanks for that reference! It looks like this option is not documented. I'll go ahead and document it. Stream caching cannot be disabled on per-route basis with Java DSL -- Key: CAMEL-5946 URL: https://issues.apache.org/jira/browse/CAMEL-5946 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.10.3 Reporter: Raul Kripalani If you enable stream caching on the Camel context, you cannot disable it on a per-route basis with Java DSL. It is possible with Spring DSL, nevertheless. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-5946) Stream caching cannot be disabled on per-route basis with Java DSL
[ https://issues.apache.org/jira/browse/CAMEL-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani closed CAMEL-5946. - Resolution: Invalid Stream caching cannot be disabled on per-route basis with Java DSL -- Key: CAMEL-5946 URL: https://issues.apache.org/jira/browse/CAMEL-5946 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.10.3 Reporter: Raul Kripalani If you enable stream caching on the Camel context, you cannot disable it on a per-route basis with Java DSL. It is possible with Spring DSL, nevertheless. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5865) camel-jms: concurrent consumers on Temp Reply Queue requires more work
[ https://issues.apache.org/jira/browse/CAMEL-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Kripalani updated CAMEL-5865: -- Description: This feature requires a bit more work to get right. Currently it's a bit buggy. Here are the reasons: - every time the DLMC initialises a new consumer task (AsyncMessageListenerInvoker), it invokes the Destination Resolver. The current code ends up creating a new temp queue and overwriting the reply queue in the Reply Manager every time. - temp queues can only be consumed from by the same JMS connection that created the queue. If you use a connection pool and maxConsumers 1, there's no way to guarantee that the same JMS connection is used to create the subsequent consumers, as concurrency expands. We should explicitly set cacheLevel=CACHE_CONSUMER which activates sharing the connection in the DLMC across consumers. was: This feature requires a bit more work to get right. Currently it's a bit buggy. Here are the reasons: - every time the DLMC initialises a new consumer task (AsyncMessageListenerInvoker), it invokes the Destination Resolver. The current code ends up creating a new temp queue and overwriting the reply queue in the Reply Manager every time. - temp queues can only be consumed from by the same JMS connection that created the queue. If you use a connection pool and maxConsumers 1, there's no way to guarantee that the same JMS connection is used to create the subsequent consumers, as concurrency expands. We should explicitly set cacheLevel=CACHE_CONNECTION in the DLMC. camel-jms: concurrent consumers on Temp Reply Queue requires more work -- Key: CAMEL-5865 URL: https://issues.apache.org/jira/browse/CAMEL-5865 Project: Camel Issue Type: Bug Components: camel-jms Affects Versions: 2.10.3 Reporter: Raul Kripalani Assignee: Raul Kripalani Fix For: 2.10.4, 2.11.0 This feature requires a bit more work to get right. Currently it's a bit buggy. Here are the reasons: - every time the DLMC initialises a new consumer task (AsyncMessageListenerInvoker), it invokes the Destination Resolver. The current code ends up creating a new temp queue and overwriting the reply queue in the Reply Manager every time. - temp queues can only be consumed from by the same JMS connection that created the queue. If you use a connection pool and maxConsumers 1, there's no way to guarantee that the same JMS connection is used to create the subsequent consumers, as concurrency expands. We should explicitly set cacheLevel=CACHE_CONSUMER which activates sharing the connection in the DLMC across consumers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
