You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Greg Dritschler (JIRA)" <de...@tuscany.apache.org> on 2011/09/17 00:17:08 UTC

[jira] [Issue Comment Edited] (TUSCANY-3948) Support @Remotable on implementation class, reference field, or reference setter method

    [ https://issues.apache.org/jira/browse/TUSCANY-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106859#comment-13106859 ] 

Greg Dritschler edited comment on TUSCANY-3948 at 9/16/11 10:15 PM:
--------------------------------------------------------------------

I have investigated the failure in POJO_8017.

This compliance tests is testing exactly what I'm trying to fix in this JIRA. It passes in the current stream because Tuscany is ignoring the Remotable annotation on both the reference side and service side, so it was really executing with a local interface (and not detecting it).

My initial patch fixed the service side.  It did not fix the reference side because the test places the annotation in a peculiar place:

	@Reference
	public void setReference1( @Remotable Service1NoRemotable aReference ) {
		reference1 = aReference;
	}

My original patch did not handle @Remotable on the argument.  It only handled it on the method, like this:

	@Reference
        @Remotable
	public void setReference1(Service1NoRemotable aReference ) {
		reference1 = aReference;
	}

I have updated the patch to handle either case.  I assume either form is allowed and the two are equivalent.

      was (Author: gregdritschler):
    I have investigated the failure in POJO_8017.

This compliance tests is testing exactly what I'm trying to fix in this JIRA. It passes in the current stream because Tuscany is ignoring the Remotable annotation on both the reference side and service side, so it was really executing with a local interface (and not detecting it).

My initial patch fixed the service side.  It did not fix the reference side because the test places it in a peculiar place:

	@Reference
	public void setReference1( @Remotable Service1NoRemotable aReference ) {
		reference1 = aReference;
	}

My original patch did not handle @Remotable on the argument.  It only handled it on the method, like this:

	@Reference
        @Remotable
	public void setReference1(Service1NoRemotable aReference ) {
		reference1 = aReference;
	}

I have updated the patch to handle either case.  I assume either form is allowed and the two are equivalent.
  
> Support @Remotable on implementation class, reference field, or reference setter method
> ---------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-3948
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3948
>             Project: Tuscany
>          Issue Type: Bug
>    Affects Versions: Java-SCA-2.0
>            Reporter: Greg Dritschler
>            Priority: Minor
>
> The Java CAA spec says this about @Remotable:
> 3177 The @Remotable annotation has no attributes. When placed on a Java service interface, it indicates that
> 3178 the interface is remotable. When placed on a Java service implementation class, it indicates that all SCA
> 3179 service interfaces provided by the class (including the class itself, if the class defines an SCA service
> 3180 interface) are remotable. When placed on a service reference, it indicates that the interface for the
> 3181 reference is remotable.
> I tried using @Remotable in this way...
>     @Reference
>     @Remotable
>     public Service1 reference1;
> ... but it fails with a compile error:  annotation type not applicable to this kind of declaration.
> The Remotable annotation class in Tuscany has @Target(TYPE).
> The spec says it is supposed to be @Target(TYPE,METHOD,FIELD,PARAMETER).
> I also notice that ReferenceProcessor doesn't have any code to deal with Remotable.
> I also discovered that while ServiceProcessor tries to propagate @Remotable on an implementation class to the service interfaces, it doesn't work because it marks the interface remotable after introspection is done.  This doesn't work because some introspectors behave differently for local vs remote interfaces.
> I am submitting a patch to fix the above problems.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira