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
