[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] 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] 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-tabpanel&focusedCommentId=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] 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 :
>
> 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/";>
>
> targetNamespace="http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";
> xmlns="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
>
>
>
>
>
>
>
>
>
>
>
> http://9.76.45.104:8085/HelloPartnerLink"/>
>
>
> <{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>
>
--
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-tabpanel&focusedCommentId=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 :
>
> 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/";>
>
> targetNamespace="http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";
> xmlns="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
>
>
>
>
>
>
>
>
>
>
>
> http://9.76.45.104:8085/HelloPartnerLink"/>
>
>
> <{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>
>
--
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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] 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] 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-tabpanel&focusedCommentId=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 (either explicitly > or implicitly by introspection) is promoted to a composite reference defined > with , and there is a namespace conflict between the > component reference's and the composite reference's > . 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 > CompositeWireBuilderImpl.connectComposi
[jira] Commented: (TUSCANY-2052) A Composite without a targetNamespace is not properly started in a contribution
[ https://issues.apache.org/jira/browse/TUSCANY-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571073#action_12571073 ] Mike Edwards commented on TUSCANY-2052: --- The SCA Assembly spec says that a composite MUST have a targetNameSpace declared. The spec does not say that the runtime should raise an error in the case of the targetNameSpace being absent, but that would be my expectation. Does anyone think that the spec is wrong in this area? The problem is a general one for XML artifacts - if they don't belong to a namespace, how can you senssibly search for them. It's like a Java class that is not part of a package So my suggestion is to fix this JIRA by changing the composite loading code to throw an exception if the composite has no targetNameSpace declared. > A Composite without a targetNamespace is not properly started in a > contribution > --- > > Key: TUSCANY-2052 > URL: https://issues.apache.org/jira/browse/TUSCANY-2052 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-1.0 > Environment: All >Reporter: Hasan Muhammad > Fix For: Java-SCA-Next > > > If the composite does not have a targetNamespace, then the composite QName in > the sca-contribution.xml file would just be the localname. In this case, when > we add the contribution and start the deployables, it seems they are not > properly being started, since none of the service can be found through > lookup. -- 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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] 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-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 C&I 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 getProperty(Class 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: >"-//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) > > . > EURO > > When the XML Schema type does not allow mixed or simple content: > > > > > > use="optional" /> > default="may" use="optional" /> > > > > > The type is open to additional attributes, so the instance documents can be > made valid with simple changes like this: > > . > > -- 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: ...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) > > . > EURO > > When the XML Schema type does not allow mixed or simple content: > > > > > > use="optional" /> > default="may" use="optional" /> > > > > > The type is open to additional attributes, so the instance documents can be > made valid with simple changes like this: > > . > > -- 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: >"-//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-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: >"-//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-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]
