Camel-CXF will generate invalid XML in some cases
Hi, I am currently trying to debug an issue that is actually driving me crazy. I am calling a web service from a camel cxf endpoint in payload mode that returns data that uses a namespace in an attribute name that is defined on the SOAP envelope of the response. If I convert the CxfPayload into a String, the XML will be invalid because the namespace definition is missing. The response message looks like this: ?xml version=1.0 encoding=UTF-8? soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soap:Body ns1:getSeedResponse xmlns:ns1=https://maullin.sii.cl/DTEWS/CrSeed.jws; getSeedReturn xsi:type=xsd:stringResponseData/getSeedReturn /ns1:getSeedResponse /soap:Body /soap:Envelope The converted payload (as a String) will then look like that ns1:getSeedResponse xmlns:ns1=https://maullin.sii.cl/DTEWS/CrSeed.jws;getSeedReturn xsi:type=xsd:stringResponseData/getSeedReturn/ns1:getSeedResponse If you try any XML operation on this (like an XPath) the parser will complain that the xsi namespace prefix is undefined. The route looks like that: camel:route camel:from uri=file:///tmp/chile/poller / camel:to uri=cxf:bean:SII_SEED_SII_GET_SEED / camel:convertBodyTo type=java.lang.String/ camel:to uri=file:///tmp/chile/receiver?flatten=true / /camel:route and the endpoint is defined like that: cxf:cxfEndpoint address=http://localhost:8080/cxf/getSeedDummyService; endpointName=orange:MessageFlow_2 id=SII_SEED_SII_GET_SEED cxf:properties entry key=dataFormat value=PAYLOAD / entry key=synchronous value=true / /cxf:properties /cxf:cxfEndpoint My analysis so far is that the Source that is transferred from a CXF Message object to a Camel CxfPayload object is a StaxSource (the CXF class). If I try similar things in Camel-CXF unit tests, the source seems to be a DOMSource for some reason (and there is some special code for namespace handling in DefaultCxfBinding for that). However I have not managed to figure out where the SOAP envelop is read in payload mode and how to get a proper transformation in to anything flat that does not lose the namespace but does not parse the whole thing into a DOM tree (which is pretty huge). It am also under the impression that Woodstox does also play some role in this context (the XMLStreamReader behind the StaxSource is from Woodstox and this does not return these outer namespaces with the getNamespaceCount() method. Does anybody have an idea how to proceed here? Best regards Stephan
SOAP headers not relayed for a SOAP 1.2 service when using CXF component
Hi!
I'm using Camel 2.15.0 and the CXF component (CXF 3.0.4) to call a SOAP 1.2
web service in PAYLOAD mode. The call in itself works fine, however
necessary out of band soap headers (i.e. not defined in the contract) are
not relayed to the service endpoint for some reason.
In the log I can see the following trace message :
TRACE org.apache.camel.component.cxf.DefaultCxfBinding - Propagate
SOAP/protocol header:
{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
: [wsse:Security: null]
But at the server side all I get are the typical SOAP 1.2 addressing headers
(Action, ReplyTo etc) which the cxf component seems to have generated for
me, and all the other soap headers are gone. I've used wireshark to
determine that the problem seem to be in the CXF consumer somewhere.
I have a similar use case calling a SOAP 1.1 web service and there soap
header relaying works fine.
Any ideas why the soap headers aren't relayed in my cxf client?
--
View this message in context:
http://camel.465427.n5.nabble.com/SOAP-headers-not-relayed-for-a-SOAP-1-2-service-when-using-CXF-component-tp5765823.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Getting list of contexts or getting context by name
Hi, I'm working on a solution where I dynamically setup/remove routes based on external configuration. So far so good, it works good, a manager route handles this just good. A thought would be to place the dynamic routes in another context. I can create new contexts from within the Java without problem but I can't seem to find a way to either list the active contexts and/or get a context by its name. Also, are there any drawbacks on using another CamelContext instead of placing it all in the same one where the manager route also runs? Thanks /Gustav
Re: Virtual Topic isn't working
Do I also need to change the Camel side to publish to a queue instead of a topic? No you do not. Seems perhaps that you're confused. The fact that you're using a virtual topic, rather than a durable topic subscription, doesn't change the fact that messages should still be published to a topic. After all, it's still pub-sub semantics that you're looking for, albeit achieved using virtual topics. If pub-sub semantics are not what you want then don't bother with either virtual topics or durable topic subscriptions and just use queues. Thanks, Paul On Tue, Apr 14, 2015 at 9:37 PM, hayden74 hdr...@gmail.com wrote: Thanks Paul, I will give it another go when I get home. Do I also need to change the Camel side to publish to a queue instead of a topic? eg:change Camel side from from(jms:queue:foo).to(activemq:topic:VirtualTopic.bar); to from(jms:queue:foo).to(activemq:queue:VirtualTopic.bar); Thanks again for your help -- View this message in context: http://camel.465427.n5.nabble.com/Virtual-Topic-isn-t-working-tp5765762p5765795.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel-CXF will generate invalid XML in some cases
Hi Stephan, How did you turn the payload body into String? If you use the CxfPayload.getBody() you should get the a list of element which namespaces are set rightly. The PayLoadDataFormatFeature[1] just setup the interceptors for CXF to avoid processing the message part. I guess that is the missing pice that you want to know :) [1]https://github.com/apache/camel/blob/master/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/feature/PayLoadDataFormatFeature.java -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 15, 2015 at 10:21:38 PM, Siano, Stephan (stephan.si...@sap.com) wrote: Hi, I am currently trying to debug an issue that is actually driving me crazy. I am calling a web service from a camel cxf endpoint in payload mode that returns data that uses a namespace in an attribute name that is defined on the SOAP envelope of the response. If I convert the CxfPayload into a String, the XML will be invalid because the namespace definition is missing. The response message looks like this: xsi:type=xsd:stringResponseData If you try any XML operation on this (like an XPath) the parser will complain that the xsi namespace prefix is undefined. The route looks like that: and the endpoint is defined like that: address=http://localhost:8080/cxf/getSeedDummyService; endpointName=orange:MessageFlow_2 id=SII_SEED_SII_GET_SEED My analysis so far is that the Source that is transferred from a CXF Message object to a Camel CxfPayload object is a StaxSource (the CXF class). If I try similar things in Camel-CXF unit tests, the source seems to be a DOMSource for some reason (and there is some special code for namespace handling in DefaultCxfBinding for that). However I have not managed to figure out where the SOAP envelop is read in payload mode and how to get a proper transformation in to anything flat that does not lose the namespace but does not parse the whole thing into a DOM tree (which is pretty huge). It am also under the impression that Woodstox does also play some role in this context (the XMLStreamReader behind the StaxSource is from Woodstox and this does not return these outer namespaces with the getNamespaceCount() method. Does anybody have an idea how to proceed here? Best regards Stephan
JPA-Endpoint in onException is not committed
Hi folks,
I have the following RouteBuilder:
onException(Throwable.class)
.handled(true)
.bean(orderStateChanger, changeOrderStateToWaiting)
.to(jpa:Order);
from(jms:order_queue)
.routeId(Order_Route)
.transacted()
.setHeader(ORDER_ID_HEADER, simple(${body}))
.bean(orderByIdReader)
.process(orderMapper)
.to(cxf:bean:orderWebService)
.process(postOrderProcessor);
The route reads an orderId from a jms-queue, sets this id to a header for
later use and enriches the message with the order read from the database.
Then the order ist mapped and send to a webservice. After returning some
postprocessing is done. All unittest using CamelSpringTestSupport work well.
So far so good.
Now integrating the solution in the real world shows some strange behaviour:
If an exception is thrown by the webservice the onException kicks in and the
StateChangerBean is called.
BUT: the change seems never to be committed. I thought that using the
jpa-component inside a springcontext would manage to handle all the tx-magic
but obviously that's not the case. Instead I see the following output in the
log:
TransactionErrorHandler - Transaction commit (0x550d4ee1) redelivered(true)
for (MessageId: ID:1D4923BFB6FF48CF997D5353C351D271
I studied the documentation, but perhaps I searched in the wrong places? As
we say in german: Can anybody help me climb the correct camel, please?
Regards,
Frank
--
View this message in context:
http://camel.465427.n5.nabble.com/JPA-Endpoint-in-onException-is-not-committed-tp5765832.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Spring Boot component is missing CamelSpringBootApplicationController
Hi,
Just add spring-boot-starter-web to your project. It will block the main
thread. Or camel-boot-starter-remote-shell. I didn't backported CAMEL-8532
https://issues.apache.org/jira/browse/CAMEL-8532 because it is as easy to
block the main thread. I personally always add spring-boot-starter-web to
the app to have a Jolokia endpoint exposed.
Cheers.
wt., 7 kwi 2015 o 08:23 użytkownik Claus Ibsen claus.ib...@gmail.com
napisał:
Hi
Yeah wonder if we can backport this to 2.15.2.
Henryk any thoughts on this?
On Tue, Apr 7, 2015 at 1:51 AM, ccampo cca...@gmail.com wrote:
Just a follow up - it appears that CamelSpringBootApplicationController
won't
be available until 2.16.0, per
https://issues.apache.org/jira/browse/CAMEL-8532. Unfortunately, this
renders the Camel Spring Boot component effectively broken until then.
A work-around for anybody encountering this issue is just to write the
code
yourself. Create a the class CamelSpringBootApplicationController.java
somewhere in your codebase using the code
https://github.com/apache/camel/blob/master/components/camel-spring-boot/src/main/java/org/apache/camel/spring/boot/CamelSpringBootApplicationController.java
(and of course, follow the license and give credit where it's due). Then
in
your main method, just use the code:
final ApplicationContext applicationContext = new
SpringApplication(MainClass.class).run(args);
final CamelSpringBootApplicationController applicationController
=
applicationContext.getBean(CamelSpringBootApplicationController.class);
applicationController.blockMainThread();
... similar to what's shown in
https://github.com/apache/camel/blob/master/components/camel-spring-boot/src/main/java/org/apache/camel/spring/boot/FatJarRouter.java
(again, follow the license).
Finally declare a bean of type CamelSpringBootApplicationController, like
so:
@Bean
public CamelSpringBootApplicationController
applicationController(final
ApplicationContext applicationContext,
final CamelContext camelContext) {
return new
CamelSpringBootApplicationController(applicationContext,
camelContext);
}
Everything should be OK then.
--
View this message in context:
http://camel.465427.n5.nabble.com/Spring-Boot-component-is-missing-CamelSpringBootApplicationController-tp5765405p5765406.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8 http://hawt.io/fabric8: http://fabric8.io/
RE: Bi-directional comms on TCP connection
Hi Willem, I look at the code and your unit test NettyConsumerClientModeTest but still don't quite follow why clientMode can help with the case that Carl described. How can the consumer-server connects to the client-device in the first place? Can you explain the magic there? Thanks, -Quoc -Original Message- From: Willem Jiang [mailto:willem.ji...@gmail.com] Sent: Wednesday, April 15, 2015 3:00 AM To: users@camel.apache.org Subject: Re: Bi-directional comms on TCP connection We implement CAMEL-1077[1] in camel-2.15.x recently, so the ESB can talk to the device as a client to receive the events. But now the miss part is how can we share the channel between netty consumer and the netty producer. [1]https://issues.apache.org/jira/browse/CAMEL-1077 -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 14, 2015 at 11:33:13 PM, Carl Nygard (cjnyg...@gmail.com) wrote: I have a question about the Mina/Netty TCP connector in Camel. Can Mina/Netty handle bi-directional comms through Camel, or do we need to handle this type of interface externally? We have embedded devices (button/light combo) that will consume TCP messages to light a device and initiate messages to indicate button press events. In other words, the device is the server, but will also spontaneously generate event messages back to the client/ESB. Both sides (server/device,client/ESB) expect ACKs for messages. So in essence, it is a 2-way communication using 1 TCP connection, initiated by ESB. Unfortunately, Camel Netty and Mina doesn’t have the capability to support 2-way asynchronous (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s still open ticket rom 2010, 2012 + this is the duplicated ticket with some more context: https://issues.apache.org/jira/browse/CAMEL-1075 ) What we have tried so far: 1. synchronous channel (before realize the limitation above): This will always require our ESB-EndPoint to initiate the conversation, good to receive ACK, but not allowing device to send Event message at will. 2. asynchronous channel: (http://camel.apache.org/async.html ) With async model, we can send request, do something else and let the async callback to process the reply. However, we still have a 1-1 relationship between request and reply, and so in order to allow device to “initiate” the Event message, ESB-Endpoint will need to send more “no-op requests” to device-Endpoint, to catch for ACK and Event message. This solution is not beautiful (quite hacking), and will not work if there’s no “no-op operation” (e.g. device will ACK on all messages sent). 3. Look at examples in these 2 books: “Camel in Actions” ( https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf ) and “Apache Camel Developer’s Cookbook” ( https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer %20Cookbook.pdf ) but not much light on the issue we are facing. Any help? --carl
Re: Handling splitting and error handling
handled(true) just tell camel to keep on processing the message as the error is recovered. So I think you still need use handled(false) in your onException. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 15, 2015 at 5:22:21 PM, blommish (johanblomgren1...@gmail.com) wrote: So well, this can be handled by using transacted() after picking up the message from direct:inbound, making it look like: from(direct:inbound) .transacted() .multicast().parallelProcessing().to(direct:a, direct:b); But there's another issue then. If I have onException(Exception.class).handled(true).useOriginalMessage().to(jms:errorQueue) It WILL not rollback the messages from the endpoints, for example if it fails to validate for message a, it will still send the message b to q3 and q4. But when having handled(false) it will not. But then it *will also rollback the message to the inbound queue* AND post it to the errorQueue? -- View this message in context: http://camel.465427.n5.nabble.com/Handling-splitting-and-error-handling-tp5765748p5765819.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-ftp 2.15.1 return ftp error code 421
I think you may need to find another way to pull the sub directory instead of pulling root directory directly. -- View this message in context: http://camel.465427.n5.nabble.com/camel-ftp-2-15-1-return-ftp-error-code-421-tp5765272p5765843.html Sent from the Camel - Users mailing list archive at Nabble.com.
The Camel Kafka component crashes with a NoClassDefFoundError exception.
The Camel Kafka component crashes with a NoClassDefFoundError exception. If you define a Camel route which uses the Camel Kafka component, it will crash when running with a NoClassDefFoundError. I've tracked this down to the project that uses camel-kafka 2.15.1 also requires an explicit dependency on scala-library 2.10.2. This dependency is not mentioned anywhere in the documentation. Here's the error that occurs when the Scala dependency is missing: Here's the route I'm using: My project is using Spring Boot 1.2.3 and Camel 2.15.1. Would you like me to open a JIRA ticket for this to be resolved? -- View this message in context: http://camel.465427.n5.nabble.com/The-Camel-Kafka-component-crashes-with-a-NoClassDefFoundError-exception-tp5765829.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Simple expression not evaluated in Spring DSL setProperty
You cannot use dynamic values in the headerName / propertyName.
On Wed, Apr 15, 2015 at 11:34 AM, rsteppac2 r...@steppacher.name wrote:
Hello all,
is this supposed to work?
setProperty
propertyName=$simple{type:my.domain.StringConstants.EXCHANGE_PROP_TX_FAILED}
simple${type:java.lang.Boolean.TRUE}/simple
/setProperty
StringConstants.EXCHANGE_PROP_TX_FAILED := exchange_prop_tx_failed
The property name is not evaluated to the string exchange_prop_tx_failed.
Instead the expression is used verbatim as the property name.
The property value is evaluated to Boolean.TRUE as expected.
Using log
message=$simple{type:my.domain.StringConstants.EXCHANGE_PROP_TX_FAILED}...
prints the expected value exchange_prop_tx_failed to the log.
Ralf
--
View this message in context:
http://camel.465427.n5.nabble.com/Simple-expression-not-evaluated-in-Spring-DSL-setProperty-tp5765820.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: SOAP headers not relayed for a SOAP 1.2 service when using CXF component
Thanks for reply.
The particular header in this example is a security/saml-token. But I've
also tried adding headers according to the example here, and neither are
passed to the endpoint:
http://camel.apache.org/cxf.html
Again, all headers are passed successfully to a similar soap 1.1 endpoint.
I've configured the endpoint using the Java DSL similar to this:
.to(cxf://http://urlOfMyService?wsdlURL=wsdl/service.wsdldataFormat=PAYLOADendpointName={urn:test:namespace}MyServiceSOAPserviceName={urn:test:namespace}MyServiceskipFaultLogging=true;)
Camel/CXF figures out the correct binding from the WSDL I guess? Seems to be
correct anyway, as the actual invoking of the service works fine apart from
the lost out of band soap headers.
Soap action are set like this:
exchange.getIn().setHeader(CxfConstants.OPERATION_NAME, query);
exchange.getIn().setHeader(CxfConstants.OPERATION_NAMESPACE,
urn:test:namespace);
--
View this message in context:
http://camel.465427.n5.nabble.com/SOAP-headers-not-relayed-for-a-SOAP-1-2-service-when-using-CXF-component-tp5765823p5765846.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: Bi-directional comms on TCP connection
First the Netty or Mina Consumer works in clientMode just connect the address of the device as a client when the route is started, then it can keep receiving the event from the device. If the consumer doesn’t work in clientMode, it just start a server which listen to address and wait for the client to connect. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 16, 2015 at 7:30:45 AM, Quoc Le (quo...@fortna.com) wrote: Hi Willem, I look at the code and your unit test NettyConsumerClientModeTest but still don't quite follow why clientMode can help with the case that Carl described. How can the consumer-server connects to the client-device in the first place? Can you explain the magic there? Thanks, -Quoc -Original Message- From: Willem Jiang [mailto:willem.ji...@gmail.com] Sent: Wednesday, April 15, 2015 3:00 AM To: users@camel.apache.org Subject: Re: Bi-directional comms on TCP connection We implement CAMEL-1077[1] in camel-2.15.x recently, so the ESB can talk to the device as a client to receive the events. But now the miss part is how can we share the channel between netty consumer and the netty producer. [1]https://issues.apache.org/jira/browse/CAMEL-1077 -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 14, 2015 at 11:33:13 PM, Carl Nygard (cjnyg...@gmail.com) wrote: I have a question about the Mina/Netty TCP connector in Camel. Can Mina/Netty handle bi-directional comms through Camel, or do we need to handle this type of interface externally? We have embedded devices (button/light combo) that will consume TCP messages to light a device and initiate messages to indicate button press events. In other words, the device is the server, but will also spontaneously generate event messages back to the client/ESB. Both sides (server/device,client/ESB) expect ACKs for messages. So in essence, it is a 2-way communication using 1 TCP connection, initiated by ESB. Unfortunately, Camel Netty and Mina doesn’t have the capability to support 2-way asynchronous (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s still open ticket rom 2010, 2012 + this is the duplicated ticket with some more context: https://issues.apache.org/jira/browse/CAMEL-1075 ) What we have tried so far: 1. synchronous channel (before realize the limitation above): This will always require our ESB-EndPoint to initiate the conversation, good to receive ACK, but not allowing device to send Event message at will. 2. asynchronous channel: (http://camel.apache.org/async.html ) With async model, we can send request, do something else and let the async callback to process the reply. However, we still have a 1-1 relationship between request and reply, and so in order to allow device to “initiate” the Event message, ESB-Endpoint will need to send more “no-op requests” to device-Endpoint, to catch for ACK and Event message. This solution is not beautiful (quite hacking), and will not work if there’s no “no-op operation” (e.g. device will ACK on all messages sent). 3. Look at examples in these 2 books: “Camel in Actions” ( https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf ) and “Apache Camel Developer’s Cookbook” ( https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer %20Cookbook.pdf ) but not much light on the issue we are facing. Any help? --carl
Re: camel-ftp 2.15.1 return ftp error code 421
The first connection is used to check if the ftp server is still alive before starting to pull the directory. If the RemoteFileConsumer cannot connect to the server, it just return the pulling process and wait for another pulling. -- View this message in context: http://camel.465427.n5.nabble.com/camel-ftp-2-15-1-return-ftp-error-code-421-tp5765272p5765842.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: SOAP headers not relayed for a SOAP 1.2 service when using CXF component
How did you specify the SOAP 1.2 binding in your camel-cxf endpoint?
What kind of soap header were lost?
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 15, 2015 at 9:28:44 PM, _redwings (eriknygre...@gmail.com) wrote:
Hi!
I'm using Camel 2.15.0 and the CXF component (CXF 3.0.4) to call a SOAP 1.2
web service in PAYLOAD mode. The call in itself works fine, however
necessary out of band soap headers (i.e. not defined in the contract) are
not relayed to the service endpoint for some reason.
In the log I can see the following trace message :
TRACE org.apache.camel.component.cxf.DefaultCxfBinding - Propagate
SOAP/protocol header:
{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
: [wsse:Security: null]
But at the server side all I get are the typical SOAP 1.2 addressing headers
(Action, ReplyTo etc) which the cxf component seems to have generated for
me, and all the other soap headers are gone. I've used wireshark to
determine that the problem seem to be in the CXF consumer somewhere.
I have a similar use case calling a SOAP 1.1 web service and there soap
header relaying works fine.
Any ideas why the soap headers aren't relayed in my cxf client?
--
View this message in context:
http://camel.465427.n5.nabble.com/SOAP-headers-not-relayed-for-a-SOAP-1-2-service-when-using-CXF-component-tp5765823.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Getting list of contexts or getting context by name
I just assume the context means Camel Context, am I right? If you create the Camel Context you need to manage it yourself. I don’t think it is possible to look up the other Camel Context from the route which only knows about the CamelContext holds it. There are some components can only be used to talk each other within the same CamelContext, such as seda, direct. And we use these component to glue the routes. So my suggestion is you keep the dynamic routes in the same CamelContext, unless you don’t want them talk to each other. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 15, 2015 at 9:38:42 PM, Gustav Sinder (gustav.sin...@ferrologic.se) wrote: Hi, I'm working on a solution where I dynamically setup/remove routes based on external configuration. So far so good, it works good, a manager route handles this just good. A thought would be to place the dynamic routes in another context. I can create new contexts from within the Java without problem but I can't seem to find a way to either list the active contexts and/or get a context by its name. Also, are there any drawbacks on using another CamelContext instead of placing it all in the same one where the manager route also runs? Thanks /Gustav
Re: Bindy running within a WAR
I tried deploying the war in ... wildfly-camel-patch option ...I'm getting LinkageError exception I'm using ContextLoaderListener to load the camel context. dependency groupIdorg.springframework/groupId artifactIdspring-web/artifactId version4.1.5.RELEASE/version /dependency wildfly-camel-patch also contains 4.1.5.RELEASE. thanks Ravi. -- View this message in context: http://camel.465427.n5.nabble.com/Bindy-running-within-a-WAR-tp5765035p5765831.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Splitter file name automatic generation
Thanks for the useful info. I was trying to create a route that dynamically
generates filename based on attributes in xml and this post helped.
Below is the route that worked for me:
from uri=mdw:REST/REST/
setHeader
headerName=OrderNumberxpath/Envelope/Header/text()/xpath/setHeader
to uri=file:data/inbox?fileName=${header.OrderNumber}.xml pattern=InOut
/
This reads request coming to a REST webservice endpoint, parses value in
Header element and uses it to create dynamic file name.
--
View this message in context:
http://camel.465427.n5.nabble.com/Splitter-file-name-automatic-generation-tp4754576p5765825.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Bi-directional comms on TCP connection
We implement CAMEL-1077[1] in camel-2.15.x recently, so the ESB can talk to the device as a client to receive the events. But now the miss part is how can we share the channel between netty consumer and the netty producer. [1]https://issues.apache.org/jira/browse/CAMEL-1077 -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On April 14, 2015 at 11:33:13 PM, Carl Nygard (cjnyg...@gmail.com) wrote: I have a question about the Mina/Netty TCP connector in Camel. Can Mina/Netty handle bi-directional comms through Camel, or do we need to handle this type of interface externally? We have embedded devices (button/light combo) that will consume TCP messages to light a device and initiate messages to indicate button press events. In other words, the device is the server, but will also spontaneously generate event messages back to the client/ESB. Both sides (server/device,client/ESB) expect ACKs for messages. So in essence, it is a 2-way communication using 1 TCP connection, initiated by ESB. Unfortunately, Camel Netty and Mina doesn’t have the capability to support 2-way asynchronous (https://issues.apache.org/jira/browse/CAMEL-2624 - It’s still open ticket rom 2010, 2012 + this is the duplicated ticket with some more context: https://issues.apache.org/jira/browse/CAMEL-1075 ) What we have tried so far: 1. synchronous channel (before realize the limitation above): This will always require our ESB-EndPoint to initiate the conversation, good to receive ACK, but not allowing device to send Event message at will. 2. asynchronous channel: (http://camel.apache.org/async.html ) With async model, we can send request, do something else and let the async callback to process the reply. However, we still have a 1-1 relationship between request and reply, and so in order to allow device to “initiate” the Event message, ESB-Endpoint will need to send more “no-op requests” to device-Endpoint, to catch for ACK and Event message. This solution is not beautiful (quite hacking), and will not work if there’s no “no-op operation” (e.g. device will ACK on all messages sent). 3. Look at examples in these 2 books: “Camel in Actions” ( https://dl.dropboxusercontent.com/u/3786274/Camel%20In%20Action.pdf ) and “Apache Camel Developer’s Cookbook” ( https://dl.dropboxusercontent.com/u/3786274/Apache%20Camel%20Developer%20Cookbook.pdf ) but not much light on the issue we are facing. Any help? --carl
Re: Why so many port used when I use camel-netty4-http
Hi,Willem Thanks for your help! I think I need to read the document carefully first. Again, thank you! -- View this message in context: http://camel.465427.n5.nabble.com/Why-so-many-port-used-when-I-use-camel-netty4-http-tp5765433p5765810.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Handling splitting and error handling
So well, this can be handled by using transacted() after picking up the message from direct:inbound, making it look like: from(direct:inbound) .transacted() .multicast().parallelProcessing().to(direct:a, direct:b); But there's another issue then. If I have onException(Exception.class).handled(true).useOriginalMessage().to(jms:errorQueue) It WILL not rollback the messages from the endpoints, for example if it fails to validate for message a, it will still send the message b to q3 and q4. But when having handled(false) it will not. But then it *will also rollback the message to the inbound queue* AND post it to the errorQueue? -- View this message in context: http://camel.465427.n5.nabble.com/Handling-splitting-and-error-handling-tp5765748p5765819.html Sent from the Camel - Users mailing list archive at Nabble.com.
Simple expression not evaluated in Spring DSL setProperty
Hello all,
is this supposed to work?
setProperty
propertyName=$simple{type:my.domain.StringConstants.EXCHANGE_PROP_TX_FAILED}
simple${type:java.lang.Boolean.TRUE}/simple
/setProperty
StringConstants.EXCHANGE_PROP_TX_FAILED := exchange_prop_tx_failed
The property name is not evaluated to the string exchange_prop_tx_failed.
Instead the expression is used verbatim as the property name.
The property value is evaluated to Boolean.TRUE as expected.
Using log
message=$simple{type:my.domain.StringConstants.EXCHANGE_PROP_TX_FAILED}...
prints the expected value exchange_prop_tx_failed to the log.
Ralf
--
View this message in context:
http://camel.465427.n5.nabble.com/Simple-expression-not-evaluated-in-Spring-DSL-setProperty-tp5765820.html
Sent from the Camel - Users mailing list archive at Nabble.com.
