Re: Every other remote call fails with NoSuchMethodException

["Christopher G. Stach II" <cg...@ldsys.net>]

James Strachan wrote:
> On 3/24/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
>> James Strachan wrote:
>>> Ah yes - the queue can contain any messages of any type; so make sure
>>> in Lingo-land to use a different queue per message type.
>>>
>>> If it helps, we could get Lingo to add the method name as a JMS header
>>> - then you could use JMS selectors when you bind a queue to a service;
>>> so that the JMS selector would filter out only the right method
>>> invocations
>>>
>>> James
>>>
>> I would have a use for multiple interfaces on the same queue, as well.
>>
>> This is a little off topic, but it reminded me of something.  Could you
>> also get Lingo to participate in JTA transacted JMS sessions for one-way
>> asynchronous calls so that the queue only releases the messages when the
>> transaction commits?  Please? :)  We had to go back to using JmsTemplate
>> because of this limitation.
> 
> Sure - it should be pretty easy to do - we'd just need to hack the
> code to support XA sessions & transaction enlistment etc

James:

Has there been any development on either of these issues?  We're
_really_ wanting to toss JmsTemplate, but we also need something that is
transacted.  If it's really easy, could it even get into a Lingo
snapshot soon?  The multiple interfaces would be nice and would trim our
configuration a bit, but it's not a show stopper.  Thanks.

-- 
Christopher G. Stach II

Re: Every other remote call fails with NoSuchMethodException

[James Strachan <ja...@gmail.com>]

On 6/8/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
> James Strachan wrote:
> > On 3/24/06, Christopher G. Stach II <cg...@ldsys.net> wrote:
> >> James Strachan wrote:
> >>> Ah yes - the queue can contain any messages of any type; so make sure
> >>> in Lingo-land to use a different queue per message type.
> >>>
> >>> If it helps, we could get Lingo to add the method name as a JMS header
> >>> - then you could use JMS selectors when you bind a queue to a service;
> >>> so that the JMS selector would filter out only the right method
> >>> invocations
> >>>
> >>> James
> >>>
> >> I would have a use for multiple interfaces on the same queue, as well.
> >>
> >> This is a little off topic, but it reminded me of something.  Could you
> >> also get Lingo to participate in JTA transacted JMS sessions for one-way
> >> asynchronous calls so that the queue only releases the messages when the
> >> transaction commits?  Please? :)  We had to go back to using JmsTemplate
> >> because of this limitation.
> >
> > Sure - it should be pretty easy to do - we'd just need to hack the
> > code to support XA sessions & transaction enlistment etc
>
> James:
>
> Has there been any development on either of these issues?

Adding stuff to the message headers is easy to do - just derive from
the DefaultMarshaller and add whatever extra properties you want...


>  We're
> _really_ wanting to toss JmsTemplate, but we also need something that is
> transacted.  If it's really easy, could it even get into a Lingo
> snapshot soon?

We're just waiting for someone to find time to submit a patch. As soon
as we have a patch we can definitely add it to Lingo and do a release.

-- 

James
-------
http://radio.weblogs.com/0112098/