[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] [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] [Assigned] (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 reassigned CAMEL-7274: - Assignee: 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] [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] [Commented] (CAMEL-7270) New ListAggregationStrategy
[ https://issues.apache.org/jira/browse/CAMEL-7270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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(Map > 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(Map > 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-tabpanel&focusedCommentId=13916226#comment-13916226 ] Raul Kripalani commented on CAMEL-7258: --- Many thanks for the patch! Applied to master (2.13.x), 2.12.x and 2.11.x branches. [~alexlomov] - I forgot to quote your name and thank you in the commit message, but GitHub will hopefully pick up the closure of the pull request, so it will be credited to you! > 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(Map > options) constructor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Work started] (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 ] Work on CAMEL-7258 started by 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(Map > options) constructor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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(Map > 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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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.Service&bindingStyle=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=value1¶m2=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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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] [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] [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-tabpanel&focusedCommentId=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] [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] [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] [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-tabpanel&focusedCommentId=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-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] [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] [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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
>
> 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-tabpanel&focusedCommentId=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)" 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] [Work started] (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:all-tabpanel ] Work on CAMEL-6694 started by Raul Kripalani. > 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.1, 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 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-6694) Make Log component and EIP compatible with log4j MDC Sift Appender
Raul Kripalani created CAMEL-6694: - Summary: 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 Fix For: 2.12.1, 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 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-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:all-tabpanel ] Raul Kripalani reassigned CAMEL-6694: - Assignee: Raul Kripalani > 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.1, 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 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-6542) Camel Toolbox: Useful Aggregation Strategies
[ https://issues.apache.org/jira/browse/CAMEL-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [Work started] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-6648 started by Raul Kripalani.
> 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] [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] [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] [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] [Commented] (CAMEL-6648) Create a Fluent ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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] [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] [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-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] [Work started] (CAMEL-6542) Camel Toolbox: Useful AggregationStrategies, OnPrepare processors, etc.
[ https://issues.apache.org/jira/browse/CAMEL-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-6542 started by Raul Kripalani. > Camel Toolbox: Useful AggregationStrategies, OnPrepare processors, etc. > --- > > 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] [Created] (CAMEL-6542) Camel Toolbox: Useful AggregationStrategies, OnPrepare processors, etc.
Raul Kripalani created CAMEL-6542: - Summary: Camel Toolbox: Useful AggregationStrategies, OnPrepare processors, etc. 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 AggregationStrategies, OnPrepare processors, etc.
[ https://issues.apache.org/jira/browse/CAMEL-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706480#comment-13706480 ] Raul Kripalani commented on CAMEL-6542: --- Everyone – feel free to contribute your use cases! > Camel Toolbox: Useful AggregationStrategies, OnPrepare processors, etc. > --- > > 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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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] [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=test&collection=test&operation=aggregat&dynamicity=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] [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=test&collection=test&operation=aggregat&dynamicity=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=test&collection=test&operation=aggregat&dynamicity=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] [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] [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-tabpanel&focusedCommentId=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=test&collection=test&operation=aggregat&dynamicity=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=test&collection=test&operation=aggregat&dynamicity=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] [Created] (CAMEL-6486) Upgrade camel-bean-validator to JSR349 (Bean Validation 1.1)
Raul Kripalani created CAMEL-6486:
-
Summary: 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.11.0, 2.10.4
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.5, 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-tabpanel&focusedCommentId=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] [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] [Comment Edited] (CAMEL-6218) TransferExchage InOut ActiveMQ Exception
[
https://issues.apache.org/jira/browse/CAMEL-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620449#comment-13620449
]
Raul Kripalani edited comment on CAMEL-6218 at 4/3/13 12:39 AM:
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.
was (Author: raulvk):
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,
[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] [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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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-136476460186
[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-tabpanel&focusedCommentId=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
> Con
[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-tabpanel&focusedCommentId=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 -
[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
> succes
[jira] [Commented] (CAMEL-6218) TransferExchage InOut ActiveMQ Exception
[
https://issues.apache.org/jira/browse/CAMEL-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [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] [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: 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] [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: -- 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] [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-tabpanel&focusedCommentId=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] [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] [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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=13614314#comment-13614314 ] Raul Kripalani commented on CAMEL-6214: --- [~alanfoster] - Objects in JMS properties must be Serializable. Can you try making the Request DTO Serializable? > 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] [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-tabpanel&focusedCommentId=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", "");
> 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", "");
> 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] [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", "");
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", "");
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", "");
> 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 administrato
[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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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", "");
> 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] [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", "");
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-tabpanel&focusedCommentId=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", "");
> 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] [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-6118) Allow to combine predicates applying logical operators
Raul Kripalani created CAMEL-6118:
-
Summary: 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] [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] [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
