[jira] [Updated] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite
[
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws updated TUSCANY-3459:
Attachment: 3459.patch
General changes to make the infrastructure apply the remotable overide.
JSON-RPC (and other) binding fails if Interface is marked as remotable only
in the composite
-
Key: TUSCANY-3459
URL: https://issues.apache.org/jira/browse/TUSCANY-3459
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.x
Attachments: 3459.patch
public interface Catalog {
Item[] get();
}
component name=VegetablesCatalog
implementation.java class=services.sca.FruitsCatalogImpl/
service name=Catalog
interface.java interface=services.Catalog
remotable=true/
tuscany:binding.jsonrpc
uri=http://localhost:8085/VegetableCatalog; /
/service
/component
at $Proxy7.get(Unknown Source)
at services.sca.CatalogAggregatorImpl.get(CatalogAggregatorImpl.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:115)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
at $Proxy7.get(Unknown Source)
at
org.apache.tuscany.sca.performance.CatalogRemoteJsonRPCTest.testCatalog(CatalogRemoteJsonRPCTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestDecorator.run(TestDecorator.java:32)
at junit.extensions.RepeatedTest.run(RepeatedTest.java:30)
at com.clarkware.junitperf.ThreadedTest$TestRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jabsorb.serializer.UnmarshallException: element 0 no
serializer found that can unmarshall java.lang.String to services.Item
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:216)
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:692)
at org.jabsorb.client.Client.invoke(Client.java:226)
at org.jabsorb.client.Client.invoke(Client.java:156)
at
org.apache.tuscany.sca.binding.jsonrpc.provider.JSONRPCClientInvoker.invoke(JSONRPCClientInvoker.java:60)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
... 27 more
Caused by: org.jabsorb.serializer.UnmarshallException: no serializer found
that can unmarshall java.lang.String to services.Item
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:705)
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:209)
... 33 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Overriding remotable
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;
}
ListOperation 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
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 simonsl...@googlemail.comwrote:
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;
}
ListOperation 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
[jira] [Created] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
Tuscany needs to process profile intents as in OSOA --- Key: TUSCANY-4017 URL: https://issues.apache.org/jira/browse/TUSCANY-4017 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-Beta3 Reporter: Rashmi Hunt Fix For: Java-SCA-2.x In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when I tried to get intent name from PolicySubject. In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany used to return it as 'atleastOnce'/'atMostOnce' as intent name ( PolicyComputationUtils.expandProfileIntents()) , which seems to be missing in OASIS implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
