On Fri, Aug 26, 2011 at 10:25 AM, ant elder <[email protected]> wrote: > On Fri, Aug 26, 2011 at 9:35 AM, Simon Laws <[email protected]> wrote: >> On Fri, Aug 26, 2011 at 9:31 AM, ant elder <[email protected]> wrote: >>> On Thu, Aug 25, 2011 at 3:50 PM, Simon Laws <[email protected]> >>> wrote: >>> >>>> Issues 3: Given that callback endpoints are put into the registry >>>> there is a danger that they will be mistakenly matched for forward >>>> endpoint when just the component name is provided as input to the >>>> match. >>> >>> For issue 3 about callback endpoints getting found in the registry by >>> accident how about instead of tacking "Callback" on the service name >>> put it on the component name? >>> >>> ...ant >>> >> >> Do you mean in the xml that fluffed up when an endpoint is serialized? >> If so yes, I agree, something like that would work. >> > > Thats not quite what i meant but i've just had a look and the code > doesn't work the way it used to now so what i was thinking wont help. > If we did more complete interface matching when picking an endpoint > instead of just picking the first one would this issue go away? Didn't > Greg raise a JIRA or post to the ML about doing that a little while > back? > > ...ant >
The problem with relying on remote interface matching is that it's difficult to be absolutely sure that two interfaces don't match, In some cases we'll have to defer to the runtime. For example, some Java types can't be converted to XML by JAXB so trying to match XML types will fail. Now I admit you'd have to be pretty unlucky to have you're callback interface match your forward interface in everything but type details. However I'm becoming increasingly skeptical about the performance of remote interface matching. You may have noticed I've turned if off temporarily. There seem to be several situations where it doesn't work properly which I don't understand well enough to articulate in a post yet. It's likely this is just lack of databinding understanding on my part. We'll see. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
