point with
a matching url pattern can be used together to meet this requirement. This
would be similar to a dispatcher pattern implementation.
Cheers
Jens
-Original Message-
From: Onder SEZGIN [mailto:ondersez...@gmail.com]
Sent: Friday, September 01, 2017 12:26 PM
To: users@camel.apache.org
For a consumer endpoint in Payload mode, you only want the message payload
(ie: body) without the SOAP stuff:
String soap = "8545";
mabahma wrote
> Hello everyBody
> I'm struggling to make the folowing code to work..
>
>
>
> CamelContext context = new DefaultCamelContext()
(35000/6/60/60). The processes responsible
for reading the queue is single-threaded??
Jens
Am 15/04/16 um 14:59 schrieb Michele:
Hi,
I spent a bit of time reading different topics on this issue, and I changed
my route like this reducing the memory usage of about 300Mb
Thanks, both of you.
I can't use the BlueprintBundleContext directly because I may not be running
under Blueprint, but I'll figure something out from these leads.
Claus, the common OsgiCamelContext idea sounds neat.
Jens
--
View this message in context:
http://camel.465427.n5.
Ranx wrote
> There are a variety of ways to do that but what is it you are after
> actually? There may be easier ways to accomplish what you are after. Are
> you using Blueprint? One mechanism is the BlueprintListener. You can
> also get the information and inject it during instantiation and I
Hi,
I'm running Camel in an OSGi container (Karaf). I'd like to get hold of the
OSGi bundle (or bundle name) that the route (or the context) belongs to in
one of my processors.
Is there a way to get that information somehow?
Thanks,
Jens
--
View this message in context:
http://ca
to
track down memory usage and number of objects next
Jens
Am 29/03/16 um 20:11 schrieb Ranx:
Jens,
That's why I suggested setting the limit on the queue size. She has
streaming turned on already so I believe that will block when the queue
(SEDA or JMS) gets full. But 50,000 object
space is left.
see: http://activemq.apache.org/producer-flow-control.html
Jens
Am 29/03/16 um 10:12 schrieb Michele:
Hi,
thanks a lot for your reply.
I changed my route introducing Throttler Pattern like this
t handling the exception in Camel?
Thanks,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/camel-cxf-Accessing-Camel-headers-properties-in-CXF-interceptor-on-exception-tp5770530.html
Sent from the Camel - Users mailing list archive at Nabble.com.
s is my message before
aggregation thus the "grouped_exchange" property is not set. So
regardless what I try it's not possible for me to decide if completion
is complete.
Using "timeout" is no solution as I noticed a timeout can also occur in
the middle of aggregation which leads to an invalid aggregation result
(same keys spread accross two messages).
Any idea to handle aggregation without timeout is welcome.
Thanks in advance
Jens
cache, a SQL
DB, whatever) it's possible to analyze your problem without any further
dependencies, right? So what are you trying to achieve with camel?
Passing messages? In-VM or across multiple machines (like JMS?)?
Jens
Am 14.07.14 18:26, schrieb Jon Mithe:
Hello,
I'm learning a
dditional code until performance really matters
Jens
Am 30.04.14 10:06, schrieb Muhammad Ichsan:
Ah..!
So, in the same JVM, using Java object simply uses an instance
pointer. But if I'm going to produce into an ActiveMQ endpoint, I
should make sure the MQ in the same JVM with vm transport o
keep track about the number of exchanges
combined and the desired chunk size. Maybe you create your own
aggregator derived from AbstractListAggregationStrategy and override
this method:
public Exchange aggregate(Exchange oldExchange, Exchange newExchange)
?
Jens
Am 25.02.14 10:11, schri
Hi Philroc!
if camel does not support it out of the box I would try to write my own
camel processor (internally using java's ProcessBuilder to call a native
application).
Jens
Am 24.11.13 16:06, schrieb Philippe de Rochambeau:
Hello,
I would like to pass arguments to a C applic
Jens wrote
> Hi,
>
> I'm trying to "implement" a CXF JAX-WS service using an XSL
> transformation, ie.
>
> from("cxf:bean:...").to("xslt:...");
>
> The CXF endpoint has a JMSConfiguration with a replyDestination attached
>
n't sent back? Is there anything I need to do to
"prepare" the response message for the CXF endpoint. Fwiw, I also tried
converting the (string) transformation result to a CxfPayload but that
didn't make any difference.
Camel version used is 2.8.4.
Thanks,
Jens
--
View this m
if
the "router" endpoint is JMS as well (and therefore async by default) the
route "hangs" after calling the "realEP" and never returns the response to
the caller. Switching the "router" endpoint to synchronous operation as well
seems to fix that, but is th
typically because
you'll have packages like javax.jms on your classpath twice. Make sure there
is only one, and you should be fine.
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/ActiveMQ-and-WebSphereMQ-tp5721492p5721494.html
Sent from the Camel - Users mailing list archive at Nabble.com.
plied
anyway? I'm currently working around this by setting headers on the route
which do get propagated to endpoint properties but that's somewhat less than
ideal.
Thanks,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Setting-properties-on-Camel-CXF-consumer-endpoints-tp5719195p5719259.html
Sent from the Camel - Users mailing list archive at Nabble.com.
nsumer side? Is there a way to avoid that?
Thanks,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Setting-properties-on-Camel-CXF-consumer-endpoints-tp5719195.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Claus Ibsen-2 wrote
>
> On Wed, May 30, 2012 at 2:09 PM, Jens wrote:
>>
>> Jens wrote
>>>
>>>
>>> Claus Ibsen-2 wrote
>>>>
>>>> Hi
>>>>
>>>> Have you tried enabling stream caching?
>>>> h
Jens wrote
>
>
> Claus Ibsen-2 wrote
>>
>> Hi
>>
>> Have you tried enabling stream caching?
>> http://camel.apache.org/stream-caching.html
>>
>
> Yes, and I also tried converting the message to a String right away but
> neither ch
Claus Ibsen-2 wrote
>
> Hi
>
> Have you tried enabling stream caching?
> http://camel.apache.org/stream-caching.html
>
Yes, and I also tried converting the message to a String right away but
neither change helped.
This is with Camel 2.8.3, by the way.
Jens
--
View this
Interestingly, using onException() does not seem to show the same problem.
Thanks,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/doTry-doCatch-with-original-message-tp5713695.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Björn Bength wrote
>
> Have a look at this:
> https://issues.apache.org/jira/browse/CAMEL-4666
>
Thanks, I'm going to give that a good look when I get some time.
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Using-XML-Catalog-with-XPath-tp5651404p
a way to use one short of writing my own
XPathFactory.
Thanks,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Using-XML-Catalog-with-XPath-tp5651404p5651404.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Kerry Barnes wrote
> How can I get the full envelope to do my transformations against?
Try
from
uri="cxf:bean:ControllerEndpoint?dataFormat=MESSAGE&allowStreaming=true"
Regards,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Access-the-entire-CXF-
ures and interceptors on the bean:
>
> cxf:myCXFBean?address=${in.headers.addressToSendTo}
>
Just use cxf:bean:myEp where myEP is a cxfEndpoint.
Best,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/CXF-endpoint-s-address-dynamically-modified-tp3349431p5540241
ures and interceptors on the bean:
>
> cxf:myCXFBean?address=${in.headers.addressToSendTo}
>
Just use cxf:bean:myEp where myEP is a cxfEndpoint.
Best,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/CXF-endpoint-s-address-dynamically-modified-tp3349431p5540239
ures and interceptors on the bean:
>
> cxf:myCXFBean?address=${in.headers.addressToSendTo}
>
Just use cxf:bean:myEp where myEP is a cxfEndpoint.
Best,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/CXF-endpoint-s-address-dynamically-modified-tp3349431p5540238
ures and interceptors on the bean:
>
> cxf:myCXFBean?address=${in.headers.addressToSendTo}
>
Just use cxf:bean:myEp where myEP is a cxfEndpoint.
Best,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/CXF-endpoint-s-address-dynamically-modified-tp3349431p5540235
ures and interceptors on the bean:
>
> cxf:myCXFBean?address=${in.headers.addressToSendTo}
>
Just use "cxf:bean:myEp" where myEP is a cxfEndpoint.
Best,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/CXF-endpoint-s-address-dynamically-modified-tp33494
Claus Ibsen-2 wrote:
>
> On Thu, Sep 1, 2011 at 6:31 PM, Jens wrote:
>> koseki nonuyuki wrote:
>>> I encountered the same trouble when I got SOAP fault.
>>>
>>> The first processor in the onException route, I put
>>> "exchange.getOu
to me that's what
the onException handler should do already, though.
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Does-onException-not-support-multiple-statements-tp4381958p4759049.html
Sent from the Camel - Users mailing list archive at Nabble.com.
uest]
[myns:param1/]
[myns:param2/]
[/myns:request]
it would be valid and it would be possible to use XPath etc. to work
with it. Currently, I use a custom processor to convert the NodeList
to such a document but it would be nice if there was a way to do this
out of the box.
Regards
s like XPath or XSLT to process PAYLOAD messages.
Thanks,
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/CxfEndpoint-data-formats-tp4631394p4631394.html
Sent from the Camel - Users mailing list archive at Nabble.com.
> #1-3 are correct, for #4, with the fault removed (or converted to an
exception), the exception pipeline
> will not be short-circuited...
>From what I can see that doesn't seem to be true. As I said below I can make
the use case work as intendedby shoving the exception into an exchange
property.
>> Doesn't from("").handleFault() work either?
>
> Building on my previous example I'm assuming it should look like this?
> ...
> If so then no, that doesn't work, either.
I think I should clarify. I'm not quite sure but I believe that what's
happening might be this:
1. The CXF endpoint gets
to(ep).
handleFault();
}
If so then no, that doesn't work, either.
>>> Jens, I think you can use this interceptor to convert faults to
>>> exceptions...see
>>> https://svn.apache.org/repos/asf/c
> Jens, I think you can use this interceptor to convert faults to
> exceptions...see
> https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/FaultRouteTest.java
> this unit test
>
> basically, just add this to your context
> On Wed, May 11, 2011 at 9:03 AM, Jens wrote:
>>
>> I just built a small test case similar to your example and it does indeed
>> work as expected.
>>
>> Unfortunately, my real world case doesn't. Even if I replace proc3 by a
>> simple setBody("Hell
It looks to me like Camel doesn't properly clean up the exchange
and still regards it as failed, therefore breaking out of the pipeline
again.
Any ideas what might be causing this?
Jens
--
View this message in context:
http://camel.465427.n5.nabble.com/Does-onException-not-support
nly the first step of the onException block gets called,
and the result of this call is returned as my reply. Everything thereafter
in the onException block is effectively ignored.
This is using Camel 2.6.0.
Am I doing something wrong?
Thanks,
Jens
--
View this message in context:
http://came
43 matches
Mail list logo
