Re: camel xslt 2.0 support
Have you checked out all the different possibilities outlined under http://camel.apache.org/xslt.html to use Saxon? You can set options on the endpoints or set a JVM property which looks different from what you're setting. Regards, Raúl. Sent from my iPhone On 23 Jun 2012, at 08:03, weather99 wrote: > I tried installing camel-saxon but got the same results. > > I made the following change to ./etc/system.properties: > #javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl > javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl > > This also had no effect. I'm still at the same place. My camel xslt 2.0 > transform returns prolog only. When using a bean xslt 2.0 transformer the > bean returns errors for xslt 2.0 tags. Removing the xalan-2.7.1.jar from > ./ib/endorsed causes my route to fail to load. > > I have no problem getting this to work in standalone Camel. I have been > able to duplicate the problem in standalone Camel by putting a xalan jar > file on my classpath. In that case, the Camel xslt transformer gives me a > prolog only. > > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-xslt-2-0-support-tp5646214p5714932.html > Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel 2.9.1 DeadLetterChannel infinite loop
Hello, It's correct. >From my point of view to break infinite loop you need configure your RedeliveryPolicy without .to(Constants.INBOUND_QUEUE) instruction --Filippo 2012/6/23 E.Gherardini : > My question lies behind the fact that I understood onException clause is used > until the set maximumRedelivery is reached, and then the DLC would come in. > > Is this correct? > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961p5714967.html > Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel 2.9.1 DeadLetterChannel infinite loop
My question lies behind the fact that I understood onException clause is used until the set maximumRedelivery is reached, and then the DLC would come in. Is this correct? -- View this message in context: http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961p5714967.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: data_coding in camel-smpp
Thank you for response. I ended up with issue. Using encoding UTF-16BE is suitable solution. -- View this message in context: http://camel.465427.n5.nabble.com/data-coding-in-camel-smpp-tp5714925p5714966.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel 2.9.1 DeadLetterChannel infinite loop
Ah i forgot to mention that the above route is preceeded by another route,
with its own errorHandler:
[code]
dlcb = new
DeadLetterChannelBuilder(Constants.MAIN_INBONUND_QUEUE+"/deadLetter");
dlcb.setFailureProcessor(new MyLoggingProcessor("Message
Delivery
Failure"));
...
@Override
public void configure() throws Exception {
from(Constants.MAIN_INBONUND_QUEUE)
.errorHandler(dlcb.maximumRedeliveries(redeliveriesCount).redeliveryDelay(redeliveryDelay).onRedelivery(new
MyLoggingProcessor("Message redelivery in progress.")))
.threads(routeExecutionThreadCountCount)
.multicast().parallelProcessing().to(Constants.ANOTHER_QUEUE,
Constants.INBOUND_QUEUE)
;
[code]
and that even if the failure occurs on the second route (the one described
in the previous message) I notice this error handler is also involved, and I
can't figure out why really...
The error I situation I am testing is the "DuplicatedMessageException" one.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961p5714963.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Camel 2.9.1 DeadLetterChannel infinite loop
Hello ,
I am struggling with a strange issue using a simple deadLetterChannel error
handler with some onException clauses.
The route goes into an infinite loop, and debugging (going step by step in
the method "RedeliveryErrorHandler.processErrorHandler(exchange,
asynchcallback, data) )
I observe that the redelivery counter gets always reset to 0.
Here is my route:
{code}
@Override
public void configure() throws Exception {
from(Constants.INBOUND_QUEUE)
.errorHandler(dlcb
.maximumRedeliveries(redeliveriesCount)
.useOriginalMessage()
.redeliveryDelay(redeliveryDelay)
.onRedelivery(
new MyOwnLoggerProcessor(
"Message
Redelivery in progress.")))
.onException(MessageOutOfSyncException.class)
.useOriginalMessage()
.handled(true)
.maximumRedeliveries(redeliveriesCountOutOfSync)
.onRedelivery(
new
MyOwnLoggerProcessor("Requeueing message to "
+
Constants.RDBMS_WRITES_INBOUND_QUEUE))
.to(Constants.INBOUND_QUEUE)
.end()
// this message is duplicated, discard it to dead letter queue
.onException(DuplicatedEventMessageException.class)
.useOriginalMessage()
.handled(true)
.process(
new MyOwnLoggerProcessor(
"Sending
duplicated message to dead letter queue"))
.to(dlcb.getDeadLetterUri())
.end()
.threads(routeExecutionThreadCountCount)
.choice()
.when(body().isInstanceOf(Test1.class))
.process(test1Processor)
// otherwhise we send it to dead letter queue
.otherwise()
.process(new
MyOwnLoggerProcessor("Unhandled Message: "))
.to(dlcb.getDeadLetterUri()).stop()
;
}
{code}
The Dead Letter Queue Builder is constructed in the constructor of my class,
in this way:
{code}
dlcb = new DeadLetterChannelBuilder(
Constants.INBOUND_QUEUE + "/deadLetter");
dlcb.setFailureProcessor(new MyOwnLoggerProcessor(
"Message Delivery Failure"));
{code}
Can someone help me figuring out what's happening ?
Thanks a lot in advance.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-2-9-1-DeadLetterChannel-infinite-loop-tp5714961.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel OSGi services component
Yes, or something even more flexible such as
to("direct-vm:/parent/child")
and for the expression, a simple xpath like:
from("foo:bar").recipientList(directVm("/parent/*"))
or
/parent//*
Just a thought though, not sure if that's really needed.
On Sat, Jun 23, 2012 at 9:18 AM, Claus Ibsen wrote:
> On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky
> wrote:
>> Hello Guillaume,
>>
>> I suppose static method to retrieve consumers that can be filtered by a
>> custom
>> expression will be quite enough.
>>
>
> Yeah that may be a good idea and fairly easy to implement.
>
> The regular direct component could in theory also support this, but I
> guess direct-vm makes the most sense only, as its cross CamelContext
> communication.
>
> The filter expression could also be defined in the uri, if we want to
> consider that, though the foo name would then become a dummy? Or would
> it be to confusing if the name is a filter itself
>
> .to("direct-vm:dummy?filter=someFilterStuffHere")
>
> .to("direct-vm:someFilterStuffHere")
>
>
>
>
>> Regards,
>> Sergey
>>
>>
>>> On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky
>>> wrote:
Hello, guys,
I agree that if the camel-core could be enhanced to achieve easy
cross-context
communication in the single JVM it would be fine.
>>
>>> Claus committed the direct-vm component recently which is part of 2.10:
>>> http://camel.apache.org/direct-vm.html
>>
In that case I would not tire the core to OSGi anyhow to be really
environment-independent.
I suppose that camel context could be published into the JNDI to be
retrieved at some time
lately to discover consuming endpoints. Thus we can achieve the similar
behavior in different
environments and
from("foo:bar").recipientList(osgiServices("myldapfilter"))
would become
from("foo:bar").recipientList(vm("myfilter"))
>>
>>> Atm, the direct-vm queues are not really accessible afaik, so we may
>>> need to enhance the direct-vm slightly to allow retrieving the set of
>>> registered consumers (adding a static getRegisteredConsumers on the
>>> component should be sufficient). Those are mapped by the path
>>> component of the consumer uris, so it already provides some kinda of
>>> tree based structure. If that's sufficient, we would just need a
>>> simple expression that would filter them based on some regular
>>> expression maybe.
>>
Regards,
Sergey
> Agree, I think that enhancing the existing could achieve this.
> Regards
> JB
> On 06/21/2012 08:51 AM, Guillaume Nodet wrote:
>> That's really my main goal. If we fit into what already exists more,
>> we'll be able to better leverage everything.
>>
>> On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider
>> wrote:
>>> +1
>>>
>>> I like that aproach. It would make the OSGi services component a lot
>>> simpler.
>>>
>>>
>>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>
>>> I guess we can use a similar aproach to achieve load balancing. Not
>>> sure if
>>> the example below already would work but I am sure we could make it work
>>> this way or similar:
>>>
>>> from("foo:bar").loadbalance().roundRobin().recepientList(osgiServices("myldapfilter"))
>>>
>>>
>>> Christian
>>>
>>> Am 21.06.2012 08:27, schrieb Guillaume Nodet:
>>>
Yeah, and I agree leveraging OSGi services for that is a good idea.
That's not really what I'm concerned about.
The goal is to have a way to multicast a message to a set of endpoint
which will be discovered at runtime, and that's not really OSGi
specific (though the fact that OSGi has a service registry make that
use case very relevant).
I'd like to reuse what camel-core provides for that instead of going
around and implementing a brand new component.
The dynamic recipient list works with an Expression which returns a
list of endpoints (either Endpoint or string uris), so why not writing
such an expression ? This expression could easily use a
ServiceTracker internally to track changes on services and the
expression itself could be an osgi filter...
from("foo:bar").recipientList(osgiServices("myldapfilter"))
We could even maybe make use of the CamelContext internal registry
which can do some type of discovery (though the osgi implementation is
lacking a lot of stuff).
A simple one would at least be some kind of regular expression that
would match some endpoints. We may need something slightly more
specific for vm:// and direct-vm:// which can be used for
cross-camelContext exchanges.
And sorry if I seem a bit reluctant, I'm just trying to make things
fit
Re: Camel OSGi services component
On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky wrote:
> Hello Guillaume,
>
> I suppose static method to retrieve consumers that can be filtered by a custom
> expression will be quite enough.
>
Yeah that may be a good idea and fairly easy to implement.
The regular direct component could in theory also support this, but I
guess direct-vm makes the most sense only, as its cross CamelContext
communication.
The filter expression could also be defined in the uri, if we want to
consider that, though the foo name would then become a dummy? Or would
it be to confusing if the name is a filter itself
.to("direct-vm:dummy?filter=someFilterStuffHere")
.to("direct-vm:someFilterStuffHere")
> Regards,
> Sergey
>
>
>> On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky
>> wrote:
>>> Hello, guys,
>>>
>>> I agree that if the camel-core could be enhanced to achieve easy
>>> cross-context
>>> communication in the single JVM it would be fine.
>
>> Claus committed the direct-vm component recently which is part of 2.10:
>> http://camel.apache.org/direct-vm.html
>
>>> In that case I would not tire the core to OSGi anyhow to be really
>>> environment-independent.
>>> I suppose that camel context could be published into the JNDI to be
>>> retrieved at some time
>>> lately to discover consuming endpoints. Thus we can achieve the similar
>>> behavior in different
>>> environments and
>>>
>>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>
>>> would become
>>>
>>> from("foo:bar").recipientList(vm("myfilter"))
>>>
>
>> Atm, the direct-vm queues are not really accessible afaik, so we may
>> need to enhance the direct-vm slightly to allow retrieving the set of
>> registered consumers (adding a static getRegisteredConsumers on the
>> component should be sufficient). Those are mapped by the path
>> component of the consumer uris, so it already provides some kinda of
>> tree based structure. If that's sufficient, we would just need a
>> simple expression that would filter them based on some regular
>> expression maybe.
>
>>>
>>> Regards,
>>> Sergey
>>>
>>>
>>>
Agree, I think that enhancing the existing could achieve this.
>>>
Regards
JB
>>>
On 06/21/2012 08:51 AM, Guillaume Nodet wrote:
> That's really my main goal. If we fit into what already exists more,
> we'll be able to better leverage everything.
>
> On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider
> wrote:
>> +1
>>
>> I like that aproach. It would make the OSGi services component a lot
>> simpler.
>>
>>
>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>
>> I guess we can use a similar aproach to achieve load balancing. Not sure
>> if
>> the example below already would work but I am sure we could make it work
>> this way or similar:
>>
>> from("foo:bar").loadbalance().roundRobin().recepientList(osgiServices("myldapfilter"))
>>
>>
>> Christian
>>
>> Am 21.06.2012 08:27, schrieb Guillaume Nodet:
>>
>>> Yeah, and I agree leveraging OSGi services for that is a good idea.
>>> That's not really what I'm concerned about.
>>>
>>> The goal is to have a way to multicast a message to a set of endpoint
>>> which will be discovered at runtime, and that's not really OSGi
>>> specific (though the fact that OSGi has a service registry make that
>>> use case very relevant).
>>> I'd like to reuse what camel-core provides for that instead of going
>>> around and implementing a brand new component.
>>> The dynamic recipient list works with an Expression which returns a
>>> list of endpoints (either Endpoint or string uris), so why not writing
>>> such an expression ? This expression could easily use a
>>> ServiceTracker internally to track changes on services and the
>>> expression itself could be an osgi filter...
>>>
>>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>
>>> We could even maybe make use of the CamelContext internal registry
>>> which can do some type of discovery (though the osgi implementation is
>>> lacking a lot of stuff).
>>> A simple one would at least be some kind of regular expression that
>>> would match some endpoints. We may need something slightly more
>>> specific for vm:// and direct-vm:// which can be used for
>>> cross-camelContext exchanges.
>>>
>>> And sorry if I seem a bit reluctant, I'm just trying to make things
>>> fit more cleanly in camel, and improve camel core where it needs
>>> rather than implementing a new component. It just seems that your
>>> requirements are not really osgi specific and could be made slightly
>>> mode generic.
>>>
>>> On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitsky
>>> wrote:
Hi Guillaume,
Of course if there is more convenient way to communicate between
bundl
Re: SEDA queue max size behaviour
Hi See the blockWhenFull option at http://camel.apache.org/seda The default behavior would be an exception will be thrown if the queue is full. but that option allows you to wait and block instead. On Fri, Jun 22, 2012 at 6:56 PM, Edwin wrote: > Hi Folks, > > If I have a route (route1) where I send messages to a seda queue and I have > another route (route2) that consumes messages from this seda queue and the > maximum size of the queue is set at 1000. > > And, lets say that route2 cannot consume messages from the queue as quick as > route1 is placing them on and the 1000 limit is reached > > I am wondering what will happen to message 1001 coming from route1? > > Will route1 wait until route2 removes enough messages from the queue so that > the current size of the queue is < 1000 - allowing message 1001 to proceed > through the flow? > > Any thoughts are much appreciated > > Thanks, > Edwin > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/SEDA-queue-max-size-behaviour-tp5714933.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: How to achieve both xpath and aggregator
On Fri, Jun 22, 2012 at 10:41 PM, Deepthi wrote: > Hi, > > I am trying to aggregate in the following manner: > > > > > > /order/id > > > > > > > I am using camel 2.8.0. > The above route throws me an exception "Definition has no children on > Aggregate". > > Where am I going wrong? Any help is appreciated. > You need to put these inside the aggregate tag. That means when the message is being sent out of the aggregator its routed to the bean and file. > Thanks, > Deepthi > > -- > View this message in context: > http://camel.465427.n5.nabble.com/How-to-achieve-both-xpath-and-aggregator-tp5714691p5714941.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: Lazy Camel...
Hi Christian wish you a nice as well as recreative weekend too :-) Babak -- View this message in context: http://camel.465427.n5.nabble.com/Lazy-Camel-tp5714949p5714951.html Sent from the Camel - Users mailing list archive at Nabble.com.
SEDA queue max size behaviour
Hi Folks, If I have a route (route1) where I send messages to a seda queue and I have another route (route2) that consumes messages from this seda queue and the maximum size of the queue is set at 1000. And, lets say that route2 cannot consume messages from the queue as quick as route1 is placing them on and the 1000 limit is reached I am wondering what will happen to message 1001 coming from route1? Will route1 wait until route2 removes enough messages from the queue so that the current size of the queue is < 1000 - allowing message 1001 to proceed through the flow? Any thoughts are much appreciated Thanks, Edwin -- View this message in context: http://camel.465427.n5.nabble.com/SEDA-queue-max-size-behaviour-tp5714933.html Sent from the Camel - Users mailing list archive at Nabble.com.
RE: camel xslt 2.0 support
I tried installing camel-saxon but got the same results. I made the following change to ./etc/system.properties: #javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl This also had no effect. I'm still at the same place. My camel xslt 2.0 transform returns prolog only. When using a bean xslt 2.0 transformer the bean returns errors for xslt 2.0 tags. Removing the xalan-2.7.1.jar from ./ib/endorsed causes my route to fail to load. I have no problem getting this to work in standalone Camel. I have been able to duplicate the problem in standalone Camel by putting a xalan jar file on my classpath. In that case, the Camel xslt transformer gives me a prolog only. -- View this message in context: http://camel.465427.n5.nabble.com/camel-xslt-2-0-support-tp5646214p5714932.html Sent from the Camel - Users mailing list archive at Nabble.com.
