[jira] [Assigned] (CAMEL-5325) camel-cxf-transport build failed using system encoding
[ https://issues.apache.org/jira/browse/CAMEL-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-5325: -- Assignee: Willem Jiang camel-cxf-transport build failed using system encoding -- Key: CAMEL-5325 URL: https://issues.apache.org/jira/browse/CAMEL-5325 Project: Camel Issue Type: Bug Components: build system, camel-cxf Environment: Windows 7 with chinese language camel 2.10-SNAPSHOT Reporter: Liu Jianhong Assignee: Willem Jiang Fix For: 2.10.0 Attachments: pom.xml This bug is fixed as https://issues.apache.org/jira/browse/CXF-2450;, by adding forkalways/fork additionalJvmArgs-Duser.language=en/additionalJvmArgs to cxf-codegen-plugin's configuration section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5325) camel-cxf-transport build failed using system encoding
[ https://issues.apache.org/jira/browse/CAMEL-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5325: --- Component/s: build system Priority: Minor (was: Major) Issue Type: Task (was: Bug) camel-cxf-transport build failed using system encoding -- Key: CAMEL-5325 URL: https://issues.apache.org/jira/browse/CAMEL-5325 Project: Camel Issue Type: Task Components: build system, camel-cxf Environment: Windows 7 with chinese language camel 2.10-SNAPSHOT Reporter: Liu Jianhong Assignee: Willem Jiang Priority: Minor Fix For: 2.10.0 Attachments: pom.xml This bug is fixed as https://issues.apache.org/jira/browse/CXF-2450;, by adding forkalways/fork additionalJvmArgs-Duser.language=en/additionalJvmArgs to cxf-codegen-plugin's configuration section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3686) Allow to share cache between bundles, and only clear cache when no more bundles access that cache
[ https://issues.apache.org/jira/browse/CAMEL-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288095#comment-13288095 ] Claus Ibsen commented on CAMEL-3686: The stop logic is not in line what we do in other components. The class loader comparison is special, and we should avoid such things. Allow to share cache between bundles, and only clear cache when no more bundles access that cache - Key: CAMEL-3686 URL: https://issues.apache.org/jira/browse/CAMEL-3686 Project: Camel Issue Type: Improvement Components: camel-cache Affects Versions: 2.4.0 Environment: camel-cache 2.4.0-fuse-01-00 Reporter: Justas Fix For: 2.11, Future Attachments: camel-cache.sharedCacheManagerFactory.patch, camel-cache.zip, diff.txt I am using camel-cache component in serviceMix. Cache endpoint uri is cache://elements?maxElementsInMemory=2memoryStoreEvictionPolicy=MemoryStoreEvictionPolicy.FIFOoverflowToDisk=falseeternal=falsetimeToLiveSeconds=800 I have 2 bundles (core.jar, services.jar). Inside those bundles I use @EndpointInject(uri = Constants.CACHE_URI) ProducerTemplate cacheTemplate; cacheTemplate.requestBodyAndHeaders(...) core.jar puts and reads elements from cache. services.jar only reads elements from cache. After deploying both bundles it works fine, but if i uninstall services.jar, cache is destroyed. core.jar (and all others) can't put objects into cache anymore. How could I make all bundles to share the same cache? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5246) File consumer - Widen check for exchange failed in case onException was used but without handling the exception
[
https://issues.apache.org/jira/browse/CAMEL-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-5246.
Resolution: Not A Problem
Works fine
File consumer - Widen check for exchange failed in case onException was used
but without handling the exception
---
Key: CAMEL-5246
URL: https://issues.apache.org/jira/browse/CAMEL-5246
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.9.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.9.3, 2.10.0
See nabble
http://camel.465427.n5.nabble.com/Component-file-move-and-moveFailed-tp5685631.html
eg
{code}
from file (moveFailed=error)
onException
to log
end
to bla
to damn
{code}
Then the file should be moved to error dir, even if onException didnt handle
the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-3547) Custom absorbing PropertyPlaceholderConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-3547:
---
Fix Version/s: (was: Future)
2.10.0
Custom absorbing PropertyPlaceholderConfigurer
Key: CAMEL-3547
URL: https://issues.apache.org/jira/browse/CAMEL-3547
Project: Camel
Issue Type: New Feature
Components: camel-spring
Affects Versions: 2.5.0
Reporter: Dan Checkoway
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.10.0
I find Camel's property placeholder support clumsy. I already use Spring's
PropertyPlaceholderConfigurer, and I feel like Camel should be able to
harness that. I realize Spring doesn't make it easy to access those
properties, but I have come up with a way to enable Camel to use them...
By simply extending PropertyPlaceholderConfigurer, we will be able to
intercept and absorb the properties that Spring has access to:
{{
import java.util.Properties;
import
org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;
public class CamelPropertyPlaceholderConfigurer extends
PropertyPlaceholderConfigurer {
private final Properties properties = new Properties();
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactory, Properties props) {
super.processProperties(beanFactory, props);
// Absorb all properties that pass through so we can expose them
later
properties.putAll(props);
}
/** Expose all absorbed properties */
public final Properties getProperties() {
return properties;
}
}
}}
It means users who want to take advantage of this would need to instantiate
this instead of the stock PropertyPlaceholderConfigurer, but that's no
problem:
bean class=org.apache.camel.impl.CamelPropertyPlaceholderConfigurer
p:location=.../
/bean
That way, you wouldn't need to declare a duplicating propertyPlaceholer
in the CamelContext. What do you think, is this feasible?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5234) Spring-WS does neither set message body nor message headers if exchange is not outCapable
[
https://issues.apache.org/jira/browse/CAMEL-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288124#comment-13288124
]
Christian Müller commented on CAMEL-5234:
-
This means if the MEP is inOnly and the web service returns a response, we
should put this into the in message (body and headers) after cleaning it from
the request body and headers, right?
Spring-WS does neither set message body nor message headers if exchange is
not outCapable
-
Key: CAMEL-5234
URL: https://issues.apache.org/jira/browse/CAMEL-5234
Project: Camel
Issue Type: Bug
Components: camel-spring-ws
Affects Versions: 2.7.5, 2.8.4, 2.9.2
Reporter: Benjamin Gniza
Assignee: Babak Vahdat
Labels: in, out, out-capable, response, spring-ws
Fix For: 2.9.3, 2.10.0
Spring-WS component does not behave as expected from pipes and filters
pattern if exchange is not _outCapable_.
If _ExchangeHelper_._isOutCapable_ returns false for the given _exchange_ the
IN-message is returned instead of the WS-Response.
Example:
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
In the example above I would expect the WS-response written to the files in
the responses directory. Currently (since 2.7.3) the IN message is written to
the files.
This is caused by _SpringWebserviceProducer#process_ because it only sets
headers and body for the OUT-message if _isOutCapable_ is _true_.
Workaround (maybe this has side effects!):
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setExchangePattern(ExchangePattern.InOut) // -- Override
with InOut Pattern
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
This behavior has been implemented to fix CAMEL-3974. From my point of view
its counter intuitive since other processing-steps don't check the exchange's
_outCapability_.
It took me several hours to find out why I always got the IN message back,
although the webservice was called correctly and returned correct results.
Maybe an option should be provided to control this behavior. At least a
log-message should be written to explain, that the webservice-reponse is
thrown away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5234) Spring-WS does neither set message body nor message headers if exchange is not outCapable
[
https://issues.apache.org/jira/browse/CAMEL-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288127#comment-13288127
]
Claus Ibsen commented on CAMEL-5234:
Yes.
Normally the response is set on the IN message if its NOT out capable.
if OUT capable
set response OUT
else
set response IN
But in the world of WS you can have OneWay which is a bit special WS. Normally
they are request/reply over WS.
Spring-WS does neither set message body nor message headers if exchange is
not outCapable
-
Key: CAMEL-5234
URL: https://issues.apache.org/jira/browse/CAMEL-5234
Project: Camel
Issue Type: Bug
Components: camel-spring-ws
Affects Versions: 2.7.5, 2.8.4, 2.9.2
Reporter: Benjamin Gniza
Assignee: Babak Vahdat
Labels: in, out, out-capable, response, spring-ws
Fix For: 2.9.3, 2.10.0
Spring-WS component does not behave as expected from pipes and filters
pattern if exchange is not _outCapable_.
If _ExchangeHelper_._isOutCapable_ returns false for the given _exchange_ the
IN-message is returned instead of the WS-Response.
Example:
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
In the example above I would expect the WS-response written to the files in
the responses directory. Currently (since 2.7.3) the IN message is written to
the files.
This is caused by _SpringWebserviceProducer#process_ because it only sets
headers and body for the OUT-message if _isOutCapable_ is _true_.
Workaround (maybe this has side effects!):
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setExchangePattern(ExchangePattern.InOut) // -- Override
with InOut Pattern
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
This behavior has been implemented to fix CAMEL-3974. From my point of view
its counter intuitive since other processing-steps don't check the exchange's
_outCapability_.
It took me several hours to find out why I always got the IN message back,
although the webservice was called correctly and returned correct results.
Maybe an option should be provided to control this behavior. At least a
log-message should be written to explain, that the webservice-reponse is
thrown away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-5314) camel jclouds blobstore streaming support
[ https://issues.apache.org/jira/browse/CAMEL-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioannis Canellos reassigned CAMEL-5314: --- Assignee: Ioannis Canellos camel jclouds blobstore streaming support - Key: CAMEL-5314 URL: https://issues.apache.org/jira/browse/CAMEL-5314 Project: Camel Issue Type: Improvement Components: camel-jclouds Affects Versions: 2.9.0, 2.9.1, 2.9.2 Reporter: Ioannis Canellos Assignee: Ioannis Canellos When reading and writing from blob stores the camel jclouds component assumes that that the payload is always a java object. Moreover, it fully reads the object and places it inside the message body. We should provide streaming support, since there is no limit in the size of the payload. We should also make sure that it can handle any type of data and not just java objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-3547) Custom absorbing PropertyPlaceholderConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-3547.
Resolution: Fixed
Updated docs at
https://cwiki.apache.org/confluence/display/CAMEL/Using+PropertyPlaceholder
Custom absorbing PropertyPlaceholderConfigurer
Key: CAMEL-3547
URL: https://issues.apache.org/jira/browse/CAMEL-3547
Project: Camel
Issue Type: New Feature
Components: camel-spring
Affects Versions: 2.5.0
Reporter: Dan Checkoway
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.10.0
I find Camel's property placeholder support clumsy. I already use Spring's
PropertyPlaceholderConfigurer, and I feel like Camel should be able to
harness that. I realize Spring doesn't make it easy to access those
properties, but I have come up with a way to enable Camel to use them...
By simply extending PropertyPlaceholderConfigurer, we will be able to
intercept and absorb the properties that Spring has access to:
{{
import java.util.Properties;
import
org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;
public class CamelPropertyPlaceholderConfigurer extends
PropertyPlaceholderConfigurer {
private final Properties properties = new Properties();
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactory, Properties props) {
super.processProperties(beanFactory, props);
// Absorb all properties that pass through so we can expose them
later
properties.putAll(props);
}
/** Expose all absorbed properties */
public final Properties getProperties() {
return properties;
}
}
}}
It means users who want to take advantage of this would need to instantiate
this instead of the stock PropertyPlaceholderConfigurer, but that's no
problem:
bean class=org.apache.camel.impl.CamelPropertyPlaceholderConfigurer
p:location=.../
/bean
That way, you wouldn't need to declare a duplicating propertyPlaceholer
in the CamelContext. What do you think, is this feasible?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-949) Support for multi-threaded, reliable resequencing.
[ https://issues.apache.org/jira/browse/CAMEL-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-949: - Assignee: (was: Claus Ibsen) Support for multi-threaded, reliable resequencing. -- Key: CAMEL-949 URL: https://issues.apache.org/jira/browse/CAMEL-949 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 1.5.0 Reporter: Martin Krasser Fix For: Future Support for multi-threaded, reliable resequencing has been discussed in [http://www.nabble.com/forum/ViewPost.jtp?post=19344150framed=yskin=22882]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5234) Spring-WS does neither set message body nor message headers if exchange is not outCapable
[
https://issues.apache.org/jira/browse/CAMEL-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288131#comment-13288131
]
Babak Vahdat commented on CAMEL-5234:
-
Now I'm a bit puzzled confused about all these MEP rules :-( Currently we
have the following by SpringWebserviceProducer
{code}
if (ExchangeHelper.isOutCapable(exchange)) {
exchange.getOut().copyFrom(exchange.getIn());
exchange.getOut().setBody(body);
}
{code}
Now do you mean we should change this to
{code}
if (ExchangeHelper.isOutCapable(exchange)) {
exchange.getOut().copyFrom(exchange.getIn());
exchange.getOut().setBody(body);
} else {
exchange.getIn().setBody(body);
}
{code}
And what about camel-restlet? Currently it doesn't care about MEP at all!, See
DefaultRestletBinding.populateExchangeFromRestletResponse()
Also do we have a precise documentation about these MEP rules somewhere?
Spring-WS does neither set message body nor message headers if exchange is
not outCapable
-
Key: CAMEL-5234
URL: https://issues.apache.org/jira/browse/CAMEL-5234
Project: Camel
Issue Type: Bug
Components: camel-spring-ws
Affects Versions: 2.7.5, 2.8.4, 2.9.2
Reporter: Benjamin Gniza
Assignee: Babak Vahdat
Labels: in, out, out-capable, response, spring-ws
Fix For: 2.9.3, 2.10.0
Spring-WS component does not behave as expected from pipes and filters
pattern if exchange is not _outCapable_.
If _ExchangeHelper_._isOutCapable_ returns false for the given _exchange_ the
IN-message is returned instead of the WS-Response.
Example:
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
In the example above I would expect the WS-response written to the files in
the responses directory. Currently (since 2.7.3) the IN message is written to
the files.
This is caused by _SpringWebserviceProducer#process_ because it only sets
headers and body for the OUT-message if _isOutCapable_ is _true_.
Workaround (maybe this has side effects!):
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setExchangePattern(ExchangePattern.InOut) // -- Override
with InOut Pattern
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
This behavior has been implemented to fix CAMEL-3974. From my point of view
its counter intuitive since other processing-steps don't check the exchange's
_outCapability_.
It took me several hours to find out why I always got the IN message back,
although the webservice was called correctly and returned correct results.
Maybe an option should be provided to control this behavior. At least a
log-message should be written to explain, that the webservice-reponse is
thrown away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3547) Custom absorbing PropertyPlaceholderConfigurer
[
https://issues.apache.org/jira/browse/CAMEL-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288145#comment-13288145
]
Dan Checkoway commented on CAMEL-3547:
--
Thanks, Claus!
Custom absorbing PropertyPlaceholderConfigurer
Key: CAMEL-3547
URL: https://issues.apache.org/jira/browse/CAMEL-3547
Project: Camel
Issue Type: New Feature
Components: camel-spring
Affects Versions: 2.5.0
Reporter: Dan Checkoway
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.10.0
I find Camel's property placeholder support clumsy. I already use Spring's
PropertyPlaceholderConfigurer, and I feel like Camel should be able to
harness that. I realize Spring doesn't make it easy to access those
properties, but I have come up with a way to enable Camel to use them...
By simply extending PropertyPlaceholderConfigurer, we will be able to
intercept and absorb the properties that Spring has access to:
{{
import java.util.Properties;
import
org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;
public class CamelPropertyPlaceholderConfigurer extends
PropertyPlaceholderConfigurer {
private final Properties properties = new Properties();
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactory, Properties props) {
super.processProperties(beanFactory, props);
// Absorb all properties that pass through so we can expose them
later
properties.putAll(props);
}
/** Expose all absorbed properties */
public final Properties getProperties() {
return properties;
}
}
}}
It means users who want to take advantage of this would need to instantiate
this instead of the stock PropertyPlaceholderConfigurer, but that's no
problem:
bean class=org.apache.camel.impl.CamelPropertyPlaceholderConfigurer
p:location=.../
/bean
That way, you wouldn't need to declare a duplicating propertyPlaceholer
in the CamelContext. What do you think, is this feasible?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CAMEL-5234) Spring-WS does neither set message body nor message headers if exchange is not outCapable
[
https://issues.apache.org/jira/browse/CAMEL-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288131#comment-13288131
]
Babak Vahdat edited comment on CAMEL-5234 at 6/3/12 11:27 AM:
--
Now I'm a bit confused :-(
Currently we have the following by SpringWebserviceProducer
{code}
if (ExchangeHelper.isOutCapable(exchange)) {
exchange.getOut().copyFrom(exchange.getIn());
exchange.getOut().setBody(body);
}
{code}
Now do you mean we should change this to
{code}
if (ExchangeHelper.isOutCapable(exchange)) {
exchange.getOut().copyFrom(exchange.getIn());
exchange.getOut().setBody(body);
} else {
exchange.getIn().setBody(body);
}
{code}
And what about camel-restlet? Seems it doesn't care about MEP:
https://fisheye6.atlassian.com/browse/~br=trunk/camel/trunk/components/camel-restlet/src/main/java/org/apache/camel/component/restlet/DefaultRestletBinding.java?hb=true#to241
Also do we maybe have a documentation about the MEP rules somewhere?
was (Author: bvahdat):
Now I'm a bit puzzled confused about all these MEP rules :-( Currently we
have the following by SpringWebserviceProducer
{code}
if (ExchangeHelper.isOutCapable(exchange)) {
exchange.getOut().copyFrom(exchange.getIn());
exchange.getOut().setBody(body);
}
{code}
Now do you mean we should change this to
{code}
if (ExchangeHelper.isOutCapable(exchange)) {
exchange.getOut().copyFrom(exchange.getIn());
exchange.getOut().setBody(body);
} else {
exchange.getIn().setBody(body);
}
{code}
And what about camel-restlet? Currently it doesn't care about MEP at all!, See
DefaultRestletBinding.populateExchangeFromRestletResponse()
Also do we have a precise documentation about these MEP rules somewhere?
Spring-WS does neither set message body nor message headers if exchange is
not outCapable
-
Key: CAMEL-5234
URL: https://issues.apache.org/jira/browse/CAMEL-5234
Project: Camel
Issue Type: Bug
Components: camel-spring-ws
Affects Versions: 2.7.5, 2.8.4, 2.9.2
Reporter: Benjamin Gniza
Assignee: Babak Vahdat
Labels: in, out, out-capable, response, spring-ws
Fix For: 2.9.3, 2.10.0
Spring-WS component does not behave as expected from pipes and filters
pattern if exchange is not _outCapable_.
If _ExchangeHelper_._isOutCapable_ returns false for the given _exchange_ the
IN-message is returned instead of the WS-Response.
Example:
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
In the example above I would expect the WS-response written to the files in
the responses directory. Currently (since 2.7.3) the IN message is written to
the files.
This is caused by _SpringWebserviceProducer#process_ because it only sets
headers and body for the OUT-message if _isOutCapable_ is _true_.
Workaround (maybe this has side effects!):
{code:title=ExampleRoute}
from(timer://foo?fixedRate=trueperiod=1000)//
.setExchangePattern(ExchangePattern.InOut) // -- Override
with InOut Pattern
.setBody().simple(ex:getExampleResponse
xmlns:ex=\http://example.com/\; //
+id1/id //
+ /ex:getExampleResponse)//
.to(spring-ws:http://localhost:9000/Example;)//
.to(file://responses);
{code}
This behavior has been implemented to fix CAMEL-3974. From my point of view
its counter intuitive since other processing-steps don't check the exchange's
_outCapability_.
It took me several hours to find out why I always got the IN message back,
although the webservice was called correctly and returned correct results.
Maybe an option should be provided to control this behavior. At least a
log-message should be written to explain, that the webservice-reponse is
thrown away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-5250) Using data format defined in XML and referenced from Java Route may be a problem in blueprint
[ https://issues.apache.org/jira/browse/CAMEL-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-5250: -- Assignee: Claus Ibsen Using data format defined in XML and referenced from Java Route may be a problem in blueprint - Key: CAMEL-5250 URL: https://issues.apache.org/jira/browse/CAMEL-5250 Project: Camel Issue Type: Bug Components: camel-blueprint Affects Versions: 2.8.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.9.3, 2.10.0 See nabble http://camel.465427.n5.nabble.com/How-to-bind-an-object-in-the-registry-camel-tp5686392.html We should add a test case in tests/camel-itest-osgi, for spring-dm and blueprint, that uses a data format defined in the XML, but used from a route builder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-5250) Using data format defined in XML and referenced from Java Route may be a problem in blueprint
[ https://issues.apache.org/jira/browse/CAMEL-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5250. Resolution: Not A Problem Fix Version/s: (was: 2.9.3) Works as designed. You need to define your data formats inside the camelContext tags. Using data format defined in XML and referenced from Java Route may be a problem in blueprint - Key: CAMEL-5250 URL: https://issues.apache.org/jira/browse/CAMEL-5250 Project: Camel Issue Type: Bug Components: camel-blueprint Affects Versions: 2.8.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.10.0 See nabble http://camel.465427.n5.nabble.com/How-to-bind-an-object-in-the-registry-camel-tp5686392.html We should add a test case in tests/camel-itest-osgi, for spring-dm and blueprint, that uses a data format defined in the XML, but used from a route builder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-5309) Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route with ActiveMQ Endpoint and Exclusive Reply Queue
[
https://issues.apache.org/jira/browse/CAMEL-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-5309:
--
Assignee: Claus Ibsen
Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route
with ActiveMQ Endpoint and Exclusive Reply Queue
-
Key: CAMEL-5309
URL: https://issues.apache.org/jira/browse/CAMEL-5309
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-jms
Affects Versions: 2.9.2
Environment: Java 1.6, ActiveMQ 5.6-SNAPSHOT (used in-memory within a
Spring application)
Reporter: Vladimir Tsvetkov
Assignee: Claus Ibsen
When I first instantiate the following route, it works as expected. The
Replies that come have the right correlation ids, just as Camel has assigned
them.
{code}
from(direct:fetchStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + FETCH_INDEX_TIMEOUT)
.threads(10)
.routeId(route-001);
{code}
When this route completes, it is stopped and removed from the camel context.
When a similar route is instantiated:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
Half of the replies come as expected, while the other half results in the
following warning: *Reply received for unknown correlationID*.
A workaround for this issues is to use a different *ReplyTo*-queue for each
new instantiation of a similar route.
E.g. for the second route, it'll work if:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=processedIndecesQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5309) Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route with ActiveMQ Endpoint and Exclusive Reply Queue
[
https://issues.apache.org/jira/browse/CAMEL-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288175#comment-13288175
]
Claus Ibsen commented on CAMEL-5309:
Why are you doing .threads(10) that dont makes sense, if you dont do any
further routing.
Also when you report an issue, then please include more details, and full
stacktraces etc.
The Camel team have to spend a lot of time to track down and reproduce peoples
issues. So do as much upfront work for us.
For example to create a sample unit test that demonstrates the issue.
Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route
with ActiveMQ Endpoint and Exclusive Reply Queue
-
Key: CAMEL-5309
URL: https://issues.apache.org/jira/browse/CAMEL-5309
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-jms
Affects Versions: 2.9.2
Environment: Java 1.6, ActiveMQ 5.6-SNAPSHOT (used in-memory within a
Spring application)
Reporter: Vladimir Tsvetkov
Assignee: Claus Ibsen
When I first instantiate the following route, it works as expected. The
Replies that come have the right correlation ids, just as Camel has assigned
them.
{code}
from(direct:fetchStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + FETCH_INDEX_TIMEOUT)
.threads(10)
.routeId(route-001);
{code}
When this route completes, it is stopped and removed from the camel context.
When a similar route is instantiated:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
Half of the replies come as expected, while the other half results in the
following warning: *Reply received for unknown correlationID*.
A workaround for this issues is to use a different *ReplyTo*-queue for each
new instantiation of a similar route.
E.g. for the second route, it'll work if:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=processedIndecesQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5309) Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route with ActiveMQ Endpoint and Exclusive Reply Queue
[
https://issues.apache.org/jira/browse/CAMEL-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288180#comment-13288180
]
Claus Ibsen commented on CAMEL-5309:
Okay I managed to track down an issue that the reply manager should be disposed
when the route is stopped, so a new is re-created when you add the 2nd route
using the same reply to queue.
Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route
with ActiveMQ Endpoint and Exclusive Reply Queue
-
Key: CAMEL-5309
URL: https://issues.apache.org/jira/browse/CAMEL-5309
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-jms
Affects Versions: 2.9.2
Environment: Java 1.6, ActiveMQ 5.6-SNAPSHOT (used in-memory within a
Spring application)
Reporter: Vladimir Tsvetkov
Assignee: Claus Ibsen
When I first instantiate the following route, it works as expected. The
Replies that come have the right correlation ids, just as Camel has assigned
them.
{code}
from(direct:fetchStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + FETCH_INDEX_TIMEOUT)
.threads(10)
.routeId(route-001);
{code}
When this route completes, it is stopped and removed from the camel context.
When a similar route is instantiated:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
Half of the replies come as expected, while the other half results in the
following warning: *Reply received for unknown correlationID*.
A workaround for this issues is to use a different *ReplyTo*-queue for each
new instantiation of a similar route.
E.g. for the second route, it'll work if:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=processedIndecesQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5327) Upgrade to Hibernate 3.6.6-Final
Christian Müller created CAMEL-5327: --- Summary: Upgrade to Hibernate 3.6.6-Final Key: CAMEL-5327 URL: https://issues.apache.org/jira/browse/CAMEL-5327 Project: Camel Issue Type: Task Components: tests Affects Versions: 2.9.2 Reporter: Christian Müller Assignee: Christian Müller Priority: Minor Fix For: 2.10.0 Hibernate 3.6.x is supported by Spring 3.0.7, so we should use this version for our Hibernate tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-5327) Upgrade to Hibernate 3.6.6-Final
[ https://issues.apache.org/jira/browse/CAMEL-5327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller closed CAMEL-5327. --- Resolution: Fixed Upgrade to Hibernate 3.6.6-Final Key: CAMEL-5327 URL: https://issues.apache.org/jira/browse/CAMEL-5327 Project: Camel Issue Type: Task Components: tests Affects Versions: 2.9.2 Reporter: Christian Müller Assignee: Christian Müller Priority: Minor Fix For: 2.10.0 Hibernate 3.6.x is supported by Spring 3.0.7, so we should use this version for our Hibernate tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4734) Consolidate the database vendors in our unit tests
[
https://issues.apache.org/jira/browse/CAMEL-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288204#comment-13288204
]
Christian Müller commented on CAMEL-4734:
-
If I switch to derby in camel-example-tracer, I got the following exception
(this still happens after upgrading to Hibernate 3.6.6-Final).
I think it's related to [HHH-7264|https://hibernate.onjira.com/browse/HHH-7264]
and block this issue (it's not a show stopper for a new release):
{code}
2012-06-03 18:47:08,819 [read #3 - Split] ERROR JDBCExceptionReporter
- Java exception: 'A truncation error was encountered trying to shrink CLOB
'stream-value' to length 255.:
org.apache.derby.iapi.services.io.DerbyIOException'.
2012-06-03 18:47:08,822 [read #3 - Split] ERROR DefaultTraceEventHandler
- Error processing trace event (original Exchange will continue):
Exchange[Message:
TraceEventMessage[ID-christian-muellers-macbook-pro-fritz-box-50339-1338742006733-0-4]
on node: bean://quoteService?method=quote]
org.springframework.orm.jpa.JpaSystemException:
org.hibernate.exception.GenericJDBCException: could not insert:
[org.apache.camel.processor.interceptor.jpa.JpaTraceEventMessage]; nested
exception is javax.persistence.PersistenceException:
org.hibernate.exception.GenericJDBCException: could not insert:
[org.apache.camel.processor.interceptor.jpa.JpaTraceEventMessage]
at
org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:321)[spring-orm-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:120)[spring-orm-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.springframework.dao.support.DataAccessUtils.translateIfNecessary(DataAccessUtils.java:213)[spring-tx-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.springframework.orm.jpa.JpaAccessor.translateIfNecessary(JpaAccessor.java:152)[spring-orm-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:188)[spring-orm-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:146)[spring-orm-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.apache.camel.component.jpa.JpaTemplateTransactionStrategy$1.doInTransaction(JpaTemplateTransactionStrategy.java:80)[camel-jpa-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)[spring-tx-3.0.7.RELEASE.jar:3.0.7.RELEASE]
at
org.apache.camel.component.jpa.JpaTemplateTransactionStrategy.execute(JpaTemplateTransactionStrategy.java:78)[camel-jpa-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.component.jpa.JpaProducer.process(JpaProducer.java:50)[camel-jpa-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.interceptor.DefaultTraceEventHandler.traceExchange(DefaultTraceEventHandler.java:117)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.interceptor.TraceInterceptor.traceExchange(TraceInterceptor.java:291)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:151)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:333)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:223)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:45)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:303)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:117)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:333)[camel-core-2.10-SNAPSHOT.jar:2.10-SNAPSHOT]
at
[jira] [Commented] (CAMEL-4734) Consolidate the database vendors in our unit tests
[ https://issues.apache.org/jira/browse/CAMEL-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288237#comment-13288237 ] Christian Müller commented on CAMEL-4734: - camel-example-tracer is the last module which use a different database than HSQLDB. Consolidate the database vendors in our unit tests -- Key: CAMEL-4734 URL: https://issues.apache.org/jira/browse/CAMEL-4734 Project: Camel Issue Type: Task Affects Versions: 2.8.3 Reporter: Christian Müller Assignee: Christian Müller Fix For: 2.11 At present, we use HSQL, H2 and Derby in our unit tests (for historically reasons). We should consolidate this and go ahead with Derby because of the issues we had with CAMEL-3371 and CAMEL-4726. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5309) Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route with ActiveMQ Endpoint and Exclusive Reply Queue
[
https://issues.apache.org/jira/browse/CAMEL-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288242#comment-13288242
]
Vladimir Tsvetkov commented on CAMEL-5309:
--
Is .threads(10) makes more sense if the route is:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=processedIndecesQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.to(log:REPLY?level=DEBUG)
.routeId(route-002)
{code}
As to how I reported the issue, I've tried to provide the minimum information
that can describe the issue, and I was waiting to add more (e.g. a unit test)
upon request.
Replies with Incorrect CorrelationIDs Received After Reinstantiating a Route
with ActiveMQ Endpoint and Exclusive Reply Queue
-
Key: CAMEL-5309
URL: https://issues.apache.org/jira/browse/CAMEL-5309
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-jms
Affects Versions: 2.9.2
Environment: Java 1.6, ActiveMQ 5.6-SNAPSHOT (used in-memory within a
Spring application)
Reporter: Vladimir Tsvetkov
Assignee: Claus Ibsen
When I first instantiate the following route, it works as expected. The
Replies that come have the right correlation ids, just as Camel has assigned
them.
{code}
from(direct:fetchStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + FETCH_INDEX_TIMEOUT)
.threads(10)
.routeId(route-001);
{code}
When this route completes, it is stopped and removed from the camel context.
When a similar route is instantiated:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=completionsQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
Half of the replies come as expected, while the other half results in the
following warning: *Reply received for unknown correlationID*.
A workaround for this issues is to use a different *ReplyTo*-queue for each
new instantiation of a similar route.
E.g. for the second route, it'll work if:
{code}
from(direct:processStateStart)
.setExchangePattern(ExchangePattern.InOut)
.to(activemq:queue:tasksQueue?replyTo=processedIndecesQueue +
replyToType=Exclusive +
requestTimeout= + PROCESS_INDEX_TIMEOUT)
.threads(10)
.routeId(route-002);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (CAMEL-5043) Provision for setting a custom SessionStateListener
[ https://issues.apache.org/jira/browse/CAMEL-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-5043 started by Christian Müller. Provision for setting a custom SessionStateListener --- Key: CAMEL-5043 URL: https://issues.apache.org/jira/browse/CAMEL-5043 Project: Camel Issue Type: New Feature Components: camel-smpp Affects Versions: 2.9.0 Reporter: Ranjit Kumar Assignee: Christian Müller Provision for setting a customized SessionStateListener on the SmppProducer and SmppConsumer.This would enable tracking of the connection lost and connection established events with the SMSC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5043) Provision for setting a custom SessionStateListener
[ https://issues.apache.org/jira/browse/CAMEL-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller updated CAMEL-5043: Fix Version/s: 2.10.0 2.9.3 Provision for setting a custom SessionStateListener --- Key: CAMEL-5043 URL: https://issues.apache.org/jira/browse/CAMEL-5043 Project: Camel Issue Type: New Feature Components: camel-smpp Affects Versions: 2.9.0 Reporter: Ranjit Kumar Assignee: Christian Müller Fix For: 2.9.3, 2.10.0 Provision for setting a customized SessionStateListener on the SmppProducer and SmppConsumer.This would enable tracking of the connection lost and connection established events with the SMSC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-5043) Provision for setting a custom SessionStateListener
[ https://issues.apache.org/jira/browse/CAMEL-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller closed CAMEL-5043. --- Resolution: Fixed Provision for setting a custom SessionStateListener --- Key: CAMEL-5043 URL: https://issues.apache.org/jira/browse/CAMEL-5043 Project: Camel Issue Type: New Feature Components: camel-smpp Affects Versions: 2.9.0 Reporter: Ranjit Kumar Assignee: Christian Müller Fix For: 2.9.3, 2.10.0 Provision for setting a customized SessionStateListener on the SmppProducer and SmppConsumer.This would enable tracking of the connection lost and connection established events with the SMSC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
