Re: ServiceMix Bean issues with send()
So, basically, there is no concept of consumer endpoint: an exchange is sent from a component to an endpoint. Inside servicemix components, we usually have this concept of consumer endpoint, but in such case, this means that the component has to dispatch the incoming exchange back to the endpoint that sent it. On 10/19/07, Andreas Schaefer <[EMAIL PROTECTED]> wrote: > HI Guillaume > > I hope you are right even though I am not quite sure how you want to > figure out the service name of the consumer. I still think it is a > problem of the core. Even if we can fix the problem inside the Bean BC > the problem may arise on other BCs as well. I think that we should not > only have a source component but also a source service name or any form > of internal identification of the source SU. > > BTW today I am at home and so we may can discuss this through IRC if you > want. > > -Andy > > Guillaume Nodet wrote: > > I had some time to look at your test case on the plane and i think i > > found a fix. In all cases i'm quite sure that the problem comes from > > the component and not from the container. The fix is mainly to inject > > on the pojo a delivery channel that will track consumer exchanges sent > > by the bean. That way, the component will know about the exchange and > > will not throw an exception. > > > > 2007/10/19, Andreas Schaefer (2) <[EMAIL PROTECTED]>: > > Tomorrow I plan to try to fix this issue but if anyone sees a flaw in > > my design please stop beforehand. > > > > Today I finally resolved the problem of how does ServiceMix know to > > which component it should send the Message Exchange (ME) back even > > though it uses the wrong Service Name. Inside the > > AbstractFlow.doRouting() it uses the SourceId from the ME to find the > > correct Binding Component (BC). That is why in my test project the > > call goes back tot he Bean BC even though it tries to call a service > > that is actually based on a Script BC. This makes me hopeful that > > applying the same logic to the service name could fix the issue. > > > > That is what I want to do to fix it: > > > > - service name is removed from the packet and placed inside the ME > > (maybe also the endpoint) > > - the ME.setServiceName() is actually set on the MIRROR.serviceName > > member (so that I don't have to change the logic of switching the ME > > with its MIRROR) > > - the consumer's service name is set on the ME before the ME is sent > > onto the flow. This is either done on the Message Exchange Factory or > > on the Delivery Channel which is probably the better choice because > > then on the way back the service name of the provider can also be set > > if not already done). I just have to figure out how to obtain the > > service name of the sending SU from within the Delivery Channel. > > > > I think that should do the trick even though I don't know what the > > implications on the SYNCHRONOUS ME are and hope that I am not going > > to open Pandora's Box. > > > > Thanks - Andy > > > >> > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix Bean issues with send()
HI Guillaume I hope you are right even though I am not quite sure how you want to figure out the service name of the consumer. I still think it is a problem of the core. Even if we can fix the problem inside the Bean BC the problem may arise on other BCs as well. I think that we should not only have a source component but also a source service name or any form of internal identification of the source SU. BTW today I am at home and so we may can discuss this through IRC if you want. -Andy Guillaume Nodet wrote: > I had some time to look at your test case on the plane and i think i > found a fix. In all cases i'm quite sure that the problem comes from > the component and not from the container. The fix is mainly to inject > on the pojo a delivery channel that will track consumer exchanges sent > by the bean. That way, the component will know about the exchange and > will not throw an exception. > > 2007/10/19, Andreas Schaefer (2) <[EMAIL PROTECTED]>: > Tomorrow I plan to try to fix this issue but if anyone sees a flaw in > my design please stop beforehand. > > Today I finally resolved the problem of how does ServiceMix know to > which component it should send the Message Exchange (ME) back even > though it uses the wrong Service Name. Inside the > AbstractFlow.doRouting() it uses the SourceId from the ME to find the > correct Binding Component (BC). That is why in my test project the > call goes back tot he Bean BC even though it tries to call a service > that is actually based on a Script BC. This makes me hopeful that > applying the same logic to the service name could fix the issue. > > That is what I want to do to fix it: > > - service name is removed from the packet and placed inside the ME > (maybe also the endpoint) > - the ME.setServiceName() is actually set on the MIRROR.serviceName > member (so that I don't have to change the logic of switching the ME > with its MIRROR) > - the consumer's service name is set on the ME before the ME is sent > onto the flow. This is either done on the Message Exchange Factory or > on the Delivery Channel which is probably the better choice because > then on the way back the service name of the provider can also be set > if not already done). I just have to figure out how to obtain the > service name of the sending SU from within the Delivery Channel. > > I think that should do the trick even though I don't know what the > implications on the SYNCHRONOUS ME are and hope that I am not going > to open Pandora's Box. > > Thanks - Andy > >>
Re: ServiceMix Bean issues with send()
I had some time to look at your test case on the plane and i think i found a fix. In all cases i'm quite sure that the problem comes from the component and not from the container. The fix is mainly to inject on the pojo a delivery channel that will track consumer exchanges sent by the bean. That way, the component will know about the exchange and will not throw an exception. 2007/10/19, Andreas Schaefer (2) <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tomorrow I plan to try to fix this issue but if anyone sees a flaw in > my design please stop beforehand. > > Today I finally resolved the problem of how does ServiceMix know to > which component it should send the Message Exchange (ME) back even > though it uses the wrong Service Name. Inside the > AbstractFlow.doRouting() it uses the SourceId from the ME to find the > correct Binding Component (BC). That is why in my test project the > call goes back tot he Bean BC even though it tries to call a service > that is actually based on a Script BC. This makes me hopeful that > applying the same logic to the service name could fix the issue. > > That is what I want to do to fix it: > > - - service name is removed from the packet and placed inside the ME > (maybe also the endpoint) > - - the ME.setServiceName() is actually set on the MIRROR.serviceName > member (so that I don't have to change the logic of switching the ME > with its MIRROR) > - - the consumer's service name is set on the ME before the ME is sent > onto the flow. This is either done on the Message Exchange Factory or > on the Delivery Channel which is probably the better choice because > then on the way back the service name of the provider can also be set > if not already done). I just have to figure out how to obtain the > service name of the sending SU from within the Delivery Channel. > > I think that should do the trick even though I don't know what the > implications on the SYNCHRONOUS ME are and hope that I am not going > to open Pandora's Box. > > Thanks - Andy > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFHGADWs4gPTNnP0gkRAsNpAJ9knS8kX0NfIbAMW+uGgBjIN0i3zQCfceDi > rdw1L46NBoZnzqQzLYILOEw= > =VDq2 > -END PGP SIGNATURE- > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix Bean issues with send()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomorrow I plan to try to fix this issue but if anyone sees a flaw in my design please stop beforehand. Today I finally resolved the problem of how does ServiceMix know to which component it should send the Message Exchange (ME) back even though it uses the wrong Service Name. Inside the AbstractFlow.doRouting() it uses the SourceId from the ME to find the correct Binding Component (BC). That is why in my test project the call goes back tot he Bean BC even though it tries to call a service that is actually based on a Script BC. This makes me hopeful that applying the same logic to the service name could fix the issue. That is what I want to do to fix it: - - service name is removed from the packet and placed inside the ME (maybe also the endpoint) - - the ME.setServiceName() is actually set on the MIRROR.serviceName member (so that I don't have to change the logic of switching the ME with its MIRROR) - - the consumer's service name is set on the ME before the ME is sent onto the flow. This is either done on the Message Exchange Factory or on the Delivery Channel which is probably the better choice because then on the way back the service name of the provider can also be set if not already done). I just have to figure out how to obtain the service name of the sending SU from within the Delivery Channel. I think that should do the trick even though I don't know what the implications on the SYNCHRONOUS ME are and hope that I am not going to open Pandora's Box. Thanks - Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHGADWs4gPTNnP0gkRAsNpAJ9knS8kX0NfIbAMW+uGgBjIN0i3zQCfceDi rdw1L46NBoZnzqQzLYILOEw= =VDq2 -END PGP SIGNATURE-
