[
https://issues.apache.org/jira/browse/TUSCANY-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2658:
--------------------------------
Attachment: 2658.recreate.with.componentType
Simon, I have to agree with your point. As much as I wish the user could, in
this case, implicitly define a componentType in the component defintion, I have
to admit we can't flagrantly violate the Assembly spec without more spec-level
discussion.
I'd originally hoped to hash out this type of point in the earlier ML
discussion I linked to, but no one raised this point before I decided to open
the JIRA.
As it turns out, even with .componentType files with bidirectional interface
definitions, we still apparently have a problem when the forward intf lacks the
@Callback, as my updated recreate patch to the original itest/callback-basic
shows.
So we probably have a code fix to look at in any case...which we can say is the
subject of this JIRA.
But if there's any interest in exploring the idea of allowing for implicitly
define a componentType in the component definition, it can be done outside of
this JIRA, since it requires reconsidering of a fundamental Assembly spec
statement.
Thanks,Scott
> @Callback should not be required on forward Java interface if component
> ref/service intf definition fully defines forward/callback interface pair
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2658
> URL: https://issues.apache.org/jira/browse/TUSCANY-2658
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Java Implementation Extension
> Reporter: Scott Kurz
> Attachments: 2658.recreate, 2658.recreate.with.componentType
>
>
> If we have a component reference/service interface definition which contains
> a forward/callback interface pair, then our runtime should not also require
> the @Callback to be present on the forward Java interface.
> E.g. if we have:
> <component name="CallBackBasicClient">
> <implementation.java ... />
> <reference name="aCallBackService"
> target="CallBackBasicService">
> <interface.java
> interface="org.apache.tuscany.sca.test.CallBackBasicService"
>
> callbackInterface="org.apache.tuscany.sca.test.CallBackBasicCallBack"/>
> </reference>
> ...
> <component name="CallBackBasicService">
> <implementation.java .../>
> <service name="CallBackBasicService">
> <interface.java
> interface="org.apache.tuscany.sca.test.CallBackBasicService"
>
> callbackInterface="org.apache.tuscany.sca.test.CallBackBasicCallBack"/>
> </service>
> </component>
>
> then we shouldn't require the CallBackBasicService class to carry the
> annotation: @Callback(CallBackBasicCallBack.class)
> In modifying the itest/callback-basic test I saw we had this problem (will
> attach this recreate patch).
> Issue was discussed here
> http://www.mail-archive.com/[email protected]/msg03087.html
> and the motivating use case was the desire to avoid having to add @Callback
> to a wsimport-generated Java interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
