Re: Overriding remotable

2012-02-20 Thread Simon Nash 

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 > wrote:


On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
mailto:luckbr1...@gmail.com>> wrote:
 > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
mailto: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:
 >>
 >>
 >>
 >>
 >>   
 >>   http://binding.ws/>>
 >>
 >>
 >>
 >> 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 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] [Assigned] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA

2012-02-20 Thread Simon Laws (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws reassigned TUSCANY-4017:
---

Assignee: Simon Laws

> 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
>Assignee: Simon Laws
> 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

[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA

2012-02-20 Thread Simon Laws (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211771#comment-13211771
 ] 

Simon Laws commented on TUSCANY-4017:
-

At revision: 1291186 I added a test case which looks at how the exactlyOnce 
profile intent resolves to atLeastOnce and atMostOnce in the endpoint. I need a 
bit more information about where in the code you were looking for the resolved 
intents. 

> 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
>Assignee: Simon Laws
> 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

[jira] [Assigned] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start

2012-02-20 Thread Simon Laws (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws reassigned TUSCANY-4016:
---

Assignee: Simon Laws

> NodeImpl startComposite forgets about a composite if there is a failure on 
> start
> 
>
> Key: TUSCANY-4016
> URL: https://issues.apache.org/jira/browse/TUSCANY-4016
> Project: Tuscany
>  Issue Type: Bug
>  Components: SCA Java Runtime
>Affects Versions: Java-SCA-2.0-Beta3
> Environment: All
>Reporter: Simon Laws
>Assignee: Simon Laws
>
> org.apache.tuscany.sca.impl.NodeImpl does the following on start
> public void startComposite(String contributionURI, String compositeURI) 
> throws ActivationException, ValidationException, ContributionReadException {
> String key = contributionURI+"/"+compositeURI;
> if (startedComposites.containsKey(key)) {
> throw new IllegalStateException("composite already started: " + 
> compositeURI);
> }
> DeployedComposite dc = stoppedComposites.remove(key);
> if (dc != null) {
> dc.start();
> startedComposites.put(key, dc);
> and the following on stop
> String key = contributionURI+"/"+compositeURI;
> DeployedComposite dc = startedComposites.remove(key);
> if (dc != null) {
> dc.stop();
> stoppedComposites.put(key, dc);
> } else {
> If an error is thrown on start it won't be in startedComposites but some of 
> the providers may have been started. So even in the failure case we should 
> consider the composite partially started so that it can be stopped correctly. 

--
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

2012-02-20 Thread Simon Laws 
On Mon, Feb 20, 2012 at 10:19 AM, Simon Nash  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 > > wrote:
>>
>>    On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
>>    mailto:luckbr1...@gmail.com>> wrote:
>>     > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
>>    mailto: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:
>>     >>
>>     >>    
>>     >>        
>>     >>        
>>     >>           >    remotable="true"/>
>>     >>           http://binding.ws/>>
>>
>>     >>        
>>     >>    
>>     >>
>>     >> 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 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.apach

[jira] [Closed] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite

2012-02-20 Thread Simon Laws (Closed) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-3459.
---

Resolution: Fixed

I applied the patch at revision: 1291191  which should provide a general 
solution to this by allowing the interface remotable status to be overriden.


> 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();
> }
>   
>
>   
>remotable="true"/>
>uri="http://localhost:8085/VegetableCatalog"; />
> 
>
> 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

[jira] [Closed] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start

2012-02-20 Thread Simon Laws (Closed) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-4016.
---

   Resolution: Fixed
Fix Version/s: Java-SCA-2.0

At revision: 1291234  I committed a fix and a test. On closer inspection it 
turns out that we added code to the Activator a while back to stop providers if 
there is a failure on start. So the extra stop added here may not do anything 
but it won't do any harm. Moving the stopped composite to the stopped list does 
allow the unused contributions to be unloaded if the appropriate operation is 
called. 


> NodeImpl startComposite forgets about a composite if there is a failure on 
> start
> 
>
> Key: TUSCANY-4016
> URL: https://issues.apache.org/jira/browse/TUSCANY-4016
> Project: Tuscany
>  Issue Type: Bug
>  Components: SCA Java Runtime
>Affects Versions: Java-SCA-2.0-Beta3
> Environment: All
>Reporter: Simon Laws
>Assignee: Simon Laws
> Fix For: Java-SCA-2.0
>
>
> org.apache.tuscany.sca.impl.NodeImpl does the following on start
> public void startComposite(String contributionURI, String compositeURI) 
> throws ActivationException, ValidationException, ContributionReadException {
> String key = contributionURI+"/"+compositeURI;
> if (startedComposites.containsKey(key)) {
> throw new IllegalStateException("composite already started: " + 
> compositeURI);
> }
> DeployedComposite dc = stoppedComposites.remove(key);
> if (dc != null) {
> dc.start();
> startedComposites.put(key, dc);
> and the following on stop
> String key = contributionURI+"/"+compositeURI;
> DeployedComposite dc = startedComposites.remove(key);
> if (dc != null) {
> dc.stop();
> stoppedComposites.put(key, dc);
> } else {
> If an error is thrown on start it won't be in startedComposites but some of 
> the providers may have been started. So even in the failure case we should 
> consider the composite partially started so that it can be stopped correctly. 

--
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

[jira] [Closed] (TUSCANY-2735) Testing case where interface extends other that use Generics

2012-02-20 Thread Simon Laws (Closed) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-2735.
---

   Resolution: Fixed
Fix Version/s: Java-SCA-2.0

Patch applied to 2.x at revision: 1291283. Thanks Rodolfo. 

> Testing case where interface extends other that use Generics
> 
>
> Key: TUSCANY-2735
> URL: https://issues.apache.org/jira/browse/TUSCANY-2735
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
>Affects Versions: Java-SCA-1.3.2
> Environment: Ubuntu, Tuscany SCA 1.3.2, jrockit_150_11
>Reporter: Rodolfo Dias
>Assignee: Rodolfo Dias
>Priority: Minor
> Fix For: Java-SCA-2.0, Java-SCA-2.x
>
> Attachments: ServicesTest.diff, itest-services-1.3.2-JIRA-2735.jar, 
> itest-services-1.3.2-src-jira-2735.jar
>
>
> Project itest-service not test case where interface extends other that use 
> Generics.

--
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

[jira] [Closed] (TUSCANY-3869) WSDL data types not generated correctly

2012-02-20 Thread Simon Laws (Closed) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-3869.
---

Resolution: Fixed

I believe this is fixed now as I applied the 1.x/TUSCANY-3298 fixes to 2.x and 
took the WSDL verify tests from 1.x and added them to the wsdlgen itest on 2.x.

> WSDL data types not generated correctly
> ---
>
> Key: TUSCANY-3869
> URL: https://issues.apache.org/jira/browse/TUSCANY-3869
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-2.0-Beta2
> Environment: All
>Reporter: David Cueva
>  Labels: axis2, jaxb, wsdl
> Fix For: Java-SCA-2.0
>
>
> When a @Remotable interface receives or returns a POJO, the WSDL generated 
> when using  is not valid.
> This limits the applicability of  to methods receiving or 
> returning primitive types or wrappers only.
> If the WSDL is loaded in SoapUI, the following error is thrown:
> Fri Jun 03 11:43:04 EDT 2011:WARN:Error: 
> http://localhost:8090/Registration?wsdl:0: error: src-resolve.a: Could not 
> find type 'conference@http://dc.simple/'. Do you mean to refer to the type 
> named conference (in Registration_3Fwsdl)?
> It seems that the namespace being used for the type definition is missing or 
> misplaced
> ---
> More information:
> Mail thread
> [http://mail-archives.apache.org/mod_mbox/tuscany-user/201106.mbox/%3cbanlktimh6bbuwucumea9ifx8wtyrdw0...@mail.gmail.com%3E]
> Sample project to reproduce the issue:
> [http://cid-6f107cd11157608a.office.live.com/self.aspx/Tuscany/02.SimpleWS.zip]
> The offending WSDL
> [http://cid-6f107cd11157608a.office.live.com/self.aspx/Tuscany/Registration.wsdl]
> Scott Kurz has indicated this is probably related to
> [https://issues.apache.org/jira/browse/TUSCANY-3298]
> Info on the 1.x issue already resolved
> [http://www.mail-archive.com/dev%40tuscany.apache.org/msg10002.html]
> ---
> Copy of the original mail thread
> Hi there
> I am building a composite using the Tuscany 2.0-Beta2, The composite includes 
> a single component with one service. After compiling, the contribution loads 
> in Tuscany with no issues. I can even open the WSDL in the browser, but when 
> trying to test the service I get the following exception in 
> SoapUI/AdarnaStorm/EclipseWTP:
> Fri Jun 03 11:43:04 EDT 2011:WARN:Error: 
> http://localhost:8090/Registration?wsdl:0: error: src-resolve.a: Could not 
> find type 'conference@http://dc.simple/'. Do you mean to refer to the type 
> named conference (in Registration_3Fwsdl)?
> I hit a wall with this problem, I have searched the web quite a lot but 
> nothing. It may be a trivial setting that I am overlooking in my code.
> Basically, the contribution is supposed to be a service to register for a 
> conference. It has three very simple classes, and the composite definition:
> // ---
> // The Conference POJO: Conference.java
> package simple.dc.model;
> public class Conference {
>   private int id;
>   private String topic;
>  
>   // Here getters and setters generated by Eclipse
> }
> // ---
> // The remotable interface: Registration.java
> package simple.dc;
> import org.oasisopen.sca.annotation.Remotable;
> import simple.dc.model.Conference;
> @Remotable
> public interface Registration {
>public int register(Conference conference);
> }
> // ---
> // The component implementation: RegistrationImpl.java
> package simple.dc.impl;
> import org.oasisopen.sca.annotation.Service;
> import simple.dc.Registration;
> import simple.dc.model.Conference;
> @Service(Registration.class)
> public class RegistrationImpl implements Registration {
>   @Override
>   public int register(Conference conference) {
> System.out.println("Registering for conference: " + 
> conference.getTopic());
> return 1234; //confirmation number
>   }
> }
> // ---
> // The composite: SimpleWS.composite
> 
> http://docs.oasis-open.org/ns/opencsa/sca/200912";
>   xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1";
>   name="SimpleWSComposite"
>   targetNamespace="http://dc.simple";>
>   
> 
> 
>http://localhost:8090/Registration"/>
> 
>   
>  
> 
> No errors or warnings during compilation. I am using Gradle with the 
> following dependencies:
> compile group: 'org.apache.tuscany.sca', name: 'tuscany-base-runtime', 
> version: '2.0-Beta2'
> compile group: 'org.apache.tuscany.sca', name: 
> 'tuscany-binding-ws-runtime-axis2', version: '2.0-Beta2'
> compile group: 'org.apache.tuscany.sca', name: 'tuscany-host-jetty', 
> version: '2.0-Beta2'
> compile group: 'org.apache.tuscany.sca', name: 'tuscany-host-http', 
> version: '2.0-Beta2'
> I install the contribut

[jira] [Closed] (TUSCANY-3859) tuscany generated wsdl: namespace prefix for the attribute "base" is missing

2012-02-20 Thread Simon Laws (Closed) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-3859.
---


I believe this is fixed now as I applied the 1.x/TUSCANY-3298 fixes to 2.x and 
took the WSDL verify tests from 1.x and added them to the wsdlgen itest on 2.x.

> tuscany generated wsdl: namespace prefix for the attribute "base" is missing
> 
>
> Key: TUSCANY-3859
> URL: https://issues.apache.org/jira/browse/TUSCANY-3859
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-1.6.1
>Reporter: Antonio De Berardis
>Assignee: Simon Nash
> Fix For: Java-SCA-1.x
>
>
> I have a problem when I let tuscany generate the wsdl for a service.
> Namespace prefix for the attribute "base" is missing.
> If I have an object that extends another object, the schema generated
> should be:
> ...
> 
> 
> 
> ...
> but i got
> ...
> 
> 
> 
> ...

--
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

[jira] [Closed] (TUSCANY-3838) PolicyHandler.afterInvoke() is skipped when AxisFault occurs

2012-02-20 Thread Simon Laws (Closed) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-3838.
---


I believe this is fixed now. The policy runtime is slightly different in 2.x 
when compared to 1.x. In 2.x we have policy interceptors on the operation wire 
and on the binding wire and the binding wire providers get the opportunity to 
configure the binding. In the exception case the exception, wrapped in a 
Message object, should flow back along the wire and through the interceptors in 
the same way as a non-exception response does. 

> PolicyHandler.afterInvoke() is skipped when AxisFault occurs
> 
>
> Key: TUSCANY-3838
> URL: https://issues.apache.org/jira/browse/TUSCANY-3838
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Policy
>Affects Versions: Java-SCA-1.6
> Environment: Windows 2003.
>Reporter: Gang Yang
>Assignee: Simon Nash
> Fix For: Java-SCA-1.x
>
> Attachments: code-snippet.txt
>
>
> When AxisFault is generated from invoking a remote service using WS binding, 
> the reference side PolicyHandler.afterInvoke() is not called.

--
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

TUSCANY-4005 is in error

2012-02-20 Thread Greg Dritschler 
I believe the fix for TUSCANY-4005 is in error.  The goal of the fix was to
comply with this requirement:

The target component has multiple services. According to the following text
in the assembly specification, the target component must have one and only
one service with a compatible interface.

 1844 If  is not present, the target component MUST have one
and only
 1845 one service with an interface that is a compatible superset of the
wire source's
 1845 interface and satisifies the policy requirements of the wire source,
and the SCA
 1846 runtime MUST use this service for the wire. [ASM60048]

The fix checks if there are multiple candidate targets BEFORE DOING ANY
FILTERING for interface compatibility or policy matching.  If the target
does have one and only one service with a compatible interface and policy,
you now get the error introduced by the fix.  This was not the intention.

[jira] [Created] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer

2012-02-20 Thread Jennifer A Thompson (Created) (JIRA) 
JMS TransportServiceInterceptor using wrong values to set JMS headers in 
producer
-

 Key: TUSCANY-4018
 URL: https://issues.apache.org/jira/browse/TUSCANY-4018
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-2.x
Reporter: Jennifer A Thompson
 Fix For: Java-SCA-2.x


In TransportServiceInterceptor.invokeResponse is setting the effective 
TimeToLive, Priority in the response message, but when the values are set in 
the producer, the values from the request are used, potentially leading to an 
incorrect value. So the following:

 // Set jms header attributes in producer, not message.
int deliveryMode = requestJMSMsg.getJMSDeliveryMode();
producer.setDeliveryMode(deliveryMode);
int deliveryPriority = requestJMSMsg.getJMSPriority();
producer.setPriority(deliveryPriority);
long timeToLive = requestJMSMsg.getJMSExpiration();
producer.setTimeToLive(timeToLive);


Should be:

// Set jms header attributes in producer, not message.
producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode());
producer.setPriority(responseJMSMsg.getJMSPriority());
producer.setTimeToLive(responseJMSMsg.getJMSExpiration());

--
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

[jira] [Updated] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer

2012-02-20 Thread Jennifer A Thompson (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jennifer A Thompson updated TUSCANY-4018:
-

Attachment: Tuscany-4018.patch

> JMS TransportServiceInterceptor using wrong values to set JMS headers in 
> producer
> -
>
> Key: TUSCANY-4018
> URL: https://issues.apache.org/jira/browse/TUSCANY-4018
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA JMS Binding Extension
>Affects Versions: Java-SCA-2.x
>Reporter: Jennifer A Thompson
> Fix For: Java-SCA-2.x
>
> Attachments: Tuscany-4018.patch
>
>
> In TransportServiceInterceptor.invokeResponse is setting the effective 
> TimeToLive, Priority in the response message, but when the values are set in 
> the producer, the values from the request are used, potentially leading to an 
> incorrect value. So the following:
>  // Set jms header attributes in producer, not message.
> int deliveryMode = requestJMSMsg.getJMSDeliveryMode();
> producer.setDeliveryMode(deliveryMode);
> int deliveryPriority = requestJMSMsg.getJMSPriority();
> producer.setPriority(deliveryPriority);
> long timeToLive = requestJMSMsg.getJMSExpiration();
> producer.setTimeToLive(timeToLive);
> Should be:
> // Set jms header attributes in producer, not message.
> producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode());
> producer.setPriority(responseJMSMsg.getJMSPriority());
> producer.setTimeToLive(responseJMSMsg.getJMSExpiration());

--
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