In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
<component name="HelloworldComponent">
<implementation.java class="sample.HelloworldImpl"/>
<service name="HelloworldImpl">
<interface.java interface="sample.Helloworld" remotable="true"/>
<binding.ws/>
</service>
</component>
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When Helloworld looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code there are
tests for remotable which prevents further processing if an interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
List<Operation> operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
