Association of callback methods with request methods ----------------------------------------------------
Key: TUSCANY-803 URL: http://issues.apache.org/jira/browse/TUSCANY-803 Project: Tuscany Issue Type: Improvement Components: Specification Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Assigned To: Michael John Edwards Fix For: Java-Mx 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]