On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende <luckbr1...@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws <simonsl...@googlemail.com> wrote:
>> 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
>
> It seems that there were some more issues around this (see [1])...
> I'll try to dig out some more and see if I can remember little more
> from when I was working on this in the past.
>
> [1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/

Ok, that's interesting Luciano. So I don't loose it I added a patch to
(https://issues.apache.org/jira/browse/TUSCANY-3459) with the changes
required to make the infrastructure apply the remotable override. It
passes all the tests we have active at the moment.

I don't really understand Raymond's comment "It seems to me that we
pretty much don't differentiate local and remote interfaces any more
with such changes" from the thread you linked to. It's not clear
whether this is a comment about the aesthetics of having a flag with
which to affect the remotable status of an interface or a comment
suggesting that the infrastructure relies on there being no
databinding set for local interfaces. I can have a look at some local
tests to see if there is any spurious databinding processing going on.

Simon
-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Reply via email to