You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2008/07/26 15:55:31 UTC
[jira] Created: (TUSCANY-2501) A couple places where
InterfaceContract is not established on reference when it's not calculated
by introspection
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
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.
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 1, 2008 at 2:38 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Simon Laws wrote:
>
>>
>>
>> On Wed, Jul 30, 2008 at 8:30 PM, Scott Kurz <scottkurz@gmail.com <mailto:
>> scottkurz@gmail.com>> 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
>>
>> <snip>
>
>> 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
>>
>> Folks,
>
> There is an important point here, which the SCA Java specifications don't
> make clear.
> I'll raise an issue in the OASIS Java TC to address this - but I'll discuss
> it here first.
>
> Let me latch onto Simon's comment above:
>
> "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"
>
> No - it's not meant to be. The component metadata is configuration of the
> implementation - but the configurable points are defined by the
> implementation, not by the component.
>
> The ideal position is that the Java implementation explicitly says what all
> its services, references and properties are, using annotations. If it is
> written as an SCA component implementation, this should be no big deal. The
> question arises if the class were originally written for some other purpose
> and the desire is to use it unchanged - hence the material in the Java POJO
> implementation spec about calculating the component type of an unannotated
> Java class (it's this material that is deficient and needs fixing btw).
>
> Now, take some of the scenarios that have been described. They all seem to
> revolve around a reference which should not be injected but which will be
> obtained programmatically via an API. This is allowed for in the SCA Java
> spec - you need something like:
>
> @Reference(required=false)
> MyInterfaceType myReference;
>
> Note that the field is still required - it defines the interface of the
> reference and in this case it also names the reference. But the
> "required=false" parameter in the @Reference says "don't inject this
> reference" - so the runtime knows everything about the reference, but
> injection will not occur because we have asked to suppress it (it ain't the
> default because in the simple cases, injection is what you want...).
>
> The Java code is then free to go and ask for an actual reference proxy
> using the componentContext - and to do this as often as it likes (this would
> be a way to have multiple conversations with the same conversational
> service...).
>
> The other valid way to do things would be to use a componentType side file
> (not my cup of tea, for sure) and to lay out the references in there. I
> dislike this so much I've never even asked whether it works in Tuscany for a
> Java POJO. I know it works for a BPEL process since I wrote the code to get
> rid of the need to do it ;-)
>
> I hope this frames the discussion a bit - and now I'll go raise my issue
> against the SCA Java specs to clarify the handling of component type for
> POJOs.
>
>
> Yours, Mike.
>
Hi Mike
I've just stumbled across some more words in the spec that are pertinent to
this conversation.
Java Annotations and API Section 1.7.1 describes the getService method as
returning a proxy for the "reference defined by the current component". This
could be clarified to make it clear that this is the reference from the
component type that is important not the reference that appears on a
component in SCDL.
Java Component Implementation Section 1.2.2.2 describes dynamic references.
and could be clarrified to explain that the references that are the subject
of dynamic access must first be described as part of the the component type.
Simon
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract
is not established on reference when it's not calculated by introspection
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
>
>
> On Wed, Jul 30, 2008 at 8:30 PM, Scott Kurz <scottkurz@gmail.com
> <ma...@gmail.com>> 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
>
<snip>
> 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
>
Folks,
There is an important point here, which the SCA Java specifications don't make clear.
I'll raise an issue in the OASIS Java TC to address this - but I'll discuss it here first.
Let me latch onto Simon's comment above:
"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"
No - it's not meant to be. The component metadata is configuration of the implementation - but the
configurable points are defined by the implementation, not by the component.
The ideal position is that the Java implementation explicitly says what all its services, references
and properties are, using annotations. If it is written as an SCA component implementation, this
should be no big deal. The question arises if the class were originally written for some other
purpose and the desire is to use it unchanged - hence the material in the Java POJO implementation
spec about calculating the component type of an unannotated Java class (it's this material that is
deficient and needs fixing btw).
Now, take some of the scenarios that have been described. They all seem to revolve around a
reference which should not be injected but which will be obtained programmatically via an API. This
is allowed for in the SCA Java spec - you need something like:
@Reference(required=false)
MyInterfaceType myReference;
Note that the field is still required - it defines the interface of the reference and in this case
it also names the reference. But the "required=false" parameter in the @Reference says "don't
inject this reference" - so the runtime knows everything about the reference, but injection will not
occur because we have asked to suppress it (it ain't the default because in the simple cases,
injection is what you want...).
The Java code is then free to go and ask for an actual reference proxy using the componentContext -
and to do this as often as it likes (this would be a way to have multiple conversations with the
same conversational service...).
The other valid way to do things would be to use a componentType side file (not my cup of tea, for
sure) and to lay out the references in there. I dislike this so much I've never even asked whether
it works in Tuscany for a Java POJO. I know it works for a BPEL process since I wrote the code to
get rid of the need to do it ;-)
I hope this frames the discussion a bit - and now I'll go raise my issue against the SCA Java specs
to clarify the handling of component type for POJOs.
Yours, Mike.
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Jul 30, 2008 at 8:30 PM, Scott Kurz <sc...@gmail.com> 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 <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Jul 29, 2008 at 4:41 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jul 29, 2008 at 4:25 PM, Scott Kurz <sc...@gmail.com> 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 <simonslaws@googlemail.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) <
>>>>> dev@tuscany.apache.org> 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
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Scott Kurz <sc...@gmail.com>.
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 <si...@googlemail.com>wrote:
>
>
> On Tue, Jul 29, 2008 at 4:41 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Jul 29, 2008 at 4:25 PM, Scott Kurz <sc...@gmail.com> 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 <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) <
>>>> dev@tuscany.apache.org> 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
>
>
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 29, 2008 at 4:41 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Jul 29, 2008 at 4:25 PM, Scott Kurz <sc...@gmail.com> 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 <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) <
>>> dev@tuscany.apache.org> 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
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 29, 2008 at 4:25 PM, Scott Kurz <sc...@gmail.com> 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 <si...@googlemail.com>wrote:
>
>>
>>
>> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) <
>> dev@tuscany.apache.org> 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
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Scott Kurz <sc...@gmail.com>.
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 <si...@googlemail.com>wrote:
>
>
> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) <dev@tuscany.apache.org
> > 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
>
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 29, 2008 at 3:49 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA) <dev@tuscany.apache.org
> > 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
>
The sentence "There is no easy way for the model to determine the interface
type of "dReference2" short of either;" should read "There is no easy way
for the model to determine the interface type of "dReference" short of
either".
Simon
Re: [jira] Updated: (TUSCANY-2501) A couple places where InterfaceContract is not established on reference when it's not calculated by introspection
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Jul 26, 2008 at 2:57 PM, Scott Kurz (JIRA)
<de...@tuscany.apache.org>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
[jira] Commented: (TUSCANY-2501) A couple places where
InterfaceContract is not established on reference when it's not calculated
by introspection
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627305#action_12627305 ]
Simon Laws commented on TUSCANY-2501:
-------------------------------------
Conversation relating to this JIRA has been going on on the mail list here (http://www.mail-archive.com/dev@tuscany.apache.org/msg01953.html) and is seems that this error is the know on effect of the specs implying that if you mix annotated and unannotated references then the unannotated references are ignored. The code changes relating to this JIRA cause an error to be raised if the user tries to mix annotated and unannotated references.
> 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
> Fix For: Java-SCA-Next
>
> 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.
[jira] Resolved: (TUSCANY-2501) A couple places where
InterfaceContract is not established on reference when it's not calculated
by introspection
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws resolved TUSCANY-2501.
---------------------------------
Resolution: Fixed
Change committed to 1.3.2 at r690691
> 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
> Fix For: Java-SCA-1.3.2
>
> 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.
[jira] Updated: (TUSCANY-2501) A couple places where
InterfaceContract is not established on reference when it's not calculated
by introspection
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws updated TUSCANY-2501:
--------------------------------
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.3.2
Moving to 1.3.2 as this is a gotcha that we could usefully fix as we already have the change.
> 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
> Fix For: Java-SCA-1.3.2
>
> 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.
[jira] Updated: (TUSCANY-2501) A couple places where
InterfaceContract is not established on reference when it's not calculated
by introspection
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ 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.