[jira] Commented: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598229#action_12598229 ] Mike Edwards commented on TUSCANY-2328: --- Ashwini, Thanks for catching this one. Do you have a test case that shows this problem, please? I'd be very grateful if you could attach it to this JIRA. equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards reassigned TUSCANY-2328: - Assignee: Mike Edwards equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani Assignee: Mike Edwards In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2328) equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-2328. --- Resolution: Fixed Fix committed in 658449. Changed BPELImplementationProcessor to compare the QNames of the PortTypes using equals() rather than comparing the PortType elements themselves. equals method is not overridden and hashcode generated is different for PortType comparison in BPELImplementationProcessor class Key: TUSCANY-2328 URL: https://issues.apache.org/jira/browse/TUSCANY-2328 Project: Tuscany Issue Type: Bug Components: Java SCA BPEL Implementation Extension Affects Versions: Java-SCA-1.2 Environment: Windows XP Reporter: Ashwini Kumar Jeksani Assignee: Mike Edwards In org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor the comparison between PortType done in generateReference generateService is not proper, it is trying to compare the hascodes of two PortTypes and assigning the WSDLInterface but as the equals method in the PortType is not overridden the hashcodes are different and the WSDLInterface is not set properly. Problem: anInterface.getPortType().equals(callPT) is not compared properly as the equals method is not overridden and hashcode generated is different. Solution: Converting the portType to String.. anInterface.getPortType().toString().equals(callPT.toString()) Could anyone commit these changes in the code or provide a better solution to this. Thanks Regards, Ashwini Kumar Jeksani -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2322) ?WSDL fails when BPEL partnerLink extensions are available
[
https://issues.apache.org/jira/browse/TUSCANY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Edwards resolved TUSCANY-2322.
---
Resolution: Fixed
Fixed by a change to the marshall method of the BPELExtensionHandler class
committed in 657338 - output of the BPEL extension elements now uses
prefix:localName format in the XML rendering.
?WSDL fails when BPEL partnerLink extensions are available
--
Key: TUSCANY-2322
URL: https://issues.apache.org/jira/browse/TUSCANY-2322
Project: Tuscany
Issue Type: Bug
Components: Java SCA BPEL Implementation Extension, Java SCA Misc
Binding Extensions
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
Fix For: Java-SCA-Next
One can reproduce this by running the itest/bpel/helloworld-ws and point your
browser to : http://localhost:8085/HelloPartnerLink?wsdl
The result is :
XML Parsing Error: not well-formed
Location: http://localhost:8085/HelloPartnerLink?wsdl
Line Number 44, Column
2:{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}partnerLinkType
name=HelloPartnerLinkType
-^
The wsdl sent to the browser looks like :
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=helloworld
targetNamespace=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
xmlns:tns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
xmlns:bpws=http://schemas.xmlsoap.org/ws/2004/03/business-process/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:plnk=http://schemas.xmlsoap.org/ws/2004/03/partner-link/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
schema elementFormDefault=qualified
targetNamespace=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
xmlns=http://www.w3.org/2001/XMLSchema;
element name=hello
complexType
sequence
element name=message type=xsd:string/
/sequence
/complexType
/element
/schema
/wsdl:types
wsdl:message name=HelloMessage
wsdl:part name=TestPart element=tns:hello
/wsdl:part
/wsdl:message
wsdl:portType name=HelloPortType
wsdl:operation name=hello
wsdl:input name=TestIn message=tns:HelloMessage
/wsdl:input
wsdl:output name=TestOut message=tns:HelloMessage
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=HelloSoapBinding type=tns:HelloPortType
wsdlsoap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=hello
wsdlsoap:operation soapAction=/
wsdl:input name=TestIn
wsdlsoap:body use=literal/
/wsdl:input
wsdl:output name=TestOut
wsdlsoap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=HelloService
wsdl:port name=HelloPort binding=tns:HelloSoapBinding
wsdlsoap:address location=http://9.76.45.104:8085/HelloPartnerLink/
/wsdl:port
/wsdl:service
{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}partnerLinkType
name=HelloPartnerLinkType
{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}role name=me
portType={http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl}HelloPortType;
{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}role name=you
portType={http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl}HelloPortType;
/{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}partnerLinkType
/wsdl:definitions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596708#action_12596708 ] Mike Edwards commented on TUSCANY-2316: --- Scott, The ClassCastExceptions occur in the BPELInvoker.createInvocationMessage(...) method and are caused by that code being delivered message arguments that are not the DOM Elements that it expects. The InterfaceContract overwrite means that Axis2 related OMElements are delivered. Fixing the InterfaceContract overwrite in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider (by cloning the Interface...) then reveals a second problem, this time associated with the DataBinding code. The DataBinding code converting from OMElements to DOM generates a message which has a Document root element, while the code in createInvocationMessage expects only the internal Element elements. The simplest fix for this is to modify the createInvocationMessage code to strip off the Document element, if there is one. Doing this then reveals yet another problem, this time with the exact form of the elements in the DOM tree passed in from the DataBinding code - this causes an exception within the ODE BPEL server code. Still investigating that one with Luciano Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2322) ?WSDL fails when BPEL partnerLink extensions are available
[
https://issues.apache.org/jira/browse/TUSCANY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596968#action_12596968
]
Mike Edwards commented on TUSCANY-2322:
---
Well, I know exactly how I can fix this issue - the code for writing out the
BPEL extension elements needs a minor tweak to output the prefix form of the
QName for those elements rather than the full form shown above. Supposedly,
the form shown above is an acceptable standard format, but if it is being
rejected, we must change it
?WSDL fails when BPEL partnerLink extensions are available
--
Key: TUSCANY-2322
URL: https://issues.apache.org/jira/browse/TUSCANY-2322
Project: Tuscany
Issue Type: Bug
Components: Java SCA BPEL Implementation Extension, Java SCA Misc
Binding Extensions
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
Fix For: Java-SCA-Next
One can reproduce this by running the itest/bpel/helloworld-ws and point your
browser to : http://localhost:8085/HelloPartnerLink?wsdl
The result is :
XML Parsing Error: not well-formed
Location: http://localhost:8085/HelloPartnerLink?wsdl
Line Number 44, Column
2:{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}partnerLinkType
name=HelloPartnerLinkType
-^
The wsdl sent to the browser looks like :
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=helloworld
targetNamespace=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
xmlns:tns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
xmlns:bpws=http://schemas.xmlsoap.org/ws/2004/03/business-process/;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:plnk=http://schemas.xmlsoap.org/ws/2004/03/partner-link/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
schema elementFormDefault=qualified
targetNamespace=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
xmlns=http://www.w3.org/2001/XMLSchema;
element name=hello
complexType
sequence
element name=message type=xsd:string/
/sequence
/complexType
/element
/schema
/wsdl:types
wsdl:message name=HelloMessage
wsdl:part name=TestPart element=tns:hello
/wsdl:part
/wsdl:message
wsdl:portType name=HelloPortType
wsdl:operation name=hello
wsdl:input name=TestIn message=tns:HelloMessage
/wsdl:input
wsdl:output name=TestOut message=tns:HelloMessage
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=HelloSoapBinding type=tns:HelloPortType
wsdlsoap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=hello
wsdlsoap:operation soapAction=/
wsdl:input name=TestIn
wsdlsoap:body use=literal/
/wsdl:input
wsdl:output name=TestOut
wsdlsoap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=HelloService
wsdl:port name=HelloPort binding=tns:HelloSoapBinding
wsdlsoap:address location=http://9.76.45.104:8085/HelloPartnerLink/
/wsdl:port
/wsdl:service
{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}partnerLinkType
name=HelloPartnerLinkType
{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}role name=me
portType={http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl}HelloPortType;
{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}role name=you
portType={http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl}HelloPortType;
/{http://schemas.xmlsoap.org/ws/2004/03/partner-link/}partnerLinkType
/wsdl:definitions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards updated TUSCANY-2316: -- Attachment: sample-helloworld-bpel-ws.zip Sample BPEL application which exposes the BPEL component as a Web service Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2278) Atom Binding Extension does not support PUT operations correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards resolved TUSCANY-2278. --- Resolution: Fixed Fixed by an update to AtomBindingUtil in revision 652361 Atom Binding Extension does not support PUT operations correctly Key: TUSCANY-2278 URL: https://issues.apache.org/jira/browse/TUSCANY-2278 Project: Tuscany Issue Type: Bug Components: Java SCA ATOM Binding Extension Affects Versions: Java-SCA-1.2 Environment: All Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-Next If a PUT operation is made using the Atom binding, the ID parameter for the data element, given by the client, is not passed to the operation of the component which offers the service. The fault appears to be on line 76 of AtomBindingUtil class where an ID is calculated but not passed to a suitable variable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2278) Atom Binding Extension does not support PUT operations correctly
Atom Binding Extension does not support PUT operations correctly Key: TUSCANY-2278 URL: https://issues.apache.org/jira/browse/TUSCANY-2278 Project: Tuscany Issue Type: Bug Components: Java SCA ATOM Binding Extension Affects Versions: Java-SCA-1.2 Environment: All Reporter: Mike Edwards Priority: Minor Fix For: Java-SCA-Next If a PUT operation is made using the Atom binding, the ID parameter for the data element, given by the client, is not passed to the operation of the component which offers the service. The fault appears to be on line 76 of AtomBindingUtil class where an ID is calculated but not passed to a suitable variable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2278) Atom Binding Extension does not support PUT operations correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards reassigned TUSCANY-2278: - Assignee: Mike Edwards Atom Binding Extension does not support PUT operations correctly Key: TUSCANY-2278 URL: https://issues.apache.org/jira/browse/TUSCANY-2278 Project: Tuscany Issue Type: Bug Components: Java SCA ATOM Binding Extension Affects Versions: Java-SCA-1.2 Environment: All Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-Next If a PUT operation is made using the Atom binding, the ID parameter for the data element, given by the client, is not passed to the operation of the component which offers the service. The fault appears to be on line 76 of AtomBindingUtil class where an ID is calculated but not passed to a suitable variable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
[ https://issues.apache.org/jira/browse/TUSCANY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587629#action_12587629 ] Mike Edwards commented on TUSCANY-2109: --- Folks, It is right to be concerned over the interface matching, but let's not lose sight of the context here. In general, there are two scenarios to consider: a) the reference is to a service which is defined within the SCA domain and SCA means are used to wire it b) the reference is to a service which is outside the SCA domain and wiring is through configuration of a specific binding and target endpoint In case a) it is possible that a Java interface as used by the client in its reference is exactly the same (file) as is being used by the provider in the service interface. If this is so, then in general, even if WSDL is generated, the reference and the target service are going to match, assuming that the same rules are followed at both ends for generating WSDL. (They should be following JAX-WS according to the specs). In case b), the normal situation would be for the client to be constructed using a Java interface derived from the target WSDL using the WSDL2JAVA tooling. While the reference targets the original service from which the WSDL came, there should be no problem, even if the reference itself is typed in terms of the Java interface. Things get interesting if the target service gets changed - and if the WSDL describing the interface changes. Now, to first order, you might say that if the WSDL is different, how do you know that the new service is compatible with the old one? Even if the operation names match and the input and output messages have the same structure, if the namespaces differ, there is no guarantee that the two services are actually compatible. This is an area where ESB style mediations come into play. Let's assume that the target service does use a different namespace, but that the operations and messages otherwise map. There is still a mediation necessary, since the transmitted messages will use the wrong namespace - the mediation simply has to remap the namespace when sending and receiving messages. More complex mediations are possible, where perhaps the operation names and message names don't match, although the structure and semantics do match. The question for us folks in SCA-land is whether we want to model mediations of this type as explicit components, with services and references that match the reference and endpoint that they are trying to mediate, or whether we want to extend our bindings definition to allow configuration of mediations within the bindings. The explicit component always works - and it can in principle perform much more complex meditations too (eg wholesale message trasnformation). The question is more whether it could be simpler, for simple mediations, to manage the mediations within the bindings. Yours, Mike. Conflicts between component reference interface and promoted composite reference interface are not detected Key: TUSCANY-2109 URL: https://issues.apache.org/jira/browse/TUSCANY-2109 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: All Reporter: Simon Nash Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: jira2109.patch, jira2109.zip See TUSCANY-2033 for the background to this problem. When a component reference defined with interface.java (either explicitly or implicitly by introspection) is promoted to a composite reference defined with interface.wsdl, and there is a namespace conflict between the component reference's interface.java and the composite reference's interface.wsdl. this conflict should be diagnosed as an error because it violates the spec rule that an interface specified on a composite reference must be a compatible superset of the interface of the promoted component reference. In this case, the composite interface is incompatible with the component reference because it has a different namespace. There is code in CompositeWireBuilderImpl.connectCompositeReferences() to handle connections between composite references and promoted compoennt references. The only interface processing performed in this method is to copy the component reference's interface contract to the composite reference's interface contract if the composite reference does not have an interface contract. Code should be added here to check for conflicts between the composite reference's interface and the component reference's interface if both interfaces are specified. Similar code should be added to
[jira] Closed: (TUSCANY-2000) Feed-aggregator Sample gives exceptions when run
[ https://issues.apache.org/jira/browse/TUSCANY-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards closed TUSCANY-2000. - Feed-aggregator Sample gives exceptions when run Key: TUSCANY-2000 URL: https://issues.apache.org/jira/browse/TUSCANY-2000 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Environment: Windows XP, Firefox 2.0.0.11 Reporter: Mike Edwards Priority: Minor Attachments: rssAggregator_exception.htm, rssAggregator_exception2.htm Run the Feed-aggregator sample: get exception when reading the URL http://localhost:8083/rssAggregator the web page containing the exception is in the file rssAggregator-exception.htm get another exception when reading the URL: http://localhost:8083/rssAggregator?feedType=atom_1.0 the web page containing the exception is in the file rssAggregator-exception2.htm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2000) Feed-aggregator Sample gives exceptions when run
[ https://issues.apache.org/jira/browse/TUSCANY-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560696#action_12560696 ] Mike Edwards commented on TUSCANY-2000: --- Yeah - it works OK now with RC3 - so it may just have been a temporary problem with the feed itself. I suppose it might be worth considering tweaking the sample to deal with the exceptions generated when it's the feed that's the problem, althought the primary exception thrown is a bit weird, looking at the listings attached to this JIRA. I'm concerned that if a newbie runs the sample and just gets the exception stack that they might think it is Tuscany's fault and not the feed. Mike. Feed-aggregator Sample gives exceptions when run Key: TUSCANY-2000 URL: https://issues.apache.org/jira/browse/TUSCANY-2000 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Environment: Windows XP, Firefox 2.0.0.11 Reporter: Mike Edwards Priority: Minor Attachments: rssAggregator_exception.htm, rssAggregator_exception2.htm Run the Feed-aggregator sample: get exception when reading the URL http://localhost:8083/rssAggregator the web page containing the exception is in the file rssAggregator-exception.htm get another exception when reading the URL: http://localhost:8083/rssAggregator?feedType=atom_1.0 the web page containing the exception is in the file rssAggregator-exception2.htm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2000) Feed-aggregator Sample gives exceptions when run
[ https://issues.apache.org/jira/browse/TUSCANY-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards updated TUSCANY-2000: -- Attachment: rssAggregator_exception.htm Feed-aggregator Sample gives exceptions when run Key: TUSCANY-2000 URL: https://issues.apache.org/jira/browse/TUSCANY-2000 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Environment: Windows XP, Firefox 2.0.0.11 Reporter: Mike Edwards Priority: Minor Attachments: rssAggregator_exception.htm, rssAggregator_exception2.htm Run the Feed-aggregator sample: get exception when reading the URL http://localhost:8083/rssAggregator the web page containing the exception is in the file rssAggregator-exception.htm get another exception when reading the URL: http://localhost:8083/rssAggregator?feedType=atom_1.0 the web page containing the exception is in the file rssAggregator-exception2.htm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2000) Feed-aggregator Sample gives exceptions when run
[ https://issues.apache.org/jira/browse/TUSCANY-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards updated TUSCANY-2000: -- Attachment: rssAggregator_exception2.htm Feed-aggregator Sample gives exceptions when run Key: TUSCANY-2000 URL: https://issues.apache.org/jira/browse/TUSCANY-2000 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Environment: Windows XP, Firefox 2.0.0.11 Reporter: Mike Edwards Priority: Minor Attachments: rssAggregator_exception.htm, rssAggregator_exception2.htm Run the Feed-aggregator sample: get exception when reading the URL http://localhost:8083/rssAggregator the web page containing the exception is in the file rssAggregator-exception.htm get another exception when reading the URL: http://localhost:8083/rssAggregator?feedType=atom_1.0 the web page containing the exception is in the file rssAggregator-exception2.htm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2000) Feed-aggregator Sample gives exceptions when run
Feed-aggregator Sample gives exceptions when run Key: TUSCANY-2000 URL: https://issues.apache.org/jira/browse/TUSCANY-2000 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Environment: Windows XP, Firefox 2.0.0.11 Reporter: Mike Edwards Priority: Minor Run the Feed-aggregator sample: get exception when reading the URL http://localhost:8083/rssAggregator the web page containing the exception is in the file rssAggregator-exception.htm get another exception when reading the URL: http://localhost:8083/rssAggregator?feedType=atom_1.0 the web page containing the exception is in the file rssAggregator-exception2.htm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2001) helloworld-ws-service-jms Sample does not shut down correctly
helloworld-ws-service-jms Sample does not shut down correctly - Key: TUSCANY-2001 URL: https://issues.apache.org/jira/browse/TUSCANY-2001 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.1 Environment: Windows, 1.1 RC2 Reporter: Mike Edwards Priority: Minor Running the helloworld-ws-service-jms sample, it runs correctly and the service can be called. However, the server is supposed to shutdown when enter is pressed - the sample appears to hang after printing the message: [java] HelloWorld server stopped -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1962) WSDL2JAVA Test not valid - generating code that is not checked
WSDL2JAVA Test not valid - generating code that is not checked -- Key: TUSCANY-1962 URL: https://issues.apache.org/jira/browse/TUSCANY-1962 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.1 Environment: All Reporter: Mike Edwards Priority: Minor Fix For: Java-SCA-Next The WSDL2Java tools has a testcase WSDL2JavaGeneratorTestcase that is an invalid testcase. This testcase runs the WSDL2Java tool and generates some output Java classes based on an input WSDL document. The files get placed into the target/wsdl2java-source directory. The current testcase only generates these files - it does not check that their contents are meaningful or correct. In reality, the generated code has problems: a) The code refers to SDO classes that are not generated by the testcase and which are not available in any obvious location. As a result the code does not compile. b) The generated code does not have import statements for the SDO classes that are used. Instead, the classes are used with full paths on each declaration. At the very least this is unacceptable style and it should be changed. There is no attempt in the test to check that the generated code conforms to some expected output. The test MUST be extended to do this if it is to be of any real value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1823) The getProperty() method on ComponentContext does not work
[
https://issues.apache.org/jira/browse/TUSCANY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533733
]
Mike Edwards commented on TUSCANY-1823:
---
Raymond, you asked:
I think it requires the SCA spec clarification here. In the following case:
@Property
public String location = RTP;
Do we take the RTP as the default value? Should
ComponentContext.getProperty(String.class, location) return RTP? If so,
then it will be inconsistent with the setter method because it cannot access
the default value.
private String location =RTP;
@Property
public void setLocation(String location) {
this.location = location;
}
It's not clear in the spec (assembly and java).
In your case above, RTP IS the default value for the property. So, if no
value is provided for the property by its SCA component configuration, the
default value applies.
It is a different issue as to whether ComponentContext.getProperty(...) can
correctly get at the property value. Clearly, if there is a getter method, all
is well. If there is no getter method, then for a private field you would have
to violate encapsulation in order to go fetch the value. I don't have an
answer to that one.
I suggest that it is the Java CI spec that has the problem, since the default
value is perfectly well defined, but that getting the value of the property is
not at all clear in the case where the property field is private and there is
no getter method.
Yours, Mike.
The getProperty() method on ComponentContext does not work
--
Key: TUSCANY-1823
URL: https://issues.apache.org/jira/browse/TUSCANY-1823
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0
Environment: SVN revision #579110
Linux
Reporter: Mark Combellack
Assignee: Raymond Feng
Priority: Minor
Fix For: Java-SCA-Next
Attachments: ComponentContextGetProperty.patch,
ComponentContextGetProperty_EnableTest.patch,
ComponentContextGetPropertyComparisonFix.patch,
ComponentContextGetPropertyTest_FAILS.patch
As far as I can tell, it should be possible to get a property via:
* Injection using @Property
* ComponentContext.getProperty() method (Java Annotations spec - line 807
808)
The value returned by both of these methods should be equal.
The ComponentContext.getProperty() method currently does not work as detailed
above.
The code for the ComponentContext.getProperty() method can be found in the
ComponentContextImpl class of the core project.
There appears to be more than one problem:
Incorrectly comparing property name:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The code contains the following:
public B B getProperty(ClassB type, String propertyName) {
for (ComponentProperty p : component.getProperties()) {
if (propertyName.equals(propertyName)) {
Notice that the if statement is comparing property name with itself. They
will always be equal! This means that the first property is always being used
rather than finding the correct one based on it's name.
The code should be updated so that the if statement reads (i.e. use the
p.getName() method)
if (propertyName.equals(p.getName())) {
I have attached a patch to fix this comparison problem.
Properties appear not to be working:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
To test ComponentContext.getProperty(), I updated the properties iTest by
adding a test that gets the location from the ComponentContext and compares
it with the injected version.
The problem is that the property value returned from the ComponentContext is
null.
I have attached a patch for this test but as it does not pass so I would not
apply it yet until this bug is fixed.
Unfortunately, I do not know the cause of this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1486) Support Stateful Spring Beans and Conversational interactions
Support Stateful Spring Beans and Conversational interactions - Key: TUSCANY-1486 URL: https://issues.apache.org/jira/browse/TUSCANY-1486 Project: Tuscany Issue Type: Improvement Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-Next Provide stateful support for Spring Beans, including Scope support and Conversational interaction support, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful
[ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514610 ] Mike Edwards commented on TUSCANY-1389: --- I'm OK with Jean-Sebastien's proposal. It would be useful to update the website/Wiki documentation to describe this approach. published DTD for composite XML Schema needed/useful Key: TUSCANY-1389 URL: https://issues.apache.org/jira/browse/TUSCANY-1389 Project: Tuscany Issue Type: Improvement Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA Samples Affects Versions: Java-SCA-0.90 Environment: java Reporter: James Tomkinson Priority: Minor Attachments: addattributes_knownfromDTD.jpg, addchild_knownfromDTD.jpg, openwithxmleditor.jpg Samples should supply a DOCTYPE in *.composite xml files, that points to a stored DTD, so that XML editing tools can be used to create/edit/validate XML schema. This will enhance productivity/accuracy. Example for Hibernate: !DOCTYPE hibernate-configuration PUBLIC -//Hibernate/Hibernate Configuration DTD 3.0//EN http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types
[ https://issues.apache.org/jira/browse/TUSCANY-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards reassigned TUSCANY-1443: - Assignee: Mike Edwards sample composite files are invalid instance documents against SCA schema types -- Key: TUSCANY-1443 URL: https://issues.apache.org/jira/browse/TUSCANY-1443 Project: Tuscany Issue Type: Bug Components: C++ SCA Environment: all Reporter: Michael Yoder Assignee: Mike Edwards The SCA samples composite files are invalid against the SCA schemas. In a component element, the property element has content. e.g. (from CppBigBank) component name=AccountServiceComponent . property name=currencyEURO/property /component When the XML Schema type does not allow mixed or simple content: complexType name=PropertyType complexContent extension base=anyType attribute name=name type=NCName use=required / attribute name=type type=QName use=required / attribute name=many type=boolean default=false use=optional / attribute name=override type=sca:OverrideOptions default=may use=optional / anyAttribute namespace=##any processContents=lax / /extension /complexContent /complexType The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: component name=AccountServiceComponent . property name=currency value=EURO/ /component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types
[ https://issues.apache.org/jira/browse/TUSCANY-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513257 ] Mike Edwards commented on TUSCANY-1443: --- Umm, which SCA XSDs are you referencing here? The correct ones are in the SCA Assembly spec document here: http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf and they are also available directly on the web at their indicated locations, eg: http://www.osoa.org/xmlns/sca/1.0 In those, the definition of SCA Property type goes like this: complexType name=SCAPropertyBase mixed=true !-- mixed=true to handle simple type -- sequence any namespace=##any processContents=lax minOccurs=0 maxOccurs=1 / !-- NOT an extension point; This xsd:any exists to accept the element-based or complex type property i.e. no element-based extension point under sca:property -- /sequence /complexType !-- complex type for sca:property declaration -- complexType name=Property mixed=true complexContent extension base=sca:SCAPropertyBase !-- extension defines the place to hold default value -- attribute name=name type=NCName use=required/ attribute name=type type=QName use=optional/ attribute name=element type=QName use=optional/ attribute name=many type=boolean default=false use=optional/ attribute name=mustSupply type=boolean default=false use=optional/ anyAttribute namespace=##any processContents=lax/ !-- an extension point ; attribute-based only -- /extension /complexContent /complexType ...which I believe covers the usage described for the property in the composite document which you reference. Now, there is a problem with the XSDs within the cpp Project, but it isn't the one you've raised. Actually, the ones in the cpp project look to be out of date and need to be replaced wholesale with the ones from www.osoa.org. Yours, Mike. sample composite files are invalid instance documents against SCA schema types -- Key: TUSCANY-1443 URL: https://issues.apache.org/jira/browse/TUSCANY-1443 Project: Tuscany Issue Type: Bug Environment: all Reporter: Michael Yoder The SCA samples composite files are invalid against the SCA schemas. In a component element, the property element has content. e.g. (from CppBigBank) component name=AccountServiceComponent . property name=currencyEURO/property /component When the XML Schema type does not allow mixed or simple content: complexType name=PropertyType complexContent extension base=anyType attribute name=name type=NCName use=required / attribute name=type type=QName use=required / attribute name=many type=boolean default=false use=optional / attribute name=override type=sca:OverrideOptions default=may use=optional / anyAttribute namespace=##any processContents=lax / /extension /complexContent /complexType The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: component name=AccountServiceComponent . property name=currency value=EURO/ /component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful
[ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509460 ] Mike Edwards commented on TUSCANY-1389: --- I think that the right approach here is to use the XSDs for SCA. Eclipse XML tooling is certainly capable of using XSDs as well as DTDs to describe to structure of XML documents. The SCA XSDs are freely available at: http://www.osoa.org/xmlns/sca/1.0 I propose one additional step which will help in handling the SCA samples - that each composite file in the samples has an xsi:location attribute added to it as follows: xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0 http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd This should allow any context aware XML editor to find the SCA XSDs and use them for validation and editing assist. Anyone who wants to workffline will need to install local copies of the XSDs on their machine and adjust the xsi:location target value. published DTD for composite XML Schema needed/useful Key: TUSCANY-1389 URL: https://issues.apache.org/jira/browse/TUSCANY-1389 Project: Tuscany Issue Type: Improvement Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA Samples Affects Versions: Java-SCA-0.90 Environment: java Reporter: James Tomkinson Priority: Minor Attachments: addattributes_knownfromDTD.jpg, addchild_knownfromDTD.jpg, openwithxmleditor.jpg Samples should supply a DOCTYPE in *.composite xml files, that points to a stored DTD, so that XML editing tools can be used to create/edit/validate XML schema. This will enhance productivity/accuracy. Example for Hibernate: !DOCTYPE hibernate-configuration PUBLIC -//Hibernate/Hibernate Configuration DTD 3.0//EN http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1377) Conversational PM- HTTP Session persistence
[ https://issues.apache.org/jira/browse/TUSCANY-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508486 ] Mike Edwards commented on TUSCANY-1377: --- There is a mixture of 2 things here, as described in Sebastien's last comment: 1) Handling of Scope for components (he mentions implementation.java, which is fine) 2) Dealing with conversational sessions on the HTTP binding These two are NOT directly related. You can do one without the other. I'd suggest sorting out the HTTP binding first - only once there is a conversation going on between 2 components over the wire does it become useful to implement the Scope attribute on a component. Conversational PM- HTTP Session persistence --- Key: TUSCANY-1377 URL: https://issues.apache.org/jira/browse/TUSCANY-1377 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next Implement conversational PM- HTTP Session persistence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful
[ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508537 ] Mike Edwards commented on TUSCANY-1389: --- James, Does it have to be a DTD - or will an XSD be sufficient to meet your requirements? I have a particular dislike of DTDs born of having to deal with them in relation to SGML documents back in the old days. There are plenty of tools that can work with XSDs and use them for validation. published DTD for composite XML Schema needed/useful Key: TUSCANY-1389 URL: https://issues.apache.org/jira/browse/TUSCANY-1389 Project: Tuscany Issue Type: Improvement Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA Samples Affects Versions: Java-SCA-0.90 Environment: java Reporter: James Tomkinson Priority: Minor Samples should supply a DOCTYPE in *.composite xml files, that points to a stored DTD, so that XML editing tools can be used to create/edit/validate XML schema. This will enhance productivity/accuracy. Example for Hibernate: !DOCTYPE hibernate-configuration PUBLIC -//Hibernate/Hibernate Configuration DTD 3.0//EN http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1152) Support Spring beans as eager-init singletons with references to SCA composite references
[ https://issues.apache.org/jira/browse/TUSCANY-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505192 ] Mike Edwards commented on TUSCANY-1152: --- The only information about this issue is the title, which is a bit thin! Having implemented the Spring Implementation support for the new core runtime, I'm having trouble understanding why this is required: 1) Why Spring beans need to be eager-init. In fact, in the current implementation, lazy initialization is almost forced due to timing issues relating to the instantiation of Spring Beans vs the existence of the wire configuration for references that they make. 2) Why singletons? This I really don't understand. Seems counter-intuitive to me. 3) References to SCA Composite references. Already supported as standard in the current implementation. So, unless someone can come up with a detailed explanation of the requirements behind this Issue, I propose to close it as won't fix since none of the items seem to make sense to me. Have I missed something here? Support Spring beans as eager-init singletons with references to SCA composite references - Key: TUSCANY-1152 URL: https://issues.apache.org/jira/browse/TUSCANY-1152 Project: Tuscany Issue Type: Bug Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Reporter: Jim Marino Assignee: Mike Edwards Fix For: Java-SCA-Next -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
