Scott,
basically, its one-to-one. Camel (S)JMS + Proxies + Beans (Spring or
EJB) is our standard remoting mechanism.
A client system has an outgoing route starting with a Camel proxy for FooService
from("direct:fooProxy).to("sjms:queue:fooQueue")
and the server system has a corresponding inco
Harald,
First, thanks again for your feedback. I will update the documentation with a
warning clarifying the limitation.
If you could clarify your use case for me, is this a one to many configuration?
One endpoint definition to many routes?
Thanks again,
Scott ES
On Feb 13, 2013, at 12:59
Thanks for the clarification Claus. I will update the documentation and plan
for an update in a later release.
Best Regards,
Scott ES
On Feb 13, 2013, at 12:59 AM, Harald Wellmann wrote:
> Well, it should be clearly documented that inOut() does not have the
> desired effect and that camel-sj
Well, it should be clearly documented that inOut() does not have the
desired effect and that camel-sjms behaves differently than camel-jms
in this respect.
I can live with the current approach, and I'm eager to see a release
of camel-sjms in 2.11 to get rid of the transitive Spring dependency
in m
On Tue, Feb 12, 2013 at 6:45 PM, Scott England-Sullivan
wrote:
> Sorry but I misunderstood that behavior.
>
> SJMS is designed to be agressive, meaning that the intent of the message
> flow is expected at initialization so the endpoint can be optimized with
> all necessary resources cached. In th
Sorry but I misunderstood that behavior.
SJMS is designed to be agressive, meaning that the intent of the message
flow is expected at initialization so the endpoint can be optimized with
all necessary resources cached. In this case the producer has already been
created and cached as an InOnly han
On Mon, Feb 11, 2013 at 5:56 PM, Scott England-Sullivan
wrote:
> After looking at it they don't appear to behave the same. The parameter sets
> the exchange pattern at initialization while the inOut() method sets the
> exchange at runtime.
>
> Is that what you would expect Claus?
>
Yes, there i
After looking at it they don't appear to behave the same. The parameter sets
the exchange pattern at initialization while the inOut() method sets the
exchange at runtime.
Is that what you would expect Claus?
Scott England-Sullivan
blog:sully6768.blogspot.com twitter:@sully6768
On Feb 9, 2013,
Ok, I've created an issue with a failing test attached:
https://issues.apache.org/jira/browse/CAMEL-6065
Best regards,
Harald
2013/2/11 Claus Ibsen :
> On Sun, Feb 10, 2013 at 10:38 AM, Harald Wellmann
> wrote:
>> Yes, I read the Javadoc. I have a test case which deterministically breaks
>> when
On Sun, Feb 10, 2013 at 10:38 AM, Harald Wellmann
wrote:
> Yes, I read the Javadoc. I have a test case which deterministically breaks
> when replacing 2) by 1).
>
> Given that SJMS is not yet released, should I create a JIRA issue, or post
> the details somewhere else?
>
Yeah if you can create an
Yes, I read the Javadoc. I have a test case which deterministically
breaks when replacing 2) by 1).
Given that SJMS is not yet released, should I create a JIRA issue, or
post the details somewhere else?
Best regards,
Harald
Am 10.02.2013 06:51, schrieb Claus Ibsen:
On Sat, Feb 9, 2013 at 4
On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann wrote:
> I'm rather confused by the different flavours of InOut.
>
> What's the difference between
>
> 1) from("direct:calculatorProxy")
> .inOut("sjms:calculator-queue");
>
> and
>
> 2) from("direct:calculatorProxy")
> .to("sjms:calculat
I'm rather confused by the different flavours of InOut.
What's the difference between
1) from("direct:calculatorProxy")
.inOut("sjms:calculator-queue");
and
2) from("direct:calculatorProxy")
.to("sjms:calculator-queue?exchangePattern=InOut");
inOut() in 1) does not seem to make an
13 matches
Mail list logo
