[
https://issues.apache.org/jira/browse/TUSCANY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-803.
----------------------------------
Resolution: Fixed
> Association of callback methods with request methods
> ----------------------------------------------------
>
> Key: TUSCANY-803
> URL: https://issues.apache.org/jira/browse/TUSCANY-803
> Project: Tuscany
> Issue Type: Improvement
> Components: Specification
> Reporter: Ignacio Silva-Lepe
> Assignee: Mike Edwards
> Fix For: Java-SCA-Next
>
>
> The specs (assembly and C&I) do not seem to be very explicit about what
> should happen with an interface that is annotated as @Callback and that
> defines more than one method. But notice that if this is the case then
> the next question pertains to a previous question, which is what happens
> when the callback interface (the one in the annotation, not the annotated
> one) has more than one method.
> Let i1 be an intrerface annotated with @Callback(c1), where c1 is the
> callback interface. The simplest case is when both i1 and c1 have only
> one method. If i1 has > 1 methods there are two cases: c1 has only one
> method, and c1 has > 1 methods. The first case is the case at hand.
> Notice that one last case is where i1 has one method and c1 has > 1, but
> that really is a special case of the second case.
> The second case is the one we had asked about before, how do we associate
> methods in c1 with methods in i1. Again, the specs are not explicit about
> this. In general, this association may require knowledge about the
> implementation of i1. That is, i1Impl will get an injected instance of c1
> which then it will use in its method(s) to make callback invocations.
> Which c1 method is invoked in i1 is arbitrary and we may have to resort
> to non-trivial introspection to figure it out. Btw, nontice that this
> case also includes the first case.
> So it seems we have a choice of how to interpret the specs.
> 1- The simplest choice is to assume i1 and c1 both have only one method.
> 2- We can assume that c1 has only one method (case at hand) and
> introspect each method in i1 to figure out which is intended as async
> with callback and which is not. In addition, here we also have a choice
> of whether to treat non-callback methods as sync or async.
> 3- We can try go for the general case.
> My vote is to go with choice 1, which is what I have been assuming so
> far, at least for the coming release. And if we don't feel comfortable
> with this choice long term, then we can try for choice 2 or maybe even
> choice 3, if we can make sense of it.
> It would also be useful to try to go back to the spec collaboration to
> try to calrify the intent.
> More details:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg08617.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
