You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Gert Vanthienen <ge...@gmail.com> on 2009/07/02 16:00:03 UTC

Re: JMS BC and MEP

L.S.,

I have taken a quick look at the source code for the new jms:consumer
and jms:provider endpoints and I think they should be able to handle
all MEPs correctly.  We are fully aware that some of our documentation
is not up-to-date, but you're can always raise a JIRA issue to get
this particular documentation issue addressed (cfr.
http://servicemix.apache.org/contributing.html).  Off course, the
documentation is maintained in a wiki and we welcome any kind of
contribution so feel free to add things there.

Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



2009/6/30 ffrenchm <ff...@gmail.com>:
>
> Uhm ignore my last comment about provider endpoint it's non sense and the
> underlined behavior make sense.
> In fact I just would like to know the JBI MEP management limitations with
> JMS BC because I do not know if I must believe the documentation or the smx
> jms bc source code...
>
> Thanks for all...
>
>
> ffrenchm wrote:
>>
>> Hello,
>>
>> I read here (http://servicemix.apache.org/component-matrix.html) that JMS
>> BC is managing InOnly and InOut JBI MEP.
>>
>> After checking the source code I discover that it can also manage
>> RobustInOnly and InOptionalOut. I notice also that for example if a
>> provider enpoint get a DONE or ERROR message there is no JMS messages
>> sended to the target queue, consequently I think JBI MEP are not correctly
>> managed in all the case. But there is certainly good reasons for this
>> behavior I ignore ? Can I get these reasons ?
>>
>> Thanks for all
>>
>
> --
> View this message in context: http://www.nabble.com/JMS-BC-and-MEP-tp24273821p24274071.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>

Re: JMS BC and MEP

Posted by ffrenchm <ff...@gmail.com>.
Hello, 

there is something which I don't really understand. In the case of the
InOnly MEP and AFAI understand SMX JMS BC sending the DONE just after
sending the serialized message to the JMS broker. But should it not the
final application target which should send this DONE message in the JBI
InOnly MEP definition ? In the other end for the InOut JBI MEP I've the
impression you're managing this case correctly: so why not for the InOnly
MEP ?

Thanks


Gert Vanthienen wrote:
> 
> L.S.,
> 
> I have taken a quick look at the source code for the new jms:consumer
> and jms:provider endpoints and I think they should be able to handle
> all MEPs correctly.  We are fully aware that some of our documentation
> is not up-to-date, but you're can always raise a JIRA issue to get
> this particular documentation issue addressed (cfr.
> http://servicemix.apache.org/contributing.html).  Off course, the
> documentation is maintained in a wiki and we welcome any kind of
> contribution so feel free to add things there.
> 
> Regards,
> 
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
> 
> 
> 
> 2009/6/30 ffrenchm <ff...@gmail.com>:
>>
>> Uhm ignore my last comment about provider endpoint it's non sense and the
>> underlined behavior make sense.
>> In fact I just would like to know the JBI MEP management limitations with
>> JMS BC because I do not know if I must believe the documentation or the
>> smx
>> jms bc source code...
>>
>> Thanks for all...
>>
>>
>> ffrenchm wrote:
>>>
>>> Hello,
>>>
>>> I read here (http://servicemix.apache.org/component-matrix.html) that
>>> JMS
>>> BC is managing InOnly and InOut JBI MEP.
>>>
>>> After checking the source code I discover that it can also manage
>>> RobustInOnly and InOptionalOut. I notice also that for example if a
>>> provider enpoint get a DONE or ERROR message there is no JMS messages
>>> sended to the target queue, consequently I think JBI MEP are not
>>> correctly
>>> managed in all the case. But there is certainly good reasons for this
>>> behavior I ignore ? Can I get these reasons ?
>>>
>>> Thanks for all
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JMS-BC-and-MEP-tp24273821p24274071.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
> 
> 
> -----
> ---
> Gert Vanthienen
> http://gertvanthienen.blogspot.com
> 

-- 
View this message in context: http://www.nabble.com/JMS-BC-and-MEP-tp24273821p24352216.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.