You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2012/02/17 17:02:27 UTC
Overriding remotable
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
Re: Overriding remotable
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Feb 20, 2012 at 10:19 AM, Simon Nash <na...@apache.org> wrote:
> Raymond Feng wrote:
>>
>> Hi,
>>
>> At that time, I was questioning the merit to introduce "remotable"
>> attribute in the composite to override the Java interface. Really, to make
>> the service remotable, the interface design has to take that into
>> consideration upfront, especially the data model (for example, DTO instead
>> of an Object).
>>
> The rationale for this is that some Java interfaces can't be modified to
> add SCA annotations, perhaps because they're in some standard spec or a
> pre-existing framework library. However, these interfaces may have been
> designed to have remotable semantics (SCA didn't invent remotability!)
>
> Simon
>
>> Thanks,
>> Raymond
>>
>>
>> On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws <simonslaws@googlemail.com
>> <ma...@googlemail.com>> wrote:
>>
>> On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
>> <luckbr1975@gmail.com <ma...@gmail.com>> wrote:
>> > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
>> <simonslaws@googlemail.com <ma...@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/ <http://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
>> <http://tuscany.apache.org>
>>
>> >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>> <http://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://people.apache.org/%7Elresende>
>>
>> > 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
>> <http://tuscany.apache.org>
>>
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>> <http://tuscanyinaction.com>
>>
>>
>
I haven't heard any technical reasons for not fixing this (or for
calculating the databinding information for local interfaces on the
off chance they have their remotability overridden) so I'm going to go
ahead and apply the patch that I attached to TUSCANY-3459.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Overriding remotable
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> At that time, I was questioning the merit to introduce "remotable"
> attribute in the composite to override the Java interface. Really, to
> make the service remotable, the interface design has to take that into
> consideration upfront, especially the data model (for example, DTO
> instead of an Object).
>
The rationale for this is that some Java interfaces can't be modified to
add SCA annotations, perhaps because they're in some standard spec or a
pre-existing framework library. However, these interfaces may have been
designed to have remotable semantics (SCA didn't invent remotability!)
Simon
> Thanks,
> Raymond
>
> On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws <simonslaws@googlemail.com
> <ma...@googlemail.com>> wrote:
>
> On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
> <luckbr1975@gmail.com <ma...@gmail.com>> wrote:
> > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
> <simonslaws@googlemail.com <ma...@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/ <http://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
> <http://tuscany.apache.org>
> >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
> <http://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://people.apache.org/%7Elresende>
> > 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 <http://tuscany.apache.org>
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
> <http://tuscanyinaction.com>
>
>
Re: Overriding remotable
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Feb 18, 2012 at 7:25 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> At that time, I was questioning the merit to introduce "remotable" attribute
> in the composite to override the Java interface. Really, to make the service
> remotable, the interface design has to take that into consideration upfront,
> especially the data model (for example, DTO instead of an Object).
>
> Thanks,
> Raymond
>
>
> On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende <lu...@gmail.com>
>> wrote:
>> > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws <si...@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
>
>
Ok, thanks Raymond
They went ahead and did it and it's now in the spec.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Overriding remotable
Posted by Raymond Feng <en...@gmail.com>.
Hi,
At that time, I was questioning the merit to introduce "remotable"
attribute in the composite to override the Java interface. Really, to make
the service remotable, the interface design has to take that into
consideration upfront, especially the data model (for example, DTO instead
of an Object).
Thanks,
Raymond
On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws <si...@googlemail.com>wrote:
> On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende <lu...@gmail.com>
> wrote:
> > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws <si...@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
>
Re: Overriding remotable
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws <si...@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
Re: Overriding remotable
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws <si...@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/