Simon, About the 2nd case...
Let me just throw out a case where the ComponentContext is useful without needing a single field to hold the reference: Say component A has a dependency on component B over a conversational intf, and say A wants to manage the sessions. So instead of a single MyReference it has a map of <SomeSessionID, MyReference>. In the SCDL, though, we only want to model the single reference, not the map of References. Now... I know this brings up the question of why are you having your business logic manage sessions.. which is a good counterpoint, but I did want to mention an example so it didn't look totally useless. Scott On Wed, Jul 30, 2008 at 1:43 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > > > 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 > >
