On Fri, Mar 6, 2009 at 4:30 PM, beduin wrote:
>
> Hi, I'm building a routing like this :
>
> from jetty to
> splitter to
> aggegator to
> responseProcessor to
> mockend
>
> each endpoint is set to InOut and direct.
> Basically I want that request from jetty (that's like a batch to process)
> being
Hello, I have custom endpoints developed that I would like to expose as
mbeans through JMX. Currently, only the attributes of ManagedEndpoint show
up. What is the easiest way to get a custom endpoint exposed in jmx while
piggy-backing off the existing mbean server/naming strategy/etc supplied by
Hi.
I have a multithreaded environment using Camel's Mina component with Spring
Remoting as following:
I am getting unexpected results. One calling thread consumes a result
intended for different calling thread, etc. It looks like t
The classes have been renamed lately in Camel. xxxType is now named
xxxDefinition.
So you need to update all camel jars in your container. Also camel-spring
On Mon, Mar 9, 2009 at 4:01 PM, cmoulliard wrote:
>
> Hi,
>
> When I deploy the following routes on SMX4,
>
>
> http://www.springframewor
Hi,
When I deploy the following routes on SMX4,
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:cxf="http://camel.apache.org/schema/cxf";
xsi:schemaLocation="
Hi Charles,
Yup - you don't have a broker started ,so it can't make the connect
when you use "tcp://localhost:61616" as the broker Url.
When you use the vm://localhost URL, ActiveMQ will lazily create a
broker for you in the current JVM, so that's why it's working in that
case.
Best,
Ad
Hi,
Can someone tell me why I receive the following error :
2009-03-09 14:23:07,921 DEBUG TcpTransport - Stopping transport tcp://null:0
2009-03-09 14:23:07,921 DEBUG DefaultMessageListenerContainer - Could not
establish shared JMS Connection - leaving it up to asynchronous invokers to
establi
Hi Christian,
I've got a sample of a batch file/ftp processor in my demo up on
http://fusesource.com/wiki/display/ProdInfo/FUSE+ESB+4+Getting+Started+Tutorial+Downloads
Maybe that might help?
/Ade
On 7 Mar 2009, at 14:31, thabach wrote:
Heya
would you recommend using Camel in a Batch P
I know that this is the case with ActiveMQ (you posted about it some time ago
in this forum) but we're using Oracle AQ (Streams replication) and their
samples show how they think it should work and in their case the
unsubscribe stops the delivery of messages.
James.Strachan wrote:
>
> 200
2009/3/5 akuhtz :
>
> There is currently no code to unsubscribe a durable subscriber as Camel uses
> the XXMessageListenerContainer classes from the spring framework and inside
> the spring code there is no unsubscribe code. I solved this yesterday by
> making a copy of the (in my case) SimpleMessa
Spring Issue created: http://jira.springframework.org/browse/SPR-5552
Claus Ibsen-2 wrote:
>
> On Thu, Mar 5, 2009 at 12:33 PM, akuhtz wrote:
>>
>> There is currently no code to unsubscribe a durable subscriber as Camel
>> uses
>> the XXMessageListenerContainer classes from the spring framewor
On Mon, Mar 9, 2009 at 9:28 AM, Henric Hedin wrote:
> OK, I had missed that warning :)
>
> I'm using WebSphere MQ 6.0.2.5, Camel 1.6.0 and Spring 2.5.6. I'm not
> running XA or inside a J2EE Container, but the cacheLevelName=CACHE_NONE
> seems to have solved by problem for WebSphere MQ.
Thanks. I
OK, I had missed that warning :)
I'm using WebSphere MQ 6.0.2.5, Camel 1.6.0 and Spring 2.5.6. I'm not
running XA or inside a J2EE Container, but the cacheLevelName=CACHE_NONE
seems to have solved by problem for WebSphere MQ.
/Henric
On Mon, Mar 9, 2009 at 9:11 AM, Claus Ibsen wrote:
> On Mon,
On Mon, Mar 9, 2009 at 9:02 AM, Henric Hedin wrote:
> Hi again,
>
> I solved my problem by setting cacheLevelName=CACHE_NONE on the MQ JMS
> Endpoint. Now the message is backed out out directly, without the route/JVM
> restart.
Great
We have a warning about it here:
http://camel.apache.org/jms.ht
Hi again,
I solved my problem by setting cacheLevelName=CACHE_NONE on the MQ JMS
Endpoint. Now the message is backed out out directly, without the route/JVM
restart.
Regards,
Henric
On Mon, Mar 9, 2009 at 8:53 AM, Henric Hedin wrote:
> Thank you Claus, the trick to not use the Spring Policy w
Thank you Claus, the trick to not use the Spring Policy works good enough
for me!
Though, I still get a strange behavior. I'm using WebSphere MQ as the
incoming JMS-provider and for the input queue I have set "Backout requeue
queue" and the Backout threshold to 1. When sending a message to the i
16 matches
Mail list logo
