On Wed, Jul 30, 2008 at 8:30 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
> 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 >> >> > Hi Scott Interesting scenario. My mental model is that I expect that a component type will define, through a side file or through (annotated or unannotated) fields, all of its references and the types of those references. You scenario would still operate if the user had included the reference description in a side file or had put @Reference MyInterface MyReference; in their code. It would just look a little odd. I don't believe that including a <reference> on a component in a composite file is equivalent to defining a reference on a component type. I do note though that the <interface> element is still apparently optional in the component type descrition in section 1.4.1 of the assembly spec. Another question to raise. For example, if I have a composite implementation for my component and then define a reference at the component level but not the composite level there is no link between the reference at the component level and a component reference, in the underlying composite, that it is intended to promote. It just so happens that when there is Java implementation there is an API we can use to look up references. I think though that they should still be defined on the component type. Another scenario that comes to mind for using ComponentContext.getService() is if you have a component that has many independent references with the same interface and you want to be able to choose between them dynamically by name. I still feel the references should be defined in the component type. If they were an arbitrarty number I would be more likely to use a single reference with a multiplicity >1. Does this help? Simon
