On Tue, Jul 29, 2008 at 4:41 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > 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 > I've done more investigation now and think both of the cases described in the JIRA are issues of spec interpretation. Both of the vtests work currently in Tuscany by luck. Without Scott's change to binding.ws both cases use binding.sca which seems to operate with no recourse, at build time, to the interface contract (that is not present in the model). With Scott's change to use binding.ws the builder fails trying to find the inteface contract for these references. So I'll draft questions here for both issues and if we agree I can post then to OASIS and take it from there. Unannotated References ================== The tuscany code has interpreted the spec to mean that unannotated references in a component implementation will not be considered part of the component type unless there are no annotated references or properties. I assume because if you have annotated some of your fields why not annotate all of the,. vtest/java-api/annotations/reference does raise a number of warnings indicating that the reference in the SCDL cannot be found in the component implementation (maybe that should be an error). Suggested Java Implementation spec section 1.2.7 change... 361 In the absence of @Property and @Reference annotations, the properties and references of a class are Should become 361 In the absence of *any* @Property and @Reference annotations, the properties and references of a class are The implications for the vtest is that we would need to split tests with annotations from tests with no annotations ComponentContext.getService ====================== vtest/java-api/apis/componentcontext has a test which uses componentContext.getService(DComponent.class, "dReference").getName(); for the reference "dReference" that has not been declared on the component type, either through an annotated or unannotated field or through a component type file. This seems like a strange thing to do and I would assume that it is a precondition of using a reference that the reference exists in the component type regardless of how the reference is retrieved. I think the spec mistakenly implies that this is a valid thing through an example included in the Java Annotations and APIs spec Suggested Java Annotations and APIs spec section 1.7.1 change 830 The following shows a sample of a component context definition in a Java class using the @Context 831 annotation. 832 private ComponentContext componentContext; 833 834 @Context 835 public void setContext(ComponentContext context){ 836 componentContext = context; 837 } 838 839 public void doSomething(){ 840 HelloWorld service = 841 componentContext.getService(HelloWorld.class,"HelloWorldComponent"); 842 service.hello("hello"); 843 } Should become 830 The following shows a sample of a component context definition in a Java class using the @Context 831 annotation. * @Reference protected HelloWorld HelloWorldComponent;* 832 private ComponentContext componentContext; 833 834 @Context 835 public void setContext(ComponentContext context){ 836 componentContext = context; 837 } 838 839 public void doSomething(){ 840 HelloWorld service = 841 componentContext.getService(HelloWorld.class,"HelloWorldComponent"); 842 service.hello("hello"); 843 } The effect of this is that we have to adjust our test to properly define the reference. Let me know if you have thoughts about these interpretations. I plan to send this off to OASIS in a day or so. Regards Simon
