On Sat, Feb 18, 2012 at 7:25 PM, Raymond Feng <[email protected]> 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 <[email protected]> > wrote: >> >> On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende <[email protected]> >> wrote: >> > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws <[email protected]> >> > 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
