OK, I see that the annotation is helpful especially from the client side to deduce the Java class of the callback interface (on the service/target side we have the type of the @Callback to guide us).
If we were able to pursue my idea (and we decided we wanted to), then from the perspective of a client component we could start from the callbackInterface on the component reference interface definition and look at what interfaces the client implements (one of which should be the callback). ---- I realize I should broaden my question a bit... it's not strictly speaking the top-down case I'm asking about but more generally the case in which the component definition explicitly connects the forward/callback interfaces on the component reference definition. On Wed, Oct 29, 2008 at 10:07 AM, Simon Laws <[EMAIL PROTECTED]>wrote: > > > On Wed, Oct 29, 2008 at 1:35 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: > >> Hi Simon, >> >> So from the client-side I have a reference configured with a bidirectional >> interface (forward/callback pair). So the runtime should know to which >> client component direct the callback from this config (I'm just talking >> about which component not which component instance). If that resolves to >> another Java impl in the domain, that impl has an @Callback-annotated >> field/setter, which seems to fulfill the purpose you described. >> >> So it seems there must be some other reason. >> >> >> >> On Wed, Oct 29, 2008 at 8:12 AM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> >>> >>> On Tue, Oct 28, 2008 at 2:35 PM, Scott Kurz <[EMAIL PROTECTED]> wrote: >>> >>>> I noticed an annoyance in the scenario that we are developing in a >>>> top-down style, starting with two WSDL interfaces, which we wish to use as >>>> a >>>> forward/callback pair. >>>> >>>> Since this is top-down, we generate Java interfaces from each WSDL using >>>> something like wsimport. The annoyance is that I have to go and add an >>>> @Callback(MyCallbackIntf.class) to the generated forward interface, to link >>>> the two interfaces together. >>>> >>>> In a quick test it seemed that if I didn't do that I had problems (maybe >>>> I should try another test, but wanted to throw this out for discussion >>>> first...) >>>> >>>> Strikes me as ugly to have to add an SCA intf to generated code.... >>>> >>>> Now, I realize the OSOA Java annotations/apis implies that you need to >>>> do this. But I was wondering, if the component configures an >>>> <interface.wsdl ... interface=".." callbackInterface".."> then shouldn't >>>> that be enough to link the two? >>>> >>>> Or is there some need for the runtime to be able to look at the forward >>>> intf Class object and determine the callback intf Class that I'm not >>>> seeing, >>>> (perhaps for some particular API I'm not paying attention to)? >>>> >>>> Any thoughts? >>>> >>>> Thanks, >>>> Scott >>>> >>> >>> Hi Scott >>> >>> I haven't looked at the details of the code on this but I imagine the >>> runtime needs some help in deciding where to inject the callback reference, >>> assuming that injection is required. If it only had a WSDL document as a >>> guide to the type of the callback reference for a given service interface >>> then it wouldn't necessarily be able to map from the WSDL to the Java type. >>> For example, in the case where you have mapped from WSDL to Java manually. >>> >>> Sound plausible? >>> >>> Simon >>> >> >> > But can it deduce the java type of the callback interface? You're right I > was using the implementation.java case to justify why this is important. > > Simon >
