On Tue, Jul 29, 2008 at 4:25 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
> Simon, > > Yes, you've summed up the issue for the > vtest/java-api/apis/componentcontext failure. In the > vtest/java-api/annotations/reference > we have a bit different situation and even if there is a partly common > solution there might be a bit of extra work to tie in the unannotated field > to the constructed reference. > > I don't think (1), parsing the java, is an option. > > For (2), I did expect this to already work. That's since I know that the > componentContext.getService(DComponent.class, "dReference") maps onto a > createSelfReference call which does create and configure a new reference, > using the interface Class passed into getService(), so I'm not sure what > piece of the puzzle isn't quite there today. > > Thanks, > Scott > > > On Tue, Jul 29, 2008 at 10:49 AM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) < >> [email protected]> wrote: >> >>> >>> [ >>> https://issues.apache.org/jira/browse/TUSCANY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] >>> >>> Scott Kurz updated TUSCANY-2501: >>> -------------------------------- >>> >>> Attachment: 2501.recreate.dont.commit.me.diff >>> >>> Here's a version of the test we can use to recreate >>> >>> > A couple places where InterfaceContract is not established on reference >>> when it's not calculated by introspection >>> > >>> ----------------------------------------------------------------------------------------------------------------- >>> > >>> > Key: TUSCANY-2501 >>> > URL: >>> https://issues.apache.org/jira/browse/TUSCANY-2501 >>> > Project: Tuscany >>> > Issue Type: Bug >>> > Components: Java SCA Core Runtime >>> > Reporter: Scott Kurz >>> > Attachments: 2501.recreate.dont.commit.me.diff >>> > >>> > >>> > The vtests have a couple examples which result in component references >>> being created without a corresponding InterfaceContract. >>> > This is not a problem with the current default binding impl (as these >>> tests are currently passing), but a switch to using the WS binding, say, >>> shows the issue. >>> > I'll attach a patch, too, but here are the issues: >>> > >>> ------------------------------------------------------------------------------ >>> > In vtest/java-api/apis/componentcontext: >>> > return componentContext.getService(DComponent.class, >>> "dReference").getName(); >>> > In vtest/java-api/annotations/reference >>> > public class AServiceImpl implements AService { >>> > .... >>> > public BService b4; // field injection (public, un-annotated) >>> > >>> ------------------------------------------------------------------------------ >>> > In both cases, the SCDL merely configures the ref target (and binding) >>> but does not define the ref intf. >>> > I haven't given this area a great deal of thought, my guess is we want >>> to extend our Java introspection capabilities, though I could see that for >>> some impl >>> > types the better answer might be to require the SCDL to configure the >>> intf in component SCDL. >>> > I didn't try the latter either, but wanted to just write up the issue >>> for now. >>> > Thanks, >>> > Scott >>> > >>> >>> -- >>> This message is automatically generated by JIRA. >>> - >>> You can reply to this email to add a comment to the issue online. >>> >>> >> Hi Scott >> >> I'm just going to try and net down the problem here to make sure I >> understand it. >> >> For a component implemented thus; >> >> public class AComponentImpl implements AComponent { >> >> public String testServiceLookup() { >> return componentContext.getService(DComponent.class, >> "dReference").getName(); >> } >> >> } >> >> and described in SCDL in the following way; >> >> <component name="AComponent"> >> <implementation.java >> class="org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.impl.AComponentImpl"/> >> <reference name="dReference"> >> <binding.ws uri="http://localhost:8085/DComponent"/> >> </reference> >> </component> >> >> There is no easy way for the model to determine the interface type of >> "dReference2" short of either; >> >> 1. parsing the java to find where >> componentContext.getService(DComponent.class, "dReference") is called >> 2. waiting until runtime when >> componentContext.getService(DComponent.class, "dReference") is called and >> configuring the reference at that point. >> >> Currently an error is reported when the builders try to generate WSDL for >> the non-exsitent interface definition. >> >> Simon >> > > Ah yes I see there is a difference with the reference case. I'm a little surprised that in this case it's not able to work it out. It certainly seems more plausible than the context case. I'll take a closer look. With the context scenario I don't think parsing the Java is practical either. However there are various places in the builders that currently rely on this interface being set. So it may well be that the runtime is able to do it's thing but it can't get past the builder. Let me see what the level of dependence on a configured interfaceContract is. Simon
