[jira] [Commented] (TUSCANY-3943) JAXWS Elements are not processed by the WSDLModelResolver - enableWrapperStyle elements are ignored
[ https://issues.apache.org/jira/browse/TUSCANY-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13101324#comment-13101324 ] Scott Kurz commented on TUSCANY-3943: - Gave this some more thought and realized two things: 1) The scope/granularity of jaxws:enableWrapperStyle is a bit more complicated, according to the JAX-WS spec. Sec. 8.6: ... when determining the value of the jaxws:enableWrapperStyle customization parameter for a portType operation, binding declarations MUST be processed in the following order, according to the element they pertain to: (1) the portType operation in question, (2) its parent portType, (3) the definitions element. I guess to implement it right we'd need to do that, even though I'd guess it would be awhile before we'd ever come across a need for this. 2) I can see why you raised the subject of wsdlgen. There are some round-tripping issues here. If I start with a WSDL op that otherwise qualifies for wrapper-style mapping but has jaxws:enableWrapperStyle and generate Java I'll end up with a bare mapping and the Java will have: @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) However, I don't see that the JAX-WS spec says anything in the other direction, about mapping this (generated) Java to WSDL. So I might end up with an equivalent WSDL, but without the jaxws:enableWrapperStyle customization. The next person to generate Java might just then (assuming the toolset doesn't remember somehow) get a wrapped-style Java interface. Now... I still think it would help greatly to have a test to talk to before going further... but I thought it might be helpful to write down that thought after having it. It might be that, after considering the second point, we need to take a completely different approach than simply reading in the jaxws:enableWrapperStyle customization like in Eric's patch, a modified version of which I used to pass the interface-wsdl test I added. Scott JAXWS Elements are not processed by the WSDLModelResolver - enableWrapperStyle elements are ignored --- Key: TUSCANY-3943 URL: https://issues.apache.org/jira/browse/TUSCANY-3943 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Environment: All systems Reporter: Eric Larsen Fix For: Java-SCA-2.x Attachments: binding-ws-wsdlgen.patch, interface-wsdl.patch Tuscany doesn't process any jaxws tags that are included in WSDL files. This causes any enableWrapperStyle elements to be ignored, which causes a logic failure in the wrapping logic when Tuscany expects wrapped objects, and Java classes generated by external tools such as wsimport are not wrapped. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-3942) Should reference target=XXX with empty child binding.sca element be allowed?
[ https://issues.apache.org/jira/browse/TUSCANY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz reassigned TUSCANY-3942: --- Assignee: Scott Kurz Should reference target=XXX with empty child binding.sca element be allowed? - Key: TUSCANY-3942 URL: https://issues.apache.org/jira/browse/TUSCANY-3942 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Should this be allowed? (I should have phrased this as uri-less binding.sca rather than empty) reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): if ((binding instanceof SCABinding) (binding.getURI() == null)) continue; I can understand the thought process here, e.g. the context around ASM50026 involves avoiding ambiguity in resolving references, and since an empty, uri-less binding.sca doesn't resolve the reference at all.. it doesn't conflict with the target. However, the language in ASM50026 is plain and simple and seems to disallow this, and doesn't make a special case for binding.sca without a @uri. One problem with tolerating this syntax, (as we do today), is that, in general, when using @target you don't get to select which binding to use, from the reference side.However I could see someone thinking that adding the binding.sca child elem to the reference with @target value would imply that the binding.sca should be used to do the invocation. (ASM50012 implies this). So it's unclear if this should have this behavior making the app implementation-dependent. From a purely Tuscany-only viewpoint I can even see the value of tolerating this... however it's such a simple case syntax-wise, and the spec is clearly trying to specify the correct vs. incorrect behavior... so I do think we should try to follow the letter of the spec in this instance. I tried to find some earlier discussion here, this is all I found which didn't seem to help much (except to make me wonder if there is some other use case, maybe involving callbacks, complicating this.. but I can't think of it): https://issues.apache.org/jira/browse/TUSCANY-3013 Thoughts? Thanks, Scott -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3942) Should reference target=XXX with empty child binding.sca element be allowed?
[ https://issues.apache.org/jira/browse/TUSCANY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz closed TUSCANY-3942. --- Should reference target=XXX with empty child binding.sca element be allowed? - Key: TUSCANY-3942 URL: https://issues.apache.org/jira/browse/TUSCANY-3942 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Should this be allowed? (I should have phrased this as uri-less binding.sca rather than empty) reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): if ((binding instanceof SCABinding) (binding.getURI() == null)) continue; I can understand the thought process here, e.g. the context around ASM50026 involves avoiding ambiguity in resolving references, and since an empty, uri-less binding.sca doesn't resolve the reference at all.. it doesn't conflict with the target. However, the language in ASM50026 is plain and simple and seems to disallow this, and doesn't make a special case for binding.sca without a @uri. One problem with tolerating this syntax, (as we do today), is that, in general, when using @target you don't get to select which binding to use, from the reference side.However I could see someone thinking that adding the binding.sca child elem to the reference with @target value would imply that the binding.sca should be used to do the invocation. (ASM50012 implies this). So it's unclear if this should have this behavior making the app implementation-dependent. From a purely Tuscany-only viewpoint I can even see the value of tolerating this... however it's such a simple case syntax-wise, and the spec is clearly trying to specify the correct vs. incorrect behavior... so I do think we should try to follow the letter of the spec in this instance. I tried to find some earlier discussion here, this is all I found which didn't seem to help much (except to make me wonder if there is some other use case, maybe involving callbacks, complicating this.. but I can't think of it): https://issues.apache.org/jira/browse/TUSCANY-3013 Thoughts? Thanks, Scott -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TUSCANY-3942) Should reference target=XXX with empty child binding.sca element be allowed?
[ https://issues.apache.org/jira/browse/TUSCANY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz resolved TUSCANY-3942. - Resolution: Fixed Thanks for chiming in Mike. Should reference target=XXX with empty child binding.sca element be allowed? - Key: TUSCANY-3942 URL: https://issues.apache.org/jira/browse/TUSCANY-3942 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Should this be allowed? (I should have phrased this as uri-less binding.sca rather than empty) reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): if ((binding instanceof SCABinding) (binding.getURI() == null)) continue; I can understand the thought process here, e.g. the context around ASM50026 involves avoiding ambiguity in resolving references, and since an empty, uri-less binding.sca doesn't resolve the reference at all.. it doesn't conflict with the target. However, the language in ASM50026 is plain and simple and seems to disallow this, and doesn't make a special case for binding.sca without a @uri. One problem with tolerating this syntax, (as we do today), is that, in general, when using @target you don't get to select which binding to use, from the reference side.However I could see someone thinking that adding the binding.sca child elem to the reference with @target value would imply that the binding.sca should be used to do the invocation. (ASM50012 implies this). So it's unclear if this should have this behavior making the app implementation-dependent. From a purely Tuscany-only viewpoint I can even see the value of tolerating this... however it's such a simple case syntax-wise, and the spec is clearly trying to specify the correct vs. incorrect behavior... so I do think we should try to follow the letter of the spec in this instance. I tried to find some earlier discussion here, this is all I found which didn't seem to help much (except to make me wonder if there is some other use case, maybe involving callbacks, complicating this.. but I can't think of it): https://issues.apache.org/jira/browse/TUSCANY-3013 Thoughts? Thanks, Scott -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3943) JAXWS Elements are not processed by the WSDLModelResolver - enableWrapperStyle elements are ignored
[ https://issues.apache.org/jira/browse/TUSCANY-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100685#comment-13100685 ] Scott Kurz commented on TUSCANY-3943: - Eric, Thanks for raising the issue and the patch.In r1166896, I added a test to interface-wsdl showing this issue, @Ignore(d) for now. A couple comments on your patch. It's a good start, I did have to tweak it a bit since it assumes I'm going to have a jaxws:package customization in my WSDL along with the jaxws:enableWrapperStyle customization (which my test in particular did not have). But I basically made my test pass by tweaking the one line to: Node wrapperElem = element.getElementsByTagNameNS(jaxwsNS,wrapperTagName).item(0); I'm not sure at this point what to make of your comment about needing to tweak wsdlgen. Can you outline at least (if not post) the test you used to reach this conclusion? Also, while we might want to read and honor the jaxws:package customization (as well as others) at some point, my preference would be to leave this out altogether unless we are really going to make use of this in a real scenario. If we don't have a test which makes uses of this at least, let's cut that out so any maintainers of this code have less to worry about. If you can resubmit a trimmed-down patch which passes the new test, I can commit it. I'll let you decide whether you want to use this or another JIRA to address the wsdlgen issue as well. Thanks, Scott JAXWS Elements are not processed by the WSDLModelResolver - enableWrapperStyle elements are ignored --- Key: TUSCANY-3943 URL: https://issues.apache.org/jira/browse/TUSCANY-3943 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Environment: All systems Reporter: Eric Larsen Fix For: Java-SCA-2.x Attachments: binding-ws-wsdlgen.patch, interface-wsdl.patch Tuscany doesn't process any jaxws tags that are included in WSDL files. This causes any enableWrapperStyle elements to be ignored, which causes a logic failure in the wrapping logic when Tuscany expects wrapped objects, and Java classes generated by external tools such as wsimport are not wrapped. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3941) Reference with binding.sca uri=targetService may be resolved with another binding when target service is exposed over multiple bindings
Reference with binding.sca uri=targetService may be resolved with another binding when target service is exposed over multiple bindings -- Key: TUSCANY-3941 URL: https://issues.apache.org/jira/browse/TUSCANY-3941 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Priority: Minor If I have a service exposed over multiple bindings (including binding.sca) and I target it from component reference: reference name=xxx binding.sca uri=targetService/ /reference then the runtime should use binding.sca to perform the invocation. However, I'm noticing this isn't always the case.It seems that the runtime is treating this case similar to: reference name=xxx target=targetService/ in which case it is up to the runtime to pick the binding (if there are no other intents, etc.). In a couple tests I've run the runtime seems to pick the first binding in order listed in the target service SCDL, which is wrong when the resolution is done with binding child elements rather than the @target attr. - One itest I happen to have just worked with which can be used to recreate this is the set of tests in testing/itest/data-copy. If, starting from that directory, I change client/src/main/resources/helloworld-client.composite to: ... component name=ClientSCA implementation.java class=itest.client.impl.ClientImpl/ reference name=service binding.sca uri=Service/ ... then I will still get binding.sca on this invocation, since in service/src/main/resources/helloworld-service.composite I have: component name=Service implementation.java class=itest.service.impl.ServiceImpl/ service name=ServiceIntf binding.sca name=sca/ binding.ws name=ws uri=http://localhost:8085/Service/ServiceIntf/ However, if I switch the order of binding.sca, binding.ws in the service SCDL, I will end up getting binding.ws on the invocation. (Note you should need the debugger or some other method... I don't recall the test is designed to fail if the wrong binding is used). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3942) Should reference target=XXX with empty child binding.sca element be allowed?
Should reference target=XXX with empty child binding.sca element be allowed? - Key: TUSCANY-3942 URL: https://issues.apache.org/jira/browse/TUSCANY-3942 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Priority: Minor Should this be allowed: reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3942) Should reference target=XXX with empty child binding.sca element be allowed?
[ https://issues.apache.org/jira/browse/TUSCANY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3942: Description: Should this be allowed? (I should have phrased this as uri-less binding.sca rather than empty) reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): if ((binding instanceof SCABinding) (binding.getURI() == null)) continue; I can understand the thought process here, e.g. the context around ASM50026 involves avoiding ambiguity in resolving references, and since an empty, uri-less binding.sca doesn't resolve the reference at all.. it doesn't conflict with the target. However, the language in ASM50026 is plain and simple and seems to disallow this, and doesn't make a special case for binding.sca without a @uri. One problem with tolerating this syntax, (as we do today), is that, in general, when using @target you don't get to select which binding to use, from the reference side.However I could see someone thinking that adding the binding.sca child elem to the reference with @target value would imply that the binding.sca should be used to do the invocation. (ASM50012 implies this). So it's unclear if this should have this behavior making the app implementation-dependent. From a purely Tuscany-only viewpoint I can even see the value of tolerating this... however it's such a simple case syntax-wise, and the spec is clearly trying to specify the correct vs. incorrect behavior... so I do think we should try to follow the letter of the spec in this instance. I tried to find some earlier discussion here, this is all I found which didn't seem to help much (except to make me wonder if there is some other use case, maybe involving callbacks, complicating this.. but I can't think of it): https://issues.apache.org/jira/browse/TUSCANY-3013 Thoughts? Thanks, Scott was: Should this be allowed: reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): Should reference target=XXX with empty child binding.sca element be allowed? - Key: TUSCANY-3942 URL: https://issues.apache.org/jira/browse/TUSCANY-3942 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Priority: Minor Should this be allowed? (I should have phrased this as uri-less binding.sca rather than empty) reference target=targetService binding.sca/ /reference I see this is specifically allowed in EndpointReferenceBuilderImpl.bindingsIdentifyTargets(), so some thought went into this (looks like Raymond wrote this): if ((binding instanceof SCABinding) (binding.getURI() == null)) continue; I can understand the thought process here, e.g. the context around ASM50026 involves avoiding ambiguity in resolving references, and since an empty, uri-less binding.sca doesn't resolve the reference at all.. it doesn't conflict with the target. However, the language in ASM50026 is plain and simple and seems to disallow this, and doesn't make a special case for binding.sca without a @uri. One problem with tolerating this syntax, (as we do today), is that, in general, when using @target you don't get to select which binding to use, from the reference side.However I could see someone thinking that adding the binding.sca child elem to the reference with @target value would imply that the binding.sca should be used to do the invocation. (ASM50012 implies this). So it's unclear if this should have this behavior making the app implementation-dependent. From a purely Tuscany-only viewpoint I can even see the value of tolerating this... however it's such a simple case syntax-wise, and the spec is clearly trying to specify the correct vs. incorrect behavior... so I do think we should try to follow the letter of the spec in this instance. I tried to find some earlier discussion here, this is all I found which didn't seem to help much (except to make me wonder if there is some other use case, maybe involving callbacks, complicating this.. but I can't think of it): https://issues.apache.org/jira/browse/TUSCANY-3013 Thoughts? Thanks, Scott -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087750#comment-13087750 ] Scott Kurz commented on TUSCANY-3924: - Why wouldn't the fields in the base class be treated as Property(s)? Without any specific direction from the spec, I'd have just guessed the base fields would be treated as such? Can you give some motivation for why it should be different? Inherited fields in service impl classes are treated as Properties -- Key: TUSCANY-3924 URL: https://issues.apache.org/jira/browse/TUSCANY-3924 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Vijai Kalathur Fix For: Java-SCA-2.x In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties. Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3918) Split WSDL files in the same namespace casues problems for ws binding
[ https://issues.apache.org/jira/browse/TUSCANY-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083125#comment-13083125 ] Scott Kurz commented on TUSCANY-3918: - Just curious when this is failing... could you paste the stack trace? Thx,Scott Split WSDL files in the same namespace casues problems for ws binding - Key: TUSCANY-3918 URL: https://issues.apache.org/jira/browse/TUSCANY-3918 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I have the following scenario: wsdl:definitions targetNamespace=http://serialize; xmlns:tns=http://serialize; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=serialize-top wsdl:import namespace=http://serialize; location=wsdl-serialize-nested.wsdl / wsdl:binding name=AccountSoapBinding type=nested:Account ... wsdl:definitions targetNamespace=http://serialize; xmlns:tns=http://serialize; xmlns:account=http://accounts; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=questionmark-import-nested wsdl:types ... composite xmlns=http://docs.oasis-open.org/ns/opencsa/sca/200912; xmlns:sca=http://docs.oasis-open.org/ns/opencsa/sca/200912; targetNamespace=http://www.tuscany.apache.org/tests/binding/ws/axis2; name=WSDLSerialize component name=AccountService implementation.java class=org.apache.tuscany.sca.binding.ws.axis2.AccountService/ service name=Account binding.ws uri=http://localhost:8085/services/AccountService; wsdlElement=http://serialize#wsdl.binding(AccountSoapBinding)/ /service /component /composite This causes the ws binding to fail with an NPE in Axis when it's trying to find the AccountSoapBinding binding. I'm guessing that having both WSDL documents in the same namespace is causing confusion somewhere. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding
Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding Key: TUSCANY-3910 URL: https://issues.apache.org/jira/browse/TUSCANY-3910 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0 Reporter: Scott Kurz Assignee: Scott Kurz Say I have a wrapped-style WSDL interface which I want to map to Java intf: Node greetDOM(Node name); Our databinding introspection will correctly mark the input/output with DOMDataBinding. The JAXWSJavaInterfaceProcessor will generate the wrappers since they are not already present from the Java perspective. Then there is some more function in WrapperJavaInterfaceProcessor to promote the parm/returnVal databindings to the wrapper-level databindings. However, while in 1.x this always ran after the wrappers were generated, in 2.x the order isn't so determined because of the way we factored out the addition of the interface processors. So the user has to ensure the JAX-WS annotations are present and that they specify the databinding (via the className), which is a pain to add manually if he doesn't have a tool to do it, e.g.: @RequestWrapper(localName = greetDOM, targetNamespace = http://intf.privatecopy.itest/;, className = org.w3c.dom.Node) @ResponseWrapper(localName = greetDOMResponse, targetNamespace = http://intf.privatecopy.itest/;, className = org.w3c.dom.Node) Node greetDOM(Node name); We seem to need an ordering so that the WrapperJavaInterfaceProcessor runs after JAXWSJavaInterfaceProcessor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3911) ServiceReference type not marshalled to XML correctly
ServiceReference type not marshalled to XML correctly
-
Key: TUSCANY-3911
URL: https://issues.apache.org/jira/browse/TUSCANY-3911
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0
Reporter: Scott Kurz
Priority: Minor
When using a binding with an XML wireformat, the ServiceReference type is going
to be treated as a JAXB by the Tuscany databinding framework, and is not going
to get serialized correctly.
E.g. see this intf from the itest/service-reference module:
@Remotable
public interface DComponent {
String foo(ServiceReferenceAComponent aReference);
It works fine when we use a binding.sca config that does Java serialization,
but if we try to use an XML wireformat we get the JAXB error:
org.oasisopen.sca.ServiceReference is an interface, and JAXB can't handle
interfaces.
I'm guessing the solution is to use JAXBs customizations/annotations to tell
JAXB how to handle our ServiceReference impl.But I'd have to look into that.
I guess there's also the idea of defining a new databinding but that seems odd.
Will attach a recreate patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3911) ServiceReference type not marshalled to XML correctly
[
https://issues.apache.org/jira/browse/TUSCANY-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3911:
Attachment: 3911.recreate.patch
Assuming you have my recent binding.sca changes (r1153291), simply apply this
small tweak to binding-sca-runtime
ServiceReference type not marshalled to XML correctly
-
Key: TUSCANY-3911
URL: https://issues.apache.org/jira/browse/TUSCANY-3911
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0
Reporter: Scott Kurz
Priority: Minor
Attachments: 3911.recreate.patch
When using a binding with an XML wireformat, the ServiceReference type is
going to be treated as a JAXB by the Tuscany databinding framework, and is
not going to get serialized correctly.
E.g. see this intf from the itest/service-reference module:
@Remotable
public interface DComponent {
String foo(ServiceReferenceAComponent aReference);
It works fine when we use a binding.sca config that does Java serialization,
but if we try to use an XML wireformat we get the JAXB error:
org.oasisopen.sca.ServiceReference is an interface, and JAXB can't handle
interfaces.
I'm guessing the solution is to use JAXBs customizations/annotations to tell
JAXB how to handle our ServiceReference impl.But I'd have to look into
that.
I guess there's also the idea of defining a new databinding but that seems
odd.
Will attach a recreate patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz resolved TUSCANY-3894. - Resolution: Fixed Resolved by having local binding.sca reference provider do the following: - look at source/target operations and see if for each inputs/output, the source and target DataType are using the same databinding. - If so, set up the SameDBCopyTransformer which uses Mediator.copyXXX to do the data transform (for PBV cases) - Else, use the WSDLMediateTransformer, calculating a wsdlOperation and doing a Mediator.mediateXXX from sourceOp-wsdlOp, and then one from wsdlOp- targetOp Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Fix For: Java-SCA-2.0 Attachments: 3894.patch, 3894.tests.patch As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3908) IllegalArgumentException with XMLStreamReader2JSON transformer
IllegalArgumentException with XMLStreamReader2JSON transformer
--
Key: TUSCANY-3908
URL: https://issues.apache.org/jira/browse/TUSCANY-3908
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Scott Kurz
I get this error on what seems like a relatively simple path through the
XMLStreamReader2JSON:
java.lang.IllegalArgumentException: org.codehaus.jettison.json.JSONException: A
JSONObject text must begin with '{' at character 0 of
This happens on line 67 of XMLStreamReader2JSON which looks like:
return JSONHelper.toJSON(writer.toString(), type);
I can see that writer.toString() is returning the empty string. Not sure why.
Here is the payload (including wrapper) coming in via binding.ws. Since it's
Axis2, we load it as AXIOM and first do an OMElement2XMLStreamReader:
ns2:greetJSON
xmlns:ns2=http://intf.privatecopy.itest/;arg0firstNameJason/firstNamelastNameNosaj/lastName/arg0/ns2:greetJSON
Since JSONDataBinding doesn't provide a wrapper handler, we unwrap first (on
the source side), and so the XML being passed to XMLStreamReader2JSON
corresponds to:
arg0firstNameJason/firstNamelastNameNosaj/lastName/arg0
Could the problem be that arg0 is not a schema-declared global element?
I'm not too familiar with JSON-XML. so figured I'd just write this up. not
sure when I'd get around to investigating more and maybe someone knows the
answer.
Thanks, Scott
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3908) IllegalArgumentException with XMLStreamReader2JSON transformer
[
https://issues.apache.org/jira/browse/TUSCANY-3908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3908:
Attachment: recreate.patch
To recreate simply apply this patch enabling one of the itest/data-copy tests
using JSON
IllegalArgumentException with XMLStreamReader2JSON transformer
--
Key: TUSCANY-3908
URL: https://issues.apache.org/jira/browse/TUSCANY-3908
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Scott Kurz
Attachments: recreate.patch
I get this error on what seems like a relatively simple path through the
XMLStreamReader2JSON:
java.lang.IllegalArgumentException: org.codehaus.jettison.json.JSONException:
A JSONObject text must begin with '{' at character 0 of
This happens on line 67 of XMLStreamReader2JSON which looks like:
return JSONHelper.toJSON(writer.toString(), type);
I can see that writer.toString() is returning the empty string. Not sure
why.
Here is the payload (including wrapper) coming in via binding.ws. Since
it's Axis2, we load it as AXIOM and first do an OMElement2XMLStreamReader:
ns2:greetJSON
xmlns:ns2=http://intf.privatecopy.itest/;arg0firstNameJason/firstNamelastNameNosaj/lastName/arg0/ns2:greetJSON
Since JSONDataBinding doesn't provide a wrapper handler, we unwrap first (on
the source side), and so the XML being passed to XMLStreamReader2JSON
corresponds to:
arg0firstNameJason/firstNamelastNameNosaj/lastName/arg0
Could the problem be that arg0 is not a schema-declared global element?
I'm not too familiar with JSON-XML. so figured I'd just write this up. not
sure when I'd get around to investigating more and maybe someone knows the
answer.
Thanks, Scott
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz reopened TUSCANY-3894: - I never actually used the structure I built as part of this work to fix the original problem, as shown in some of the data-copy tests @Ignore(d) currently. Would like to complete by fixing this. Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Fix For: Java-SCA-2.0 Attachments: 3894.patch, 3894.tests.patch As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz resolved TUSCANY-3894. - Resolution: Fixed Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Fix For: Java-SCA-2.0 Attachments: 3894.patch, 3894.tests.patch As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13072148#comment-13072148 ] Scott Kurz commented on TUSCANY-3894: - I checked in some more changes here, so let me explain. From the runtime side, in r1151632, I refactored the local part of sca-binding-runtime so that the exact details of the data transform are extensible. I'm creating a new interface, BindingSCATransformer which I'll implement to handle the transform details. My thought is that the base portion of the binding will do things like calculate whether to do the pass-by-reference optimization and establish other aspects of the invoker/interceptor chain. This will be handled in DefaultLocalSCAReferenceBindingProvider, which will also compute the WSDL contract, in case the transform needs it, as well as return the ComponentTypeRefIC to disable the DataTransformationInterceptor.So we're always initiating data transform from the binding, not via DataTransformationInterceptor on the wire, just to reiterate. In my scheme, the BindingProviderFactory impl will create a ref binding provider which will potentially extend the base DefaultLocalSCAReferenceBindingProvider by providing its own BindingSCATransformer (and possibly a different databinding then the DOM default one I'm using). There are now two provider factories, each resulting in a different BindingSCATransformer being used. The first, the default, maintains the current behavior we're used to. Notably, it: - uses Mediator.copyXXX rather than Mediator.mediateXXX, which notably does not use the JAX-WS wrappers - has RMI-like referential integrity for parameters (see earlier comments) - for POJOs, preferes Java serialization (if java.io.Serializable), then JAXB/XML serialization The second is an XML-centric databinding. Some notes: - It's built via pointing to XMLWFLocalSCABindingProviderFactory in the extension point, which builds the XMLWFBindingSCATransformer. - relies on building a WSDL InterfaceContract to be used along with Mediator.mediateXXX - uses a DOM databinding (since there's been a move to avoid AXIOM if possible), but this could easily be switched in another impl with little code - The XMLWFLocalSCAReferenceBindingProvider actually extends the DefaultLocalSCAReferenceBindingProvider, the provider in the first, default impl. I would like to add a weighting to the various binding provider factories, and ideally polish things up a bit. However, there are a couple more JIRAs I need to open after noticing some side effects, and it seemed easiest to have something concrete in the trunk to refer to. So by committing this code I have: - enabled the use of separate databindings across client/service - allowed extension with reuse of the PBR calculation. Scott Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Fix For: Java-SCA-2.0 Attachments: 3894.patch, 3894.tests.patch As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3901) Problem unwrapping repeated elements (for maxOccurs1) payloads using DOM databinding (from JAX-WS binding.ws impl)
[
https://issues.apache.org/jira/browse/TUSCANY-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071167#comment-13071167
]
Scott Kurz commented on TUSCANY-3901:
-
Though I'd noticed there seemed to be code missing to group like elements when
unwrapping (for wrapper children with maxOccurs1), there's also the question
of why we are going down the child-child transform path rather than
wrapper-wrapper.
I'd assumed it had something to do with the wsdl-gen issue, however I just
noticed a completely separate bug in the DOMWrapperHandler.isInstance() method.
In r1151141, then, I just fixed this latter bug.Antonio, if you are
actually sending the wrapper elem as payload which the service-side is
expecting, this probably will be enough to cause your test to work.I'm
still planning on working on the child-child transform path in this JIRA, in
which we can tolerate an incorrect wrapper element (typically the wrong NS)
with otherwise conforming children. I committed my test, ported from
databinding-axiom, @Ignore(d) now since it will fail. And yes, there is
probably another wsdlgen JIRA as Simon Nash and Mike observed.
You might be interested in giving it a try.
Problem unwrapping repeated elements (for maxOccurs1) payloads using DOM
databinding (from JAX-WS binding.ws impl)
---
Key: TUSCANY-3901
URL: https://issues.apache.org/jira/browse/TUSCANY-3901
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.0-Beta2
Reporter: Antonio De Berardis
Assignee: Scott Kurz
Labels: array, wsdl
@Remotable
public interface CrmService {
public void test(String[] arr);
}
generate the following WSDL:
wsdl:definitions name=CrmServiceService
targetNamespace=http://interfaces/;
wsdl:types
xs:schema targetNamespace=http://jaxb.dev.java.net/array; version=1.0
xs:complexType final=#all name=stringArray
xs:sequence
xs:element maxOccurs=unbounded minOccurs=0 name=item nillable=true
type=xs:string/
/xs:sequence
/xs:complexType
/xs:schema
xs:schema attributeFormDefault=qualified elementFormDefault=unqualified
targetNamespace=http://interfaces/;
xs:element name=test
xs:complexType
xs:sequence
xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true
type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=testResponse
xs:complexType/
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=test
wsdl:part name=test element=test /wsdl:part
/wsdl:message
wsdl:message name=testResponse
wsdl:part name=testResponse element=testResponse /wsdl:part
/wsdl:message
wsdl:portType name=CrmService
wsdl:operation name=test
wsdl:input message=test /wsdl:input
wsdl:output message=testResponse /wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=CrmServiceBinding type=CrmService
SOAP:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=test
SOAP:operation/
wsdl:input
SOAP:body use=literal/
/wsdl:input
wsdl:output
SOAP:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=CrmService
wsdl:port name=CrmServiceSOAP11Port binding=CrmServiceBinding
SOAP:address location=http://localhost:8087/CrmComponent/CrmService/
/wsdl:port
/wsdl:service
/wsdl:definitions
Calling the method form a simple java client causes:
GRAVE: java.lang.IllegalArgumentException: Argument is not an array
org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: Argument is not an array
at
org.apache.tuscany.sca.core.databinding.transformers.Array2ArrayTransformer.transform(Array2ArrayTransformer.java:100)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:232)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:444)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.processRequest(DataTransformationInterceptor.java:69)
at
org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:57)
at
[jira] [Reopened] (TUSCANY-3890) Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz reopened TUSCANY-3890: - I'd like to re-open pointing to a failing test, but a quick note instead why I think this is an issue. While we ported a good chunk of 2931 I don't see the part breaking apart the Operation WrapperInfo(s). I'd think though that an XML-in, Object-out test could pass still as Object serialization doesn't use the JAXWS wrapper. So I'd think there's still an issue here. Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x - Key: TUSCANY-3890 URL: https://issues.apache.org/jira/browse/TUSCANY-3890 Project: Tuscany Issue Type: Sub-task Components: SCA Java Runtime Reporter: Simon Laws Fix For: Java-SCA-2.0 TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms was added to 1.x after the 2.x branch was taken. Needs porting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3901) Problem unwrapping repeated elements (for maxOccurs1) payloads using DOM databinding (from JAX-WS binding.ws impl)
[
https://issues.apache.org/jira/browse/TUSCANY-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3901:
Assignee: Scott Kurz
Summary: Problem unwrapping repeated elements (for maxOccurs1) payloads
using DOM databinding (from JAX-WS binding.ws impl) (was: The WSDL generated
by binding.ws for a method with an array as input generates errors when
invoking this method.)
Problem unwrapping repeated elements (for maxOccurs1) payloads using DOM
databinding (from JAX-WS binding.ws impl)
---
Key: TUSCANY-3901
URL: https://issues.apache.org/jira/browse/TUSCANY-3901
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.0-Beta2
Reporter: Antonio De Berardis
Assignee: Scott Kurz
Labels: array, wsdl
@Remotable
public interface CrmService {
public void test(String[] arr);
}
generate the following WSDL:
wsdl:definitions name=CrmServiceService
targetNamespace=http://interfaces/;
wsdl:types
xs:schema targetNamespace=http://jaxb.dev.java.net/array; version=1.0
xs:complexType final=#all name=stringArray
xs:sequence
xs:element maxOccurs=unbounded minOccurs=0 name=item nillable=true
type=xs:string/
/xs:sequence
/xs:complexType
/xs:schema
xs:schema attributeFormDefault=qualified elementFormDefault=unqualified
targetNamespace=http://interfaces/;
xs:element name=test
xs:complexType
xs:sequence
xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true
type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=testResponse
xs:complexType/
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=test
wsdl:part name=test element=test /wsdl:part
/wsdl:message
wsdl:message name=testResponse
wsdl:part name=testResponse element=testResponse /wsdl:part
/wsdl:message
wsdl:portType name=CrmService
wsdl:operation name=test
wsdl:input message=test /wsdl:input
wsdl:output message=testResponse /wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=CrmServiceBinding type=CrmService
SOAP:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=test
SOAP:operation/
wsdl:input
SOAP:body use=literal/
/wsdl:input
wsdl:output
SOAP:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=CrmService
wsdl:port name=CrmServiceSOAP11Port binding=CrmServiceBinding
SOAP:address location=http://localhost:8087/CrmComponent/CrmService/
/wsdl:port
/wsdl:service
/wsdl:definitions
Calling the method form a simple java client causes:
GRAVE: java.lang.IllegalArgumentException: Argument is not an array
org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: Argument is not an array
at
org.apache.tuscany.sca.core.databinding.transformers.Array2ArrayTransformer.transform(Array2ArrayTransformer.java:100)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:232)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46)
at
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:444)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.processRequest(DataTransformationInterceptor.java:69)
at
org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:57)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:125)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:108)
at
org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointImpl.invoke(RuntimeEndpointImpl.java:298)
at
org.apache.tuscany.sca.binding.ws.jaxws.JAXWSBindingProvider.invoke(JAXWSBindingProvider.java:207)
at
org.apache.tuscany.sca.binding.ws.jaxws.JAXWSBindingProvider.invoke(JAXWSBindingProvider.java:61)
at
com.sun.xml.internal.ws.api.server.InstanceResolver$1.invokeProvider(InstanceResolver.java:245)
at
com.sun.xml.internal.ws.server.InvokerTube$2.invokeProvider(InvokerTube.java:145)
at
com.sun.xml.internal.ws.server.provider.SyncProviderInvokerTube.processRequest(SyncProviderInvokerTube.java:67)
at
[jira] [Updated] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3894: Attachment: 3894.patch Here is a patch which only does the copy in the binding if it detects that the DataTransformationInterceptor will NOT be established on the wire. It may leave some things to be desired... For one, what if the Mediator-invoked transformer(s) somehow don't result in a copy being made (is this even possible?) Then we wouldn't get the PBV semantics. That said, I can't think of such a case today for existing transformers. Also note that BaseDataBinding.copy just returns its input (i.e. does NOT do a copy), so we could have such a hole in theory..but probably not in practice..today. Also, it might be nicer to do the isPBV and isTransformationRequired in a single place, or somehow unify the two calculations so we don't have to call isTransformationRequired twice, but I can't think of a better way right now. Finally, I know we've been trying to be careful about declaring cross-module SPIs wrt the OSGi runtime, so not sure if anyone would object to now exporting a new package: org.apache.tuscany.sca.core.databinding.wire Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Fix For: Java-SCA-2.0 Attachments: 3894.patch, 3894.tests.patch As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13061378#comment-13061378 ] Scott Kurz commented on TUSCANY-3894: - I gave what I called the object reference graph issue a bit more thought. I'm sorry if this discussion is rediscovering the wheel since I'm sure I could search and read that it's already been well-understood (on this list even???), but here goes my rehash: Let me use an example: If I have: public void m1(Person p1, Person p2) and if I do: Person p = ... ref.m1(p,p); then I'm asking is the object identity on the client side preserved on the service side, i.e. does p1==p2? I was concerned because for the binding-ws-axis2 impl, the answer is definitely no, and it seemed nice to have this local default binding impl behave in the same way as the interoperable WS binding.It's different because with MediatorImpl.copyInput(...) and the use of IdentityHashMap, p1==p2 is true. However, for our own binding-rmi, object identity is preserved. So I guess you could say it's just a question of whether you want the binding to be more Java-centric (RMI-like) or XML-centric (WS-like), and I guess precedence would argue to leave things alone all other things being equal. That means the only open issue is are we OK with the single-databinding requirement or should we add the ability to leverage the DataTransformationInterceptor? (With the delegation potentially added by TUSCANY-3884, we could have both and then the question is which should the default be)? Circling back to the object identity thing if a switch to use the DTI with XML-centric copy as the default changed the object identity story, then, I'd think this wouldn't be a huge deal, coming before a final 2.0 release especially. Any thoughts? Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
Binding.sca local behavior: copy vs. mediate, same-databinding assumption -- Key: TUSCANY-3894 URL: https://issues.apache.org/jira/browse/TUSCANY-3894 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884 the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation. Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either. Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3884) binding.sca local delegation
[ https://issues.apache.org/jira/browse/TUSCANY-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057818#comment-13057818 ] Scott Kurz commented on TUSCANY-3884: - Simon, Yes I realize I'm mixing up the issue of needing to delegate the local invocation with the question of how to do the data copy for a PBV local invocation. Sorry about that... I was responding to something I'd mention in my first comment asking for clarification, and then twisting that into an example of the need to delegate. I might rephrase my comments as: - today's PBV local invocation, in using Mediator.copyXXX, assumes that source/target use the same databinding. - use cases requiring different databindings would need a different copy algorithm, e.g. using a WSDL operation and the Mediatory.mediateXXX methods - assuming there's value in keeping the existing code (doing the copyXXX), we could factor these two different algorithms into two local delegate provider impls That's where I was going, but one might also say that the PBV+local+copyXXX isn't really worth keeping after all, and should be replaced with a PBV+local+mediateXXX. That is a separate issue, and I can open a new JIRA if it helps (I'm interested in understanding your comment: I think that by this stage we know that the source and target are at least expected to be of the same databinding). binding.sca local delegation Key: TUSCANY-3884 URL: https://issues.apache.org/jira/browse/TUSCANY-3884 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-Beta2 Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Binding.sca currently delegates for remote semantics but implements local semantics in it's own provider. Should we create a separate local binding an delegate to that so it can we swapped out without affecting the provider functionality. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3884) binding.sca local delegation
[ https://issues.apache.org/jira/browse/TUSCANY-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057469#comment-13057469 ] Scott Kurz commented on TUSCANY-3884: - I just realized a more fundamental issue with using copyXXX is that it assumes both source and target use the same databinding. At least, the JAXBDataBinding.copy() assumes both source and target are JAXB. So one thing I can see a need for in a delegate impl is the usage of a WSDL operation to model the binding operation and the use of mediateXXX to transform. binding.sca local delegation Key: TUSCANY-3884 URL: https://issues.apache.org/jira/browse/TUSCANY-3884 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-Beta2 Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Binding.sca currently delegates for remote semantics but implements local semantics in it's own provider. Should we create a separate local binding an delegate to that so it can we swapped out without affecting the provider functionality. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3884) binding.sca local delegation
[ https://issues.apache.org/jira/browse/TUSCANY-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054524#comment-13054524 ] Scott Kurz commented on TUSCANY-3884: - Simon, You're talking about local as in colocated (single JVM), right? Not local as in PBR, in contrast to remotable (PBV).Just clarifying since most times I've seen the word semantics we're talking about PBR vs. PBV. I'm not just nitpicking since there are some data-related semantics associated with the current colocated code. By this I'm referring to the use of Mediator.copyXXX rather than the use of the mediateXXX methods invoked by the DataTransformationInterceptor.The copy results in a different object graph than the DTI and also I believe does not use wrapper-wrapper transform whereas the DTI typically does in our default Java/JAXB use case. But I think you're mostly referring to delegating to the provider impl like we do with the non-colocated (distributable) case? binding.sca local delegation Key: TUSCANY-3884 URL: https://issues.apache.org/jira/browse/TUSCANY-3884 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-Beta2 Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Binding.sca currently delegates for remote semantics but implements local semantics in it's own provider. Should we create a separate local binding an delegate to that so it can we swapped out without affecting the provider functionality. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3882) Are there any changes in 1.x that we still need to apply to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13053951#comment-13053951 ] Scott Kurz commented on TUSCANY-3882: - Simon, I know we never did the work (for binding.jms to separate request/response wireformats) in https://issues.apache.org/jira/browse/TUSCANY-2931 in 2.x. Not sure how I'd argue for/against us needing it in 2.x... I'd say we would eventually want/need it though. We recently realized https://issues.apache.org/jira/browse/TUSCANY-3869 that we hadn't done some of Simon Nash's WSDL-gen changes in 2.x... So that's covered by this JIRA, but not sure if there are others besides the issue raised. That's all I can think of at the moment though I feel there might be one lurking in the back of my mind. Are there any changes in 1.x that we still need to apply to 2.x --- Key: TUSCANY-3882 URL: https://issues.apache.org/jira/browse/TUSCANY-3882 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-M5 Reporter: Simon Laws Fix For: Java-SCA-2.0 I don't know this to be true but I'm wondering if there are still changes in 1.x that we need in 2.x. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3857) unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data
[ https://issues.apache.org/jira/browse/TUSCANY-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030923#comment-13030923 ] Scott Kurz commented on TUSCANY-3857: - In r1101239, I committed a fix for this. It first tries to use the wrapper element's schema to guide the unwrapping. If this fails, (most likely because of an operation wrapper child not present in the payload wrapper), then we revert to unwrapping by groups of similar elements. To do this, I introduced a new boolean: isOmissible, which in schema terms is true if minOccurs=0 The net result continues to support invalid elements (e.g. in the case where we have a Java that's similar to an existing WSDL but not actually generated from it).Though a side effect of this change is that I validate multiple consecutive child elements against the schema (i.e. ensure that the corresponding ElementInfo isMany is true).. there's probably a payload out there for which the behavior is different then but I'm not giving it any more thought. Finally... on the wrap path (not mentioned in my original problem writeup), I added some code which will simply omit writing a null element into the wrapper in case nillable=false, i.e. I prefer to wrap 'null' as xsi:nil=true but will also simply not write anything into the wrapper. Though it may seem more symmetric to look at the isOmissible flag in this case, I couldn't see making the behavior any different after doing so, so didn't. unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data --- Key: TUSCANY-3857 URL: https://issues.apache.org/jira/browse/TUSCANY-3857 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Databinding-SDO Reporter: Scott Kurz Priority: Minor In r1086760, I committed a change to OMElementWrapperHandler.getChildren so that it could handle unwrapping a wrapper with missing children, i.e. children with schema def of minOccurs=0 which aren't present as a child of the wrapper. The code we had would, after not finding a child of given QName, group the wrapper children into like-QName-elements and then allow indexing into this list of groups. This would prevent the next wrapper child from matching normally in the minOccurs=0 case, so I removed that logic. However, now I've broken our handling of schema-invalid payloads, as seen in the module: testing\itest\ws\endpoint-references Will have to think about how to handle both cases. I don't recall us talking about it in awhile, but I think the handling of XSD-invalid data is a significant feature of Tuscany that we should try not to break. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3857) unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data
[ https://issues.apache.org/jira/browse/TUSCANY-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030925#comment-13030925 ] Scott Kurz commented on TUSCANY-3857: - One more note... I did take a quick look at the DOMWrapperHandler in implementing this, and saw that this handler lacks a lot of the function of the AXIOM one. Rather than open a vague JIRA I'll try to find some time to follow up on the specific issues. I wonder if it's worth factoring out some of the logic to a databinding-neutral place.. if it's going to be this complicated. unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data --- Key: TUSCANY-3857 URL: https://issues.apache.org/jira/browse/TUSCANY-3857 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Databinding-SDO Reporter: Scott Kurz Priority: Minor In r1086760, I committed a change to OMElementWrapperHandler.getChildren so that it could handle unwrapping a wrapper with missing children, i.e. children with schema def of minOccurs=0 which aren't present as a child of the wrapper. The code we had would, after not finding a child of given QName, group the wrapper children into like-QName-elements and then allow indexing into this list of groups. This would prevent the next wrapper child from matching normally in the minOccurs=0 case, so I removed that logic. However, now I've broken our handling of schema-invalid payloads, as seen in the module: testing\itest\ws\endpoint-references Will have to think about how to handle both cases. I don't recall us talking about it in awhile, but I think the handling of XSD-invalid data is a significant feature of Tuscany that we should try not to break. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3857) unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data
[ https://issues.apache.org/jira/browse/TUSCANY-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014033#comment-13014033 ] Scott Kurz commented on TUSCANY-3857: - In r1087339, I reverted the OMElementWrapperHandler behavior to keep the itest passing. unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data --- Key: TUSCANY-3857 URL: https://issues.apache.org/jira/browse/TUSCANY-3857 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Databinding-SDO Reporter: Scott Kurz Priority: Minor In r1086760, I committed a change to OMElementWrapperHandler.getChildren so that it could handle unwrapping a wrapper with missing children, i.e. children with schema def of minOccurs=0 which aren't present as a child of the wrapper. The code we had would, after not finding a child of given QName, group the wrapper children into like-QName-elements and then allow indexing into this list of groups. This would prevent the next wrapper child from matching normally in the minOccurs=0 case, so I removed that logic. However, now I've broken our handling of schema-invalid payloads, as seen in the module: testing\itest\ws\endpoint-references Will have to think about how to handle both cases. I don't recall us talking about it in awhile, but I think the handling of XSD-invalid data is a significant feature of Tuscany that we should try not to break. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3857) unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data
unwrapping OMElementWrapperHandler can't easily tolerate both non-valid data and minOccurs=0 data --- Key: TUSCANY-3857 URL: https://issues.apache.org/jira/browse/TUSCANY-3857 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Databinding-SDO Reporter: Scott Kurz Priority: Minor In r1086760, I committed a change to OMElementWrapperHandler.getChildren so that it could handle unwrapping a wrapper with missing children, i.e. children with schema def of minOccurs=0 which aren't present as a child of the wrapper. The code we had would, after not finding a child of given QName, group the wrapper children into like-QName-elements and then allow indexing into this list of groups. This would prevent the next wrapper child from matching normally in the minOccurs=0 case, so I removed that logic. However, now I've broken our handling of schema-invalid payloads, as seen in the module: testing\itest\ws\endpoint-references Will have to think about how to handle both cases. I don't recall us talking about it in awhile, but I think the handling of XSD-invalid data is a significant feature of Tuscany that we should try not to break. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-3832) Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data
[ https://issues.apache.org/jira/browse/TUSCANY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz resolved TUSCANY-3832. - Resolution: Fixed Assignee: Scott Kurz Fixed in 1070926 (and 1070928), enabling async bare test (in 1070929). Fixed by adding new isCompatibleWithoutUnwrapByValue method to InterfaceContractMapper. Changed logic in binding-sca-runtime so that if source/target operations do not have the same wrapper style, we do not do a mediator copyXXX, as we assume a DataTransformationInterceptor will be set up to do the transform. Also made a step towards simplifying wrapped vs. bare behavior and terminology by introducing notSubjectToWrapping as discussed on mailing list thread referenced in this JIRA. Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data Key: TUSCANY-3832 URL: https://issues.apache.org/jira/browse/TUSCANY-3832 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Attachments: 3832.diff This is the problem I mentioned here: http://markmail.org/message/yxq7w4aooawkiiog I'm attaching a patch to reproduce this problem. First, I un-@Ignore(d) Simon Laws' bare test in the implementation-sample extension module, (and fixed up the logic a bit). Then, although we're still discussing how to simplify the coding logic and naming in this area... I made my own simplification for now, (to make this test pass), replacing bare with notSubjectToWrapping. If we stop right there.. I think there would still be some work to do... as some binding-corba-runtime tests are now failing. Though I haven't looked into why those tests are failing.. I'm taking a guess that it doesn't have to do with the issue of this JIRA. Included in the patch is a not-too-thought-out fix.My fix adds a header to the Tuscany Message in the DataTransformInterceptor and looks for this header in SCABindingInvoker in order to know whether or not to call Mediator.copyXXX. Like I say in a comment in SCABindingInvoker: // This relies on the fact that the response Message is actually the same as the request Message. Is that a safe // assumption??? At least this starts the discussion even if it's not complete. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-3832) Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data
[ https://issues.apache.org/jira/browse/TUSCANY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz closed TUSCANY-3832. --- Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data Key: TUSCANY-3832 URL: https://issues.apache.org/jira/browse/TUSCANY-3832 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz Assignee: Scott Kurz Priority: Minor Attachments: 3832.diff This is the problem I mentioned here: http://markmail.org/message/yxq7w4aooawkiiog I'm attaching a patch to reproduce this problem. First, I un-@Ignore(d) Simon Laws' bare test in the implementation-sample extension module, (and fixed up the logic a bit). Then, although we're still discussing how to simplify the coding logic and naming in this area... I made my own simplification for now, (to make this test pass), replacing bare with notSubjectToWrapping. If we stop right there.. I think there would still be some work to do... as some binding-corba-runtime tests are now failing. Though I haven't looked into why those tests are failing.. I'm taking a guess that it doesn't have to do with the issue of this JIRA. Included in the patch is a not-too-thought-out fix.My fix adds a header to the Tuscany Message in the DataTransformInterceptor and looks for this header in SCABindingInvoker in order to know whether or not to call Mediator.copyXXX. Like I say in a comment in SCABindingInvoker: // This relies on the fact that the response Message is actually the same as the request Message. Is that a safe // assumption??? At least this starts the discussion even if it's not complete. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-3832) Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data
Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data Key: TUSCANY-3832 URL: https://issues.apache.org/jira/browse/TUSCANY-3832 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz Priority: Minor This is the problem I mentioned here: http://markmail.org/message/yxq7w4aooawkiiog I'm attaching a patch to reproduce this problem. First, I un-@Ignore(d) Simon Laws' bare test in the implementation-sample extension module, (and fixed up the logic a bit). Then, although we're still discussing how to simplify the coding logic and naming in this area... I made my own simplification for now, (to make this test pass), replacing bare with notSubjectToWrapping. If we stop right there.. I think there would still be some work to do... as some binding-corba-runtime tests are now failing. Though I haven't looked into why those tests are failing.. I'm taking a guess that it doesn't have to do with the issue of this JIRA. Included in the patch is a not-too-thought-out fix.My fix adds a header to the Tuscany Message in the DataTransformInterceptor and looks for this header in SCABindingInvoker in order to know whether or not to call Mediator.copyXXX. Like I say in a comment in SCABindingInvoker: // This relies on the fact that the response Message is actually the same as the request Message. Is that a safe // assumption??? At least this starts the discussion even if it's not complete. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-3832) Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data
[ https://issues.apache.org/jira/browse/TUSCANY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3832: Attachment: 3832.diff Invocation chain may run through Mediator copyInput after DataTransformationInterceptor has already transformed data Key: TUSCANY-3832 URL: https://issues.apache.org/jira/browse/TUSCANY-3832 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz Priority: Minor Attachments: 3832.diff This is the problem I mentioned here: http://markmail.org/message/yxq7w4aooawkiiog I'm attaching a patch to reproduce this problem. First, I un-@Ignore(d) Simon Laws' bare test in the implementation-sample extension module, (and fixed up the logic a bit). Then, although we're still discussing how to simplify the coding logic and naming in this area... I made my own simplification for now, (to make this test pass), replacing bare with notSubjectToWrapping. If we stop right there.. I think there would still be some work to do... as some binding-corba-runtime tests are now failing. Though I haven't looked into why those tests are failing.. I'm taking a guess that it doesn't have to do with the issue of this JIRA. Included in the patch is a not-too-thought-out fix.My fix adds a header to the Tuscany Message in the DataTransformInterceptor and looks for this header in SCABindingInvoker in order to know whether or not to call Mediator.copyXXX. Like I say in a comment in SCABindingInvoker: // This relies on the fact that the response Message is actually the same as the request Message. Is that a safe // assumption??? At least this starts the discussion even if it's not complete. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz resolved TUSCANY-3819. - Resolution: Fixed Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz closed TUSCANY-3819. --- Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3823) Issues in JavaInterfaceUtil operation vs. method matching when Holders are involved
Issues in JavaInterfaceUtil operation vs. method matching when Holders are involved --- Key: TUSCANY-3823 URL: https://issues.apache.org/jira/browse/TUSCANY-3823 Project: Tuscany Issue Type: Improvement Reporter: Scott Kurz Priority: Minor In TUSCANY-2180 we recognized that an impl could implement two different service interfaces with the same operation name, but different parm types (signatures). With the code I added in TUSCANY-3819 for multiple output (Holder) support, I know I didn't update this logic. I'm not 100% sure there's a problem here, but I'm pretty sure there is. So I'm opening this as a placeholder TODO.Apparently we don't have a test for this either since I haven't noticed that I broke anything. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12987584#action_12987584 ] Scott Kurz commented on TUSCANY-3819: - Added some more fixes in r1063548. Note a big difference with the end result here is that the JavaOperation input DataType will have had the OUT-only parms stripped out, by the time we're through the Java and JAXWS introspectors. So if you're looking at the operation parameter mode list, you have to recognize that the indexed elements of this list don't match up directly with the input children of the JavaOperation inputType (because the OUT-only parms have been stripped out). Also, on a minor note... fixed the 2nd,3rd,etc. output child elements to have names like argN, which is how wsgen does it per JAX-WS, not outN like we'd had it. Opened TUSCANY-3823 for some follow-up work needed for the issue noted in TUSCANY-2180. Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986352#action_12986352 ] Scott Kurz commented on TUSCANY-3819: - Added a fix to the bare+Holder along with void return type + Holder in r1063125. Also added a convenience method to JavaOperation, boolean hasReturnTypeVoid(). Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985955#action_12985955 ] Scott Kurz commented on TUSCANY-3819: - Added some tests in r1062956 (@Ignore'd) showing that I didn't correctly consider the case with a void return type and one or more Holder(s). Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12984214#action_12984214 ] Scott Kurz commented on TUSCANY-3819: - Checked in patch at r1061329.Note the bare tests will still fail.. so leaving this JIRA open. Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3819: Attachment: 3819.1.patch Since a lot of this code's been around for quite awhile, I thought I'd write up the changes I made in this patch, which I'll commit unless I hear any objections: 1. fix Java JAXWS introspection to build input wrapper type ignoring OUT-only, output wrapper type including Holders (and excluding return type void) 2. mediating btw. right number of inputs/outputs in Java-centric JDKInvocationHandler, JavaImplInvoker, rather than I2I, O2O. For example, in transforming from XML-Java in a wrapped-unwrapped transform, an OUT-only parm is NOT going to have a corresponding child of the input wrapper element, so we need to account for this and map the wrapper children to the correct Java parms, skipping over and filling in with empty Holders those OUT-only parms. So what I'm saying is we chose to not worry about this at all in I2I, to keep it from having too many Java-centric special cases, and we worry about this in the JDKInvocationHandler, JavaImplInvoker. 3. Fixed the O2O logic --- and some more minor changes --- 4. fix WrapperInfo.getUnwrappedOutputType() to use ListDataType logical. 5. removed wrapping of output DataType with idl:output DataType in mediateOutput, added setting in WSDL introspector to parallel input handling. (Also made WSDLIntrospector more symmetric wrt outputs as compared to inputs) 6. moved IDL_INPUT (idl:input) and other static constants from DataBinding to Operation, so we can use a constant, rather than String value, in WSDL introspector (moved from Databinding since this doesn't introduce new cross-module dependencies) 7. renamed Operation hasHolders() to hasArrayWrappedOutput() to be used in contexts where we need to understand if the invoker has passed us a single output needing to be wrapped in an array. (Maybe this is better than hasHolders() which is more Java-centric, maybe it's still more complicated?) 8. Note the check for void output ends up changing from check to: get(0)==null to size()==0 -- Some TODOs remaining: - check in test - Bare Holder support - wsdlgen testing Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: 3819.1.patch, holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3819) Multiple problems with multiple outputs (Holder support)
[ https://issues.apache.org/jira/browse/TUSCANY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3819: Attachment: holder-ws-service-multiple-outputs.zip Multiple problems with multiple outputs (Holder support) Key: TUSCANY-3819 URL: https://issues.apache.org/jira/browse/TUSCANY-3819 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-M5 Reporter: Scott Kurz Assignee: Scott Kurz Attachments: holder-ws-service-multiple-outputs.zip It seems like there are a few related problems when a Java method has multiple outputs, as my test will show. I think the history here is: - We first added support for using a single Holder parm (with INOUT or OUT) but only in the case in which there was only one output altogether, (i.e. the return type was void). - Brent recently added some support for truly using multiple outputs. I'm not sure what if any tests we have though using multiple outputs. For example, the test in samples/learning-more/binding-ws/holder-ws-service only has a single output. However, I do have a guess at how this might have worked at some point (maybe for Brent). I think if we have a binding/wire configuration which uses MediatorImpl.copyInput, etc, it might work with the existing code. However, I think when we use the DataTransformationInterceptor which in a typical Java-XML transform uses the Input2InputTransformer, etc., it exposes holes in the wrapping that need to be more fully implemented. I'll attach a test. In the meantime I've assigned to myself as I have started working on a few areas including the Input2Input, Output2Output transformers, the JAXWS interface processor. Also the wsdlgen will need some tweaking I think. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3793) WSDL: Generated Namespace for Faults are Wrong
[
https://issues.apache.org/jira/browse/TUSCANY-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933446#action_12933446
]
Scott Kurz commented on TUSCANY-3793:
-
This looks like the same symptom as the second one mentioned in TUSCANY-3778,
right?
WSDL: Generated Namespace for Faults are Wrong
--
Key: TUSCANY-3793
URL: https://issues.apache.org/jira/browse/TUSCANY-3793
Project: Tuscany
Issue Type: Bug
Components: Java SCA Databinding-SDO
Affects Versions: Java-SCA-1.6
Environment: Linux, Fedora 10, 2.6.27.38-170.2.113.fc10.i686.PAE
Reporter: Christian Nolte
Refering to mailing list post:
http://osdir.com/ml/user-tuscany.apache.org/2010-10/msg00059.html
The namespaces for faults (Exceptions) are wrong. Consider this example
(modified HelloWorldService):
helloWorldService.composite:
---
?xml version=1.0 encoding=UTF-8?
sca:composite xmlns:sca=http://www.osoa.org/xmlns/sca/1.0;
name=helloWorldService
targetNamespace=http://eclipse.org/HelloWorldService/src/resources/HelloWorldService;
sca:component name=HelloWorldServiceComponent
sca:implementation.java class=implementations.HelloWorldServiceImpl/
sca:service name=IHelloWorldService
sca:interface.java interface=service.IHelloWorldService/
sca:binding.ws/
/sca:service
/sca:component
/sca:composite
---
IHelloWorldService.java:
---
package service;
import javax.jws.WebService;
@WebService
public interface IHelloWorldService {
public String sayHello() throws Exception;
}
---
HelloWorldServiceImpl.java:
---
package implementations;
import org.osoa.sca.annotations.Service;
import service.IHelloWorldService;
@Service(IHelloWorldService.class)
public class HelloWorldServiceImpl implements IHelloWorldService{
private String sayHello = Hello remote SCA;
@Override
public String sayHello() throws Exception {
return this.sayHello;
}
}
---
Generated http://localhost:8080/HelloWorldServiceComponent?wsdl
---
?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=IHelloWorldServiceService
targetNamespace=http://service/; xmlns=http://service/;
xmlns:ns4=http://lang.java/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:SOAP=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:SOAP11=http://schemas.xmlsoap.org/wsdl/soap/;
wsdl:types
xs:schema targetNamespace=http://lang.java/; version=1.0
xmlns:tns=http://lang.java/; xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:element name=Exception type=tns:Exception/
xs:complexType name=Exceptionxs:sequencexs:element minOccurs=0
name=message type=xs:string//xs:sequence/xs:complexType
/xs:schema
xs:schema attributeFormDefault=qualified
elementFormDefault=unqualified targetNamespace=http://service/;
xmlns:tns=http://service/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;xs:element
name=sayHelloResponsexs:complexTypexs:sequencexs:element
minOccurs=0 name=return nillable=true
type=xs:string//xs:sequence/xs:complexType/xs:elementxs:element
name=sayHelloxs:complexType//xs:element/xs:schema
/wsdl:types
wsdl:message name=sayHelloResponse
wsdl:part name=sayHelloResponse element=sayHelloResponse
/wsdl:part
/wsdl:message
wsdl:message name=sayHello
wsdl:part name=sayHello element=sayHello
/wsdl:part
/wsdl:message
wsdl:message name=Exception
wsdl:part name=Exception element=ns4:Exception
/wsdl:part
/wsdl:message
wsdl:portType name=IHelloWorldService
wsdl:operation name=sayHello
wsdl:input message=sayHello
/wsdl:input
wsdl:output message=sayHelloResponse
/wsdl:output
wsdl:fault name=Exception message=ns4:Exception
/wsdl:fault
/wsdl:operation
/wsdl:portType
wsdl:binding name=IHelloWorldServiceBinding type=IHelloWorldService
SOAP:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=sayHello
SOAP:operation/
wsdl:input
SOAP:body use=literal/
/wsdl:input
wsdl:output
SOAP:body use=literal/
/wsdl:output
wsdl:fault name=Exception
SOAP:fault name=Exception use=literal/
/wsdl:fault
/wsdl:operation
/wsdl:binding
wsdl:service name=IHelloWorldServiceService
wsdl:port name=IHelloWorldServicePort
binding=IHelloWorldServiceBinding
SOAP:address
location=http://velian01:8080/HelloWorldServiceComponent/
/wsdl:port
/wsdl:service
/wsdl:definitions
---
The solution is to change the namespace
message=ns4:Exception
to
message=tns:Exception
These faults should always be placed into Namespace tns.
--
This message is automatically generated by JIRA.
-
You can reply to
[jira] Commented: (TUSCANY-3709) XSD defined in WSDL is leaking out into global scope
[ https://issues.apache.org/jira/browse/TUSCANY-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919849#action_12919849 ] Scott Kurz commented on TUSCANY-3709: - Simon, I was trying to look at the tests before asking my question, but let me just ask. Are you saying that the contribution scope is being polluted with XSD definitions or is it truly a global testbucket-scope that's being polluted? My point being that I'd always assumed that an schema definition inline to a WSDL was not hidden or further-scoped in any way simply because it was inline. Just want to be sure you aren't arguing that point in which case I'd hope to discuss further (I don't see the spec clarifying this, do you?). Scott XSD defined in WSDL is leaking out into global scope Key: TUSCANY-3709 URL: https://issues.apache.org/jira/browse/TUSCANY-3709 Project: Tuscany Issue Type: Bug Components: OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws The otests define many WSDL and some of then re-define the same XSD elements in different ways. This causes Tuscany problems as we aggregate WSDL together and hence sometimes, depending on which way the wind's blowing, we pick up the the wrong schema. This is evident in the following tests. Failed tests: testDummy(client.ASM_12007_TestCase) * testDummy(client.ASM_5016_TestCase) testDummy(client.ASM_6004_TestCase) testDummy(client.ASM_6007_TestCase) testDummy(client.ASM_12008_TestCase) * testDummy(client.ASM_6014_TestCase) testDummy(client.ASM_6008_TestCase) testDummy(client.ASM_6034_TestCase) I note that the two tests marked with * actually have incorrect expected error messages recorded because of this fault. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3698) JMS Binding erases the stack trace of RuntimeException's
[
https://issues.apache.org/jira/browse/TUSCANY-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916454#action_12916454
]
Scott Kurz commented on TUSCANY-3698:
-
The original behavior was the design, (sort of). We had in mind the case
where a non-Tuscany JMS consumer tries to receive the JMS Message, and it might
not have access to any SCA-specific classes in its environment.
That said, along these lines I'd think we should be accomplishing this by
setting a generic java.lang.RuntimeException into the message rather than
ServiceRuntimeException, so maybe as it's coded it's not all that different.
There was much discussion about exception handling over binding.jms. At first
it might seem odd that the checked exc is treated different but as part of the
contract it is more reasonable that any client environment would have to
account for the checked exception.
Since we brought this up, I'd suggest switching to RuntimeException.
Scott
JMS Binding erases the stack trace of RuntimeException's
Key: TUSCANY-3698
URL: https://issues.apache.org/jira/browse/TUSCANY-3698
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.5, Java-SCA-1.5.1, Java-SCA-1.6,
Java-SCA-2.0-M1, Java-SCA-2.0-M2, Java-SCA-2.0-M3, Java-SCA-2.0-M4,
Java-SCA-2.0-M5
Environment: Tuscany Java SCA 1.6
Windows XP SP3
JDK 1.6
Reporter: Padraig Myers
Fix For: Java-SCA-1.6, Java-SCA-2.0-M5
Attachments: Patch_TUSCANY-3698
In the file
org.apache.tuscany.sca.binding.jms.provider.AbstractMessageProcessor there is
a method createFaultMessage(), this method creates a JMS fault message from
an exception that is passed into the method.
However if the messages is a RuntimeException a new exception is created,
thereby losing the stack trace from the original exception.
The offending piece of code is
ObjectMessage message = session.createObjectMessage();
String causeMsg;
if (o instanceof RuntimeException) {
message.setObject(new
ServiceRuntimeException(o.getMessage()));
} else {
// for a checked exception return the checked exception
message.setObject(o);
}
message.setBooleanProperty(JMSBindingConstants.FAULT_PROPERTY,
true);
return message;
there is no reason that RuntimeException's should be treated any differently
and therefore the code above can be replaced with
ObjectMessage message = session.createObjectMessage();
message.setObject(o);
message.setBooleanProperty(JMSBindingConstants.FAULT_PROPERTY,
true);
return message;
This means that the component that gets this JMS message will be able to log
the true source of the exception and not lose all the stack trace information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3698) JMS Binding erases the stack trace of RuntimeException's
[
https://issues.apache.org/jira/browse/TUSCANY-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3698:
Attachment: 3698.skurz.patch
I guess we could add the stack trace, element by element, to message.I'm
sure you could format this better, but something like this patch.
I guess I like that slightly better, but in all these discussions, nothing ever
jumped out as a clear winner of a suggestion.
JMS Binding erases the stack trace of RuntimeException's
Key: TUSCANY-3698
URL: https://issues.apache.org/jira/browse/TUSCANY-3698
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.5, Java-SCA-1.5.1, Java-SCA-1.6,
Java-SCA-2.0-M1, Java-SCA-2.0-M2, Java-SCA-2.0-M3, Java-SCA-2.0-M4,
Java-SCA-2.0-M5
Environment: Tuscany Java SCA 1.6
Windows XP SP3
JDK 1.6
Reporter: Padraig Myers
Fix For: Java-SCA-1.6, Java-SCA-2.0-M5
Attachments: 3698.skurz.patch, Patch_TUSCANY-3698
In the file
org.apache.tuscany.sca.binding.jms.provider.AbstractMessageProcessor there is
a method createFaultMessage(), this method creates a JMS fault message from
an exception that is passed into the method.
However if the messages is a RuntimeException a new exception is created,
thereby losing the stack trace from the original exception.
The offending piece of code is
ObjectMessage message = session.createObjectMessage();
String causeMsg;
if (o instanceof RuntimeException) {
message.setObject(new
ServiceRuntimeException(o.getMessage()));
} else {
// for a checked exception return the checked exception
message.setObject(o);
}
message.setBooleanProperty(JMSBindingConstants.FAULT_PROPERTY,
true);
return message;
there is no reason that RuntimeException's should be treated any differently
and therefore the code above can be replaced with
ObjectMessage message = session.createObjectMessage();
message.setObject(o);
message.setBooleanProperty(JMSBindingConstants.FAULT_PROPERTY,
true);
return message;
This means that the component that gets this JMS message will be able to log
the true source of the exception and not lose all the stack trace information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3681) NullPointerException in WireFormatJMSDefaultReferenceInterceptor
[ https://issues.apache.org/jira/browse/TUSCANY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12913552#action_12913552 ] Scott Kurz commented on TUSCANY-3681: - I see. So Simon, you're referring to the specification of: org.oasisopen.sca.client.SCAClientFactory.getService(ClassT interfaze, String serviceURI) So I'm not sure where this matter stands in 2.x, but in any case I'm still not sure we would expect this to work in 1.x.Would we? Note that an alternative bypassing this problem would be to insert a component between the client and the service exposed over binding.jms. This intermediate component could be configured with a reference with binding.jms, and in turn accessed by the client via a getService() call, (the intermediate component service being exposed over the default binding). NullPointerException in WireFormatJMSDefaultReferenceInterceptor Key: TUSCANY-3681 URL: https://issues.apache.org/jira/browse/TUSCANY-3681 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.6 Environment: JDK 1.6.0_21, Windows XP Reporter: Sebastian Millies Attachments: test.zip I call a service method exposed by a JMS binding. However, at the time when the constructor of org.apache.tuscany.sca.binding.jms.wireformat.jmsdefault.runtim.WireFormatJMSDefaultReferenceInterceptor is executed, the inputWrapperMap argument is empty (size 0), which leads to a NullPointerException later on when the requestMsg is constructed in method invokeRequest. The stack trace is this: java.lang.NullPointerException at org.apache.tuscany.sca.binding.jms.wireformat.jmsdefault.runtime.WireFormatJMSDefaultReferenceInterceptor.invokeRequest(WireFormatJMSDefaultReferenceInterceptor.java:99) at org.apache.tuscany.sca.binding.jms.wireformat.jmsdefault.runtime.WireFormatJMSDefaultReferenceInterceptor.invoke(WireFormatJMSDefaultReferenceInterceptor.java:78) at org.apache.tuscany.sca.binding.jms.provider.RRBJMSBindingInvoker.invoke(RRBJMSBindingInvoker.java:203) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:55) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:349) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:193) at $Proxy10.log_lmt(Unknown Source) at logtester.LogServiceTester.main(LogServiceTester.java:49) strangely, the Exception goes away when I specify a wire format of jmsTextXML on the binding (as shown below), but not if I specify jmsdefault. I don't expect to be passing text messages. service name=LogService interface.java interface=com.softwareag.ps.platform.log.LogService/ binding.jms initialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61619 destination create=ifnotexist name=RequestQueue type=queue/ ts:wireFormat.jmsTextXML/ /binding.jms /service I attach a very bare bones Eclipse project with one interface, one impl class, one composite file and one testdriver. The project uses a user library called TUSCANY for the Tuscany classes. -- Sebastian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3681) NullPointerException in WireFormatJMSDefaultReferenceInterceptor
[
https://issues.apache.org/jira/browse/TUSCANY-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12913031#action_12913031
]
Scott Kurz commented on TUSCANY-3681:
-
So the issue here is that you're using the SCAClient getService() API to get a
proxy to a service configured with binding.jms.
I'm a bit ignorant though, so forgive me for the dumb question to the general
ML... is it valid to use this API with a service configured with non-default
binding?
If so, it seems we simply have a bug, as the self reference doesn't fully
initialize in WireFormatJMSDefaultReferenceProvider.
This comment in the WireFormatJMSDefaultReferenceProvider code itself questions
if this is valid, (though I'm not sure if the scope of this question is the
same as the one I'm asking):
// TODO - can be null if it's a $self$ reference. Need to decide if
//that's valid
if (reference.getReference() == null){
interfaceContract = reference.getInterfaceContract();
return;
-- Scott
NullPointerException in WireFormatJMSDefaultReferenceInterceptor
Key: TUSCANY-3681
URL: https://issues.apache.org/jira/browse/TUSCANY-3681
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.6
Environment: JDK 1.6.0_21, Windows XP
Reporter: Sebastian Millies
Attachments: test.zip
I call a service method exposed by a JMS binding. However, at the time when
the constructor of
org.apache.tuscany.sca.binding.jms.wireformat.jmsdefault.runtim.WireFormatJMSDefaultReferenceInterceptor
is executed, the inputWrapperMap argument is empty (size 0), which leads to a
NullPointerException later on when the requestMsg is constructed in method
invokeRequest.
The stack trace is this:
java.lang.NullPointerException
at
org.apache.tuscany.sca.binding.jms.wireformat.jmsdefault.runtime.WireFormatJMSDefaultReferenceInterceptor.invokeRequest(WireFormatJMSDefaultReferenceInterceptor.java:99)
at
org.apache.tuscany.sca.binding.jms.wireformat.jmsdefault.runtime.WireFormatJMSDefaultReferenceInterceptor.invoke(WireFormatJMSDefaultReferenceInterceptor.java:78)
at
org.apache.tuscany.sca.binding.jms.provider.RRBJMSBindingInvoker.invoke(RRBJMSBindingInvoker.java:203)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:55)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:349)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:193)
at $Proxy10.log_lmt(Unknown Source)
at logtester.LogServiceTester.main(LogServiceTester.java:49)
strangely, the Exception goes away when I specify a wire format of
jmsTextXML
on the binding (as shown below), but not if I specify jmsdefault. I don't
expect to be passing text messages.
service name=LogService
interface.java interface=com.softwareag.ps.platform.log.LogService/
binding.jms
initialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory
jndiURL=tcp://localhost:61619
destination create=ifnotexist name=RequestQueue type=queue/
ts:wireFormat.jmsTextXML/
/binding.jms
/service
I attach a very bare bones Eclipse project with one interface, one impl
class, one composite file and one testdriver. The project uses a user library
called TUSCANY for the Tuscany classes.
-- Sebastian
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3664) Add holder support to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910761#action_12910761 ] Scott Kurz commented on TUSCANY-3664: - Just wanted to note we need to keep in mind places in our code where we assume that a Java method has an array of input args but only a single return value. If the fix to implement full Holder support involves changing this assumption, then we might need to reconsider some of these instances. The example I have in mind is the binding.jms wireFormat.jmsObject support, in which we have cases on the input side where we're concerned whether or not to serialize an array or its contents. Not sure what other examples there might be. I haven't had time to look at your changes to see if you've consider this, but just wanted to mention it while the JIRA was still open. Scott Add holder support to 2.x - Key: TUSCANY-3664 URL: https://issues.apache.org/jira/browse/TUSCANY-3664 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime, OASIS Compliance - TUSCANY Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws Assignee: Brent Daniel There are a number of related JIRA that introduced some holder support and related samples to the 1.x code base including: TUSCANY-2332 TUSCANY-2557 TUSCANY-2768 It's not clear whether the support added to 1.x was complete but it didn't apparently make it into 2.x which seems to be a bit of an oversight. We need to create some samples to exercise the various holder scenarios, OUT, IN/OUT etc. and then take a look at the 1.x changes to see if they are suitable for 2.x or whether we need to work up a different solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3643) binding-ws-axis2 should use Axis2 ServiceClient in thread-safe manner
binding-ws-axis2 should use Axis2 ServiceClient in thread-safe manner - Key: TUSCANY-3643 URL: https://issues.apache.org/jira/browse/TUSCANY-3643 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-M5, Java-SCA-1.6 Reporter: Scott Kurz Priority: Minor In running a version of our 1.x code (the exact version doesn't so much matter since the problem has existed for awhile), against the Axis2 trunk running multiple threads at once, I hit the problem: java.lang.NullPointerException at org.apache.axis2.client.ServiceClient.cleanupTransport(ServiceClient.java:860) at org.apache.axis2.client.ServiceClient.createClient(ServiceClient.java:665) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.createOperationClient(..) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(...) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke() It seems Axis2 has introduced a new autoOperationCleanup function. So one solution would be to disable this. However, it seems from discussions such as this: http://www.mail-archive.com/axis-...@ws.apache.org/msg48406.html that a better solution would be to stop using a single Axis2 ServiceClient across threads, since apparently these are not intended to be thread-safe. So it seems we should switch from using an instance variable to a local variable to hold these refs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3625) Issue converting case on methodName for WSDL-derived operation used with binding.ejb reference
[
https://issues.apache.org/jira/browse/TUSCANY-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3625:
Attachment: 3625.fix.1.patch
Here's a patch which fixes the problem.
I wasn't sure if the Operation here could really be anything other than
JavaOperation, and mentioned this in a comment in my source.
I wasn't able to run a full build with itests however, but thought I'd post
this patch anyway.
Issue converting case on methodName for WSDL-derived operation used with
binding.ejb reference
--
Key: TUSCANY-3625
URL: https://issues.apache.org/jira/browse/TUSCANY-3625
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-1.6
Environment: sca-java-1.x, r959098
Reporter: Scott Kurz
Priority: Minor
Attachments: 3625.fix.1.patch, 3625.recreate.patch
So the scenario here is I start with a WSDL with upper-case operation name,
say Add, and then generate Java from it. Well, JAX-WS says to generate
with a name starting with lower-case, such as:
@WebService
public interface AddServiceRemote {
@WebMethod(operationName = Add)
double add(double n1, double n2);
Say that someone implements an EJB using this Java interface, and now I'm
trying to use this same Java interface to build an SCA client of this EJB
using a reference with binding.ejb.
The problem I'll run into in the current Tuscany impl (1.x.. haven't looked
at 2.x) is that our runtime will use the JAXWSJavaInterfaceProcessor to
calculate the operation name as Add (starts with capital 'A'). It will
pass that name to the binding-ejb-runtime code which will blow up with
NoSuchMethodException.
I think the right thing to do here is to work backwards from the operation
name to the real Java method name we want to invoke over. In other words,
treat this as a bug and fix it.
Since Java- WSDL mapping questions are always interesting, however...
I'll put this out there for comment.
Thanks,
Scott
---
Not sure how to make a new test so I'll tweak an existing test and attach to
show a recreate
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3625) Issue converting case on methodName for WSDL-derived operation used with binding.ejb reference
Issue converting case on methodName for WSDL-derived operation used with
binding.ejb reference
--
Key: TUSCANY-3625
URL: https://issues.apache.org/jira/browse/TUSCANY-3625
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-1.6
Environment: sca-java-1.x, r959098
Reporter: Scott Kurz
Priority: Minor
So the scenario here is I start with a WSDL with upper-case operation name, say
Add, and then generate Java from it. Well, JAX-WS says to generate with a
name starting with lower-case, such as:
@WebService
public interface AddServiceRemote {
@WebMethod(operationName = Add)
double add(double n1, double n2);
Say that someone implements an EJB using this Java interface, and now I'm
trying to use this same Java interface to build an SCA client of this EJB using
a reference with binding.ejb.
The problem I'll run into in the current Tuscany impl (1.x.. haven't looked at
2.x) is that our runtime will use the JAXWSJavaInterfaceProcessor to calculate
the operation name as Add (starts with capital 'A'). It will pass that name
to the binding-ejb-runtime code which will blow up with NoSuchMethodException.
I think the right thing to do here is to work backwards from the operation
name to the real Java method name we want to invoke over. In other words,
treat this as a bug and fix it.
Since Java- WSDL mapping questions are always interesting, however... I'll
put this out there for comment.
Thanks,
Scott
---
Not sure how to make a new test so I'll tweak an existing test and attach to
show a recreate
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3625) Issue converting case on methodName for WSDL-derived operation used with binding.ejb reference
[
https://issues.apache.org/jira/browse/TUSCANY-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3625:
Attachment: 3625.recreate.patch
Issue converting case on methodName for WSDL-derived operation used with
binding.ejb reference
--
Key: TUSCANY-3625
URL: https://issues.apache.org/jira/browse/TUSCANY-3625
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-1.6
Environment: sca-java-1.x, r959098
Reporter: Scott Kurz
Priority: Minor
Attachments: 3625.recreate.patch
So the scenario here is I start with a WSDL with upper-case operation name,
say Add, and then generate Java from it. Well, JAX-WS says to generate
with a name starting with lower-case, such as:
@WebService
public interface AddServiceRemote {
@WebMethod(operationName = Add)
double add(double n1, double n2);
Say that someone implements an EJB using this Java interface, and now I'm
trying to use this same Java interface to build an SCA client of this EJB
using a reference with binding.ejb.
The problem I'll run into in the current Tuscany impl (1.x.. haven't looked
at 2.x) is that our runtime will use the JAXWSJavaInterfaceProcessor to
calculate the operation name as Add (starts with capital 'A'). It will
pass that name to the binding-ejb-runtime code which will blow up with
NoSuchMethodException.
I think the right thing to do here is to work backwards from the operation
name to the real Java method name we want to invoke over. In other words,
treat this as a bug and fix it.
Since Java- WSDL mapping questions are always interesting, however...
I'll put this out there for comment.
Thanks,
Scott
---
Not sure how to make a new test so I'll tweak an existing test and attach to
show a recreate
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3418) wireFormat.jmsText is broken in some use cases
[ https://issues.apache.org/jira/browse/TUSCANY-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12798116#action_12798116 ] Scott Kurz commented on TUSCANY-3418: - I can see in the code we don't have an equals() impl for WireFormatJMSText, which means in JMSBindingReferenceBindingProvider.configureBindingChain() our check to ensure that we don't add the interceptor twice is failing. Since we are adding it twice, it's already a JMSMessage after the 1st interceptor, which explains the ClassCastExc. Sorry my machine is tied up and I can't try the patch right now though... but we could do something like WireFormatJMSTextXML does with equals(). wireFormat.jmsText is broken in some use cases - Key: TUSCANY-3418 URL: https://issues.apache.org/jira/browse/TUSCANY-3418 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-1.5 Reporter: Dan Hatfield Assignee: Simon Laws From Simon Laws: Hi Dan Yes, I'm seeing it here also. In this case the WireFormatJMSTextReferenceInterceptor is being added to the wire twice for some reason and that's causing the problem. Don't know why yet but can you raise a JIRA [1] for the problem and I'll look at making a fix for it. Basically, I modified the composite files to the have tuscany name space and placed the ts:wireFormat.jmsText/ in the appropriate locations. So the hello world service example now looks like this: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:ts=http://tuscany.apache.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworld component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.java interface=helloworld.HelloWorldService/ binding.jms initialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61619 destination name=RequestQueue create=ifnotexist/ response destination name=ResponseQueue create=ifnotexist/ ts:wireFormat.jmsText/ /response ts:wireFormat.jmsText/ /binding.jms /service /component /composite And the hello world reference jms example now looks like this: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:ts=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:hw=http://helloworld; name=helloworldjmsreference !-- A component with a reference promoted as a composite reference -- component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService interface.java interface=helloworld.HelloWorldService/ binding.jms initialContextFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61619 destination name=RequestQueue create=always/ response destination name=ResponseQueue create=always/ ts:wireFormat.jmsText/ /response ts:wireFormat.jmsText/ /binding.jms /reference /component /composite I expected this to work based on the fact that the HelloWorld interface is: public String getGreetings(String s) And my understanding of wireFormat.jmsText is this: The data in the JMS message is the string representation of data coming from/going to the service operation. The service operation signature is expected to have a single String parameter However, when I run this, I get the following error: d helloworld-reference-jms C:\Documents and Settings\hatfieda\workspace\Tuscany\tuscany-sca-1.5.1\samples\h elloworld-reference-jmsant run Buildfile: build.xml [java] INFO: Starting node: helloworldjmsreference.composite [java] Injected helloWorldService [java] Called getGreetings [java] Exception in thread main java.lang.ClassCastException: org.apache. activemq.command.ActiveMQTextMessage [java] at org.apache.tuscany.sca.binding.jms.wireformat.jmstext.runtime .WireFormatJMSTextReferenceInterceptor.invokeRequest(WireFormatJMSTextReferenceI nterceptor.java:83) [java] at org.apache.tuscany.sca.binding.jms.wireformat.jmstext.runtime
[jira] Updated: (TUSCANY-3384) XSDModelResolver only loads WSDL-inline types in interface.wsdl context; (also not threadsafe)
[ https://issues.apache.org/jira/browse/TUSCANY-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3384: Attachment: 3384.sk.patch My idea on how to do this. XSDModelResolver only loads WSDL-inline types in interface.wsdl context; (also not threadsafe) --- Key: TUSCANY-3384 URL: https://issues.apache.org/jira/browse/TUSCANY-3384 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.5 Reporter: Scott Kurz Priority: Minor Attachments: 3384.sk.patch I would like to improve the XSDModelResolver by allowing it to load XSD types that are defined inline in a WSDL file, even if they have not already been loaded by processing an interface.wsdl or binding.ws. On a separate note, I would like to introduce some locking into XSDModelResolver so that two threads can load from a given resolver at the same time (the XmlSchema schemaCollection.read() method will throw an exception if two threads read the same schema). I will attach a patch as soon as I can.. in the meantime I wanted to write that up in case anyone didn't agree with the idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3384) XSDModelResolver only loads WSDL-inline types in interface.wsdl context; (also not threadsafe)
XSDModelResolver only loads WSDL-inline types in interface.wsdl context; (also not threadsafe) --- Key: TUSCANY-3384 URL: https://issues.apache.org/jira/browse/TUSCANY-3384 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.5 Reporter: Scott Kurz Priority: Minor I would like to improve the XSDModelResolver by allowing it to load XSD types that are defined inline in a WSDL file, even if they have not already been loaded by processing an interface.wsdl or binding.ws. On a separate note, I would like to introduce some locking into XSDModelResolver so that two threads can load from a given resolver at the same time (the XmlSchema schemaCollection.read() method will throw an exception if two threads read the same schema). I will attach a patch as soon as I can.. in the meantime I wanted to write that up in case anyone didn't agree with the idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3238) Use of WS binding results in exception when returning data
[
https://issues.apache.org/jira/browse/TUSCANY-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748503#action_12748503
]
Scott Kurz commented on TUSCANY-3238:
-
Chad,
You could add this to the generated DataType, e.g.:
@XmlSeeAlso(StringType.class)
public class DataType {
I think the way to improve the Tuscany story here would be to implement the
approach I believe is in JAX-WS 2.1, which is to look for an @XmlSeeAlso on the
Java interface class.
I think that would definitely be doable, though I'm not sure we have any
processing specific to a particular databinding like JAXB at the interface
level so some thought would be needed to make that fit in nicely.
Use of WS binding results in exception when returning data
--
Key: TUSCANY-3238
URL: https://issues.apache.org/jira/browse/TUSCANY-3238
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension, Java SCA Misc Binding
Extensions
Affects Versions: Java-SCA-1.5
Environment: Microsoft Windows XP SP2
Java JDK 1.5.0_18
Apache Tuscany SCA Java 1.5 / 1.6 SNAPSHOT (r805992)
JAX-WS RI 2.1.7
Ant 1.7.0
Reporter: Chad Phillips
Attachments: ant_client.log, ant_server.log, src-gen.zip, test.zip
When the server in attached test program tries to return data to the client
(request was made via a webservice), an exception is being thrown from the
JAXB data binding (see the attached ant_server.log). I'm not sure what
exactly is causing the issue but it may have to do with the use of
substitution groups in the XSD used to generate the binding classes for the
objects being returned. This is just speculation on my part as I have done
similar things in the past, without using substitution groups, and I did not
encounter this issue.
Here is how the test program is being used:
Create/run the server:
Open a command prompt and run the following commands (adjust paths as
necessary):
cd project directory
set JAXWS_HOME=C:\jaxws-ri-2.1.7
set TUSCANY_HOME=C:\tuscany-sca-1.5
ant clean server
Create/run the client:
Open another command prompt and run the following commands (adjust paths as
necessary):
cd project directory
set JAXWS_HOME=C:\jaxws-ri-2.1.7
set TUSCANY_HOME=C:\tuscany-sca-1.5
ant client
The server and client outputs are attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3235) Exception thrown in JAXBContentCache.getPackages() when running applications with Java 2 security enabled
[ https://issues.apache.org/jira/browse/TUSCANY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747932#action_12747932 ] Scott Kurz commented on TUSCANY-3235: - No, Class.getClassLoader() does not throw any checked exceptions... good catch. Exception thrown in JAXBContentCache.getPackages() when running applications with Java 2 security enabled - Key: TUSCANY-3235 URL: https://issues.apache.org/jira/browse/TUSCANY-3235 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.5 Environment: All Reporter: Hasan Muhammad Assignee: Simon Laws Fix For: Java-SCA-1.5 Attachments: 3235_patch.txt When Java 2 security is enabled, invoking a service with JAXB data binding results in the following exception Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:211) at java.lang.Class.getClassLoader(Class.java:594) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getPackages(JAXBContextCache.java:451) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBClasses(JAXBContextCache.java:402) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:252) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:181) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:213) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:89) at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:52) at org.apache.tuscany.sca.databinding.jaxb.axiom.JAXB2OMElement.transform(JAXB2OMElement.java:40) at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:200) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:113) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:192) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:48) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:113) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:431) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:65) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3238) Use of WS binding results in exception when returning data
[ https://issues.apache.org/jira/browse/TUSCANY-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748031#action_12748031 ] Scott Kurz commented on TUSCANY-3238: - Chad, Tuscany will build the JAXBContext used to marshal your return value by introspecting the service interface parameters and return value.So if the interface parm/return type is the base (abstract) type but you want to pass a derived (concrete) type value then we have a problem. One way to get this to work is to add (by hand) an @XmlSeeAlso in the generated abstract type referring to the concrete type.. that way when we build the JAXBContext we'll build it including the concrete type as well. Use of WS binding results in exception when returning data -- Key: TUSCANY-3238 URL: https://issues.apache.org/jira/browse/TUSCANY-3238 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Misc Binding Extensions Affects Versions: Java-SCA-1.5 Environment: Microsoft Windows XP SP2 Java JDK 1.5.0_18 Apache Tuscany SCA Java 1.5 / 1.6 SNAPSHOT (r805992) JAX-WS RI 2.1.7 Ant 1.7.0 Reporter: Chad Phillips Attachments: ant_client.log, ant_server.log, test.zip When the server in attached test program tries to return data to the client (request was made via a webservice), an exception is being thrown from the JAXB data binding (see the attached ant_server.log). I'm not sure what exactly is causing the issue but it may have to do with the use of substitution groups in the XSD used to generate the binding classes for the objects being returned. This is just speculation on my part as I have done similar things in the past, without using substitution groups, and I did not encounter this issue. Here is how the test program is being used: Create/run the server: Open a command prompt and run the following commands (adjust paths as necessary): cd project directory set JAXWS_HOME=C:\jaxws-ri-2.1.7 set TUSCANY_HOME=C:\tuscany-sca-1.5 ant clean server Create/run the client: Open another command prompt and run the following commands (adjust paths as necessary): cd project directory set JAXWS_HOME=C:\jaxws-ri-2.1.7 set TUSCANY_HOME=C:\tuscany-sca-1.5 ant client The server and client outputs are attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3167) Look to cache JAXBPropertyDescriptor in XMLRootElementUtil
Look to cache JAXBPropertyDescriptor in XMLRootElementUtil -- Key: TUSCANY-3167 URL: https://issues.apache.org/jira/browse/TUSCANY-3167 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Priority: Minor Profiling shows that method createPropertyDescriptorMap() is a bottleneck, with the underlying cause related to newing up this map every time: MapString, JAXBPropertyDescriptor map = new HashMapString, JAXBPropertyDescriptor(); Look to cache somehow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3126) open up injection capability for implementation.java via ResourceHost
open up injection capability for implementation.java via ResourceHost - Key: TUSCANY-3126 URL: https://issues.apache.org/jira/browse/TUSCANY-3126 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.5 Reporter: Scott Kurz Priority: Minor See thread: http://markmail.org/thread/htzzv4nhvn65aiwi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes
[ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724099#action_12724099 ] Scott Kurz commented on TUSCANY-2640: - Thanks for implementing that idea so quickly...appreciate it. Yes I would find it useful to have in 1.x. Thanks, Scott Should use package(s) when possible in creating JAXBContext, not set of Classes --- Key: TUSCANY-2640 URL: https://issues.apache.org/jira/browse/TUSCANY-2640 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz Fix For: Java-SCA-Next The JAXBContextHelper method: createJAXBContext(TransformationContext tContext, boolean source) ends up calling JAXBContextCache.getJAXBContext(SetClass? classes) This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance(). It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()). The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation. My motive for caring here is in looking to support JAXB unmarshalling by global-element I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3121) binding.atom should leverage introspection when setting up call to mediator
binding.atom should leverage introspection when setting up call to mediator --- Key: TUSCANY-3121 URL: https://issues.apache.org/jira/browse/TUSCANY-3121 Project: Tuscany Issue Type: Improvement Reporter: Scott Kurz Assignee: Scott Kurz Fix For: Java-SCA-1.5.1 By constructing a new DataType in AtomBindingListenerServlet, AtomReferenceBindingProvider, we lose the ability to leverage the introspection of the Java interface to, say, calculate a databinding.This means we lose the ability to, say, combine bindng.atom with SDO. I will attach a suggested patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3121) binding.atom should leverage introspection when setting up call to mediator
[ https://issues.apache.org/jira/browse/TUSCANY-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3121: Attachment: 3121.patch binding.atom should leverage introspection when setting up call to mediator --- Key: TUSCANY-3121 URL: https://issues.apache.org/jira/browse/TUSCANY-3121 Project: Tuscany Issue Type: Improvement Reporter: Scott Kurz Assignee: Scott Kurz Fix For: Java-SCA-1.5.1 Attachments: 3121.patch By constructing a new DataType in AtomBindingListenerServlet, AtomReferenceBindingProvider, we lose the ability to leverage the introspection of the Java interface to, say, calculate a databinding.This means we lose the ability to, say, combine bindng.atom with SDO. I will attach a suggested patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3099) NumberFormatException occurs when parsing a JMSPriority attribute with string value
[ https://issues.apache.org/jira/browse/TUSCANY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721008#action_12721008 ] Scott Kurz commented on TUSCANY-3099: - Andrew, this is a spec bug apparently. It's been fixed in the OASIS spec as the only values are int values between 0 and 9. NumberFormatException occurs when parsing a JMSPriority attribute with string value --- Key: TUSCANY-3099 URL: https://issues.apache.org/jira/browse/TUSCANY-3099 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-1.5 Reporter: Andrew Mak When a JMS binding has a headers/@JMSPriority attribute with a string value, a NumberFormatException occurs when parsing the composite. Looking at the JMS binding spec, @JMSPriority has type string so I don't think it should throw an exception in this case. The stacktrace: java.lang.NumberFormatException: For input string: medium at java.lang.NumberFormatException.forInputString(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at org.apache.tuscany.sca.binding.jms.impl.JMSBindingProcessor.parseOperationHeaders(Unknown Source) at org.apache.tuscany.sca.binding.jms.impl.JMSBindingProcessor.parseOperationProperties(Unknown Source) at org.apache.tuscany.sca.binding.jms.impl.JMSBindingProcessor.read(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714424#action_12714424 ] Scott Kurz commented on TUSCANY-2967: - Though we've put forth a few ideas, I still don't see a clearly better alternative to what we have today for the non-XML formats. While my original point was that sending an ObjectMessage is really odd, I've since come around to the view that if we can't go all the way towards implementing a standard that can be used by non-Tuscany on the other side, then there may be no point changing the non-xml behavior until perhaps we learn what we could do better. For the unchecked/xml format, would it be too odd to use something similiar to what we will serialize with binding-ws-axis2 when an unchecked is thrown from the service side? This is a SOAP envelope with SOAP Fault, e.g. ?xml version=1.0 encoding=utf-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body soapenv:Fault faultcodesoapenv:Server/faultcode faultstringORIGINAL_RUNTIME_EXC_MESSAGE/faultstring detail/ /soapenv:Fault /soapenv:Body /soapenv:Envelope I guess we could think about EXACTLY how to populate the faultcode, faultstring elements (for the former we could just pick something and for the latter we could try to use the original unchecked's message). For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats Key: TUSCANY-2967 URL: https://issues.apache.org/jira/browse/TUSCANY-2967 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Assignee: ant elder For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea). Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage?True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms. But I wonder if this is too unexpected if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange. Maybe this needs more discussion.I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3065) Double use exposure in JAXBDataSource
[
https://issues.apache.org/jira/browse/TUSCANY-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714251#action_12714251
]
Scott Kurz commented on TUSCANY-3065:
-
Thanks Greg for the detailed writeup. Made these changes and committed in
r779808 in 1.x.(I didn't have permissions to assign the JIRA to myself
first though.)
Double use exposure in JAXBDataSource
-
Key: TUSCANY-3065
URL: https://issues.apache.org/jira/browse/TUSCANY-3065
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Reporter: Greg Dritschler
There is a potential double use of a Marshaller object in
org.apache.tuscany.sca.databinding.jaxb.axiom.JAXBDataSource.
The following code gets a marshaller from an underlying pool and then caches
it.
private Marshaller getMarshaller() throws JAXBException {
if (marshaller == null) {
// For thread safety, not sure we can cache the marshaller
marshaller = JAXBContextHelper.getMarshaller(context);
}
return marshaller;
}
The code which calls this method also releases the Marshaller back to the
pool. For example:
public void serialize(final OutputStream output, OMOutputFormat format)
throws XMLStreamException {
try {
// marshaller.setProperty(Marshaller.JAXB_ENCODING,
format.getCharSetEncoding());
AccessController.doPrivileged(new
PrivilegedExceptionActionObject() {
public Object run() throws Exception {
try {
Marshaller marshaller = getMarshaller();
marshaller.marshal(element, output);
} finally {
releaseMarshaller(marshaller);
}
return null;
}
});
} catch (PrivilegedActionException e) {
throw new XMLStreamException(e.getException());
}
}
So after this method runs, the member variable marshaller contains a
reference to an element in the free pool. If another thread obtains that
element, there is a potential of double use.
Proposed fix:
- Delete member variable marshaller.
- Change getMarshaller to just return the Marshaller obtained from
JAXBContextHelper without saving it.
- Change all callers of getMarshaller/releaseMarshaller to use local
variables. You'll note there's a local variable in the try paths, but then
the finally paths use the member variable. Both the try and finally should
use the same local 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-3054) Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class
Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class Key: TUSCANY-3054 URL: https://issues.apache.org/jira/browse/TUSCANY-3054 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Reporter: Scott Kurz Priority: Minor Nothing's broken .. just suggesting a better-performing impl. Will checkin shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-3003) Add option to do JAXB unmarshalling into a global element
Add option to do JAXB unmarshalling into a global element - Key: TUSCANY-3003 URL: https://issues.apache.org/jira/browse/TUSCANY-3003 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Reporter: Scott Kurz See ML thread: http://markmail.org/thread/q6k3rgq3ccxhg72i -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-3000) Turn databinding Mediator into a utility registered with UtilityExtensionPoint
[
https://issues.apache.org/jira/browse/TUSCANY-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704719#action_12704719
]
Scott Kurz commented on TUSCANY-3000:
-
Raymond, what would you think about factoring out the fault transform code in
DataTransformationInterceptor into some sort of utility as well?
Something like:
FaultTransformHelper {
public Object transformFault(Object result, Operation sourceOperation,
Operation targetOperation, MapString, Object metadata)
It seems likely that someone using the mediator as a utility would have to
write the exact same logic as the DTI uses to map faults.
I could post an example of what I mean...
(Or maybe this is bad form to pile on in this JIRA).
Thx,
Scott
Turn databinding Mediator into a utility registered with UtilityExtensionPoint
--
Key: TUSCANY-3000
URL: https://issues.apache.org/jira/browse/TUSCANY-3000
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.5
Reporter: Raymond Feng
Assignee: Raymond Feng
Fix For: Java-SCA-1.5
The MediatorImpl is used to create instances of Mediator which prevents the
extension registry to be passed. Register it as a utility will hide the impl
class and make it pluggable. Furthermore, it can gets other extension points
from the runtime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-3000) Turn databinding Mediator into a utility registered with UtilityExtensionPoint
[ https://issues.apache.org/jira/browse/TUSCANY-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-3000: Attachment: 3000.faultTransformHelper.idea.txt Here's something like what I had in mind (though this obviously doesn't use Mediator via an extension point). Turn databinding Mediator into a utility registered with UtilityExtensionPoint -- Key: TUSCANY-3000 URL: https://issues.apache.org/jira/browse/TUSCANY-3000 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.5 Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-1.5 Attachments: 3000.faultTransformHelper.idea.txt The MediatorImpl is used to create instances of Mediator which prevents the extension registry to be passed. Register it as a utility will hide the impl class and make it pluggable. Furthermore, it can gets other extension points from the runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2992) For binding.jms wireFormat.jmsdefault, consider smoothing over elementFormDefault differences
For binding.jms wireFormat.jmsdefault, consider smoothing over elementFormDefault differences - Key: TUSCANY-2992 URL: https://issues.apache.org/jira/browse/TUSCANY-2992 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Priority: Minor So another area where this wF.jmsdefault behavior of unwrapping a single input/output gets tricky is with respect to elementFormDefault, and let me bring up another area to consider. Consider the wrapped case, either top-down interface.wsdl or bottom-up interface.java - (the default in the absence of JAX-WS annotations being to treat Java as wrapped.) While, (according to the JMS binding spec's description of the default WF), we have to read or write the wrapper's single child, the schema-defined element in play is actually the operation-level wrapper element. The wrapper element's schema's elementFormDefault, then, will intersect with whether our child element is NS-qualified or not. When serializing (request or response), the thing to do seems simple enough: use the elementFormDefault of the wrapper elem definition to decide whether to serialize the child element with a NS (qualified) or without a NS (unqualified, the default). So for: wsdl:types schema elementFormDefault=qualified xmlns:tns=http://test; targetNamespace=http://test; ... element name=myOperation complexType sequence element name=arg1 type=xsd:int/ /sequence /complexType /element we serialize: tns:arg14/tns:arg1 whereas if we change the schema to elementFormDefault=unqualified (note this is the default for bottom-up generated schemas as well) we serialize: arg14/arg1 Seems simple enough, but what about deserialization? One approach would be to require the other side to understand the viewpoint of the SCA runtime doing the deserialization and whether or not the SCA runtime expects qualified or unqualified child elements (this is how our code is implemented today). According to this approach, receiving a JMS payload like: tns:arg14/tns:arg1 together with a service described by interface.java method such as: void myOperation(int x); would be a user error.The Java, absent JAXB annotations, maps to a schema with elementFormDefault=unqualified, and so we can't handle such a payload. An alternative approach would be to implement deserialization such that it could smooth over differences in elementFormDefault, i.e. handle either the unexpected presence or absence of a NS by ignoring or adding the NS as necessary. (Even then we could ask: should a NS that's present but incorrect also be smoothed over (ignored)?) Do we agree this change would be desirable? I wish I had more sense of how useful in practice this change would be. Not knowing that, at least opening the issue reminds us the issue exists, for later when someone asks why their data is null (as this is what happens in JAXB when you get the elemFormDefault incorrect). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703122#action_12703122 ] Scott Kurz commented on TUSCANY-2967: - Good point Simon: performing an XML serialization of a RuntimeException would also be another piece of implementing my suggestion. Going in a completely different direction, another approach would be to extend binding.jms (beyond even the OASIS spec) to allow configuration of a fault destination, separate from the response dest., which could have its own wireFormat.That might be a big enough step that we'd want to pose that to OASIS first... but I mention it thinking that if that is really the better solution we want, then it might not be worth trying to make the current state of affairs any better. Or it might... For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats Key: TUSCANY-2967 URL: https://issues.apache.org/jira/browse/TUSCANY-2967 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Assignee: ant elder For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea). Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage?True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms. But I wonder if this is too unexpected if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange. Maybe this needs more discussion.I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2966) Adjust binding.jms code since JMS BytesMessage bytes payload can only be read once
[ https://issues.apache.org/jira/browse/TUSCANY-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701784#action_12701784 ] Scott Kurz commented on TUSCANY-2966: - Just noticed there is a reset() on BytesMessage which seems to me better than adding to a context like I suggested. Adjust binding.jms code since JMS BytesMessage bytes payload can only be read once -- Key: TUSCANY-2966 URL: https://issues.apache.org/jira/browse/TUSCANY-2966 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Priority: Minor If we were to have each of an operationSelector and a wireFormat interceptor process a BytesMessage, then we would have a problem as the readBytes() method on the BytesMessage can only be called once, (at least in working with WebSphere Platform Messaging, not sure what the JMS spec says). So the code currently in OperationSelectorJMSDefaultServiceInterceptor (as of r765178), would not be able to do the readBytes and then later have the WireFormat interceptor read the bytes, as the cursor would already be at the end of the message. (Actually as OperationSelectorJMSDefaultServiceInterceptor is written today, you couldn't easily recreate this bug, as we only look at the bytes if we have textXML wireFormat, but we would never have this with a BytesMessage. I only noticed the problem in making some additional local changes). Probably the requestBytes/responseBytes need to be added to the JMSBindingContext or something like that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2964) Fix JMS operationSelector schema element name to operationSelector.jmsdefault to match OASIS
Fix JMS operationSelector schema element name to operationSelector.jmsdefault to match OASIS Key: TUSCANY-2964 URL: https://issues.apache.org/jira/browse/TUSCANY-2964 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2966) Adjust binding.jms code since JMS BytesMessage bytes payload can only be read once
Adjust binding.jms code since JMS BytesMessage bytes payload can only be read once -- Key: TUSCANY-2966 URL: https://issues.apache.org/jira/browse/TUSCANY-2966 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Priority: Minor If we were to have each of an operationSelector and a wireFormat interceptor process a BytesMessage, then we would have a problem as the readBytes() method on the BytesMessage can only be called once, (at least in working with WebSphere Platform Messaging, not sure what the JMS spec says). So the code currently in OperationSelectorJMSDefaultServiceInterceptor (as of r765178), would not be able to do the readBytes and then later have the WireFormat interceptor read the bytes, as the cursor would already be at the end of the message. (Actually as OperationSelectorJMSDefaultServiceInterceptor is written today, you couldn't easily recreate this bug, as we only look at the bytes if we have textXML wireFormat, but we would never have this with a BytesMessage. I only noticed the problem in making some additional local changes). Probably the requestBytes/responseBytes need to be added to the JMSBindingContext or something like that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2967) For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats Key: TUSCANY-2967 URL: https://issues.apache.org/jira/browse/TUSCANY-2967 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Reporter: Scott Kurz For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea). Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage?True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms. But I wonder if this is too unexpected if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange. Maybe this needs more discussion.I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2962) Throw an exception if multiple same-name operations are detected by WSDL intf introspector
Throw an exception if multiple same-name operations are detected by WSDL intf introspector -- Key: TUSCANY-2962 URL: https://issues.apache.org/jira/browse/TUSCANY-2962 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Scott Kurz Priority: Minor I noticed that a particular user error involving a badly-formed WSDL can be hard to debug. In my case (will attach example) I have the binding input/output @name not matching the portType input/output @name. Though wsimport has no problem generating Java compatible with my WSDL, the WSDL4J library processes my WSDL as having two distinct Operation(s) for my portType (will attach a sample program to show what I mean). Given the time it took me to realize what was going on later (I'll spare you the details), it seems a useful thing to do would have been for the WSDL introspector to flag this as an error instead of letting me go any further. Any issues with adding this type of validation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2962) Throw an exception if multiple same-name operations are detected by WSDL intf introspector
[ https://issues.apache.org/jira/browse/TUSCANY-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12698777#action_12698777 ] Scott Kurz commented on TUSCANY-2962: - If you run MyMain against the (bad) test.wsdl, you'll see the multiple WSDL4J Operations. Throw an exception if multiple same-name operations are detected by WSDL intf introspector -- Key: TUSCANY-2962 URL: https://issues.apache.org/jira/browse/TUSCANY-2962 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Scott Kurz Priority: Minor Attachments: MyMain.java, test.wsdl I noticed that a particular user error involving a badly-formed WSDL can be hard to debug. In my case (will attach example) I have the binding input/output @name not matching the portType input/output @name. Though wsimport has no problem generating Java compatible with my WSDL, the WSDL4J library processes my WSDL as having two distinct Operation(s) for my portType (will attach a sample program to show what I mean). Given the time it took me to realize what was going on later (I'll spare you the details), it seems a useful thing to do would have been for the WSDL introspector to flag this as an error instead of letting me go any further. Any issues with adding this type of validation? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2934) JMSBindingProcessor.write() needs to call out extensions (for WireFormats, etc.)
JMSBindingProcessor.write() needs to call out extensions (for WireFormats, etc.) Key: TUSCANY-2934 URL: https://issues.apache.org/jira/browse/TUSCANY-2934 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz Priority: Minor We have the WireFormatProcessor.write()'s implemented, but we don't call them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2930) Add wireFormat.jmsDefault for the JMS binding
[ https://issues.apache.org/jira/browse/TUSCANY-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683920#action_12683920 ] Scott Kurz commented on TUSCANY-2930: - Note OASIS refers specifically to element: wireFormat.jmsdefault (lowercase 'd'). Add wireFormat.jmsDefault for the JMS binding - Key: TUSCANY-2930 URL: https://issues.apache.org/jira/browse/TUSCANY-2930 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-Next Environment: All Reporter: Simon Laws Priority: Minor The default wire format behaviour of the JMS binding is currently wireFormat.jmsTextXML. This wire format has been modified to handle some default processing. We should have wireFormat.jmsTextXML just do the text xml processing and have wireFormat.jmsDefault handle the default wire format as described in the SCA specifications.See this ML discussion (http://www.mail-archive.com/dev%40tuscany.apache.org/msg06042.html) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2914) issues w/ StAX processing in JMSBindingProcessor
[
https://issues.apache.org/jira/browse/TUSCANY-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683042#action_12683042
]
Scott Kurz commented on TUSCANY-2914:
-
Hi Ram
Can't say I tested your patch, but I did look it over quick and it looks like a
good way to do it. Advancing in parseBindingProperties(), to the parent's
END_ELEMENT solves the problem for every element with a nested call to
parseBindingProperties().
issues w/ StAX processing in JMSBindingProcessor
Key: TUSCANY-2914
URL: https://issues.apache.org/jira/browse/TUSCANY-2914
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Reporter: Scott Kurz
Assignee: Ramkumar Ramalingam
Priority: Minor
Attachments: TUSCANY-2914.patch
I'm looking at JMSBindingProcessor.read(), and the way the read() method
relies on itself to advance the cursor past its children's END_ELEMENT seems
to be a problem.
The code is:
while (!endFound) {
int fg = reader.next();
switch (fg) {
case START_ELEMENT:
String elementName = reader.getName().getLocalPart();
if (destination.equals(elementName)) {
parseDestination(reader, jmsBinding);
} else if (connectionFactory.equals(elementName)) {
parseConnectionFactory(reader, jmsBinding);
} else {
}
reader.next();// PROBLEM!
break;
For child element 'SubscriptionHeaders', I could write that as either:
SubscriptionHeaders.../
OR
SubscriptionHeaders.../SubscriptionHeaders
OR
SubscriptionHeaders.
/SubscriptionHeaders
The first two shouldn't be a problem, I start with a START_ELEMENT and then
the next() back in read() advances me over the END_ELEMENT event. However,
the third is a problem, since there is a CHARACTERS event in the middle, in
which case the next() back in read() only takes me to the SubscriptionHeaders
END_ELEMENT, though the code at this point can only deal with 'binding.jms'
END_ELEMENT, (and since it doesn't get this, we get an error).
In general, it seems that to deal with this kind of thing, helper methods
that parse a child element should be responsible for themselves advancing the
cursor to their own child element's END_ELEMENT.
For what it's worth, I'm not sure how parseDestination() works either, it
seems like parseDestinationProperties() is going to advance the cursor too
far, but maybe I don't fully understand this scenario.
If I can get my build working, I'll post a recreate test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682646#action_12682646 ] Scott Kurz commented on TUSCANY-2906: - Hi, I opened the JIRA to say that the location/schemaLocation should be treated as a suggestion, and that we should not give up because these locations are incorrect or invalid. I mentioned how the BP says that WSDL location should be just a suggestion. Without consulting the specs, a reasonable behavior to me would be that we should look within the contribution, but not outside (via a contribution import) in the case where the location/schemaLocation is specified but is incorrect/invalid. I just took a look at the OSOA Assembly spec, and in Sec 1.10.5, it says that an SCA runtime should not attempt to use SCA artifact resolution (contribution import/export) after artifact-specific-resolution has failed. That seems to validate my view about what should happen. (branching off a bit into further discussion) The only thing which bothers me here is that this spec statement seems maybe ignorant of the possibility that, in an SCA-aware runtime, I might define that the artifact-specific mechanism for resolving location/schemaLocation involves following the SCA contribution import. Not sure if it matters for resolving this JIRA, but maybe interesting to think about. On the surface it seems to say that if I have some WSDLs doing xsd:import with @schemaLocation, and I zip up the XSDs into a separate contribution, and use contribution import/export... then I have to go remove the @schemaLocation attrs from the WSDL... which seems overly restrictive. WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations - Key: TUSCANY-2906 URL: https://issues.apache.org/jira/browse/TUSCANY-2906 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Assignee: Ramkumar Ramalingam Priority: Minor Attachments: 2906.recreate.jar My test app uses wsdl import and xsd import with @location and @schemaLocation, respectively, specifying values that don't actually correspond to relative locations within my contribution JAR.(The motive might be that in moving from my test env to my deploy env i've shuffled the relative paths around for some reason). When reading BasicProfile 1.1, section 4.2.4, I take that to mean that our runtime should be able to handle an incorrect @location (though 4.2.3 says it shouldn't be empty). Instead we blow up. In reading the XSD spec quickly I think the same should apply to @schemaLocation on XSD import, though I don't see that BP says anything about this. I did test to confirm that if @schemaLocation is simply left blank then we have no problem finding the XSD within the contribution... it's just a problem if it's set to a value that doesn't correspond to anything in the JAR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2906) WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations
WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations - Key: TUSCANY-2906 URL: https://issues.apache.org/jira/browse/TUSCANY-2906 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Priority: Minor My test app uses wsdl import and xsd import with @location and @schemaLocation, respectively, specifying values that don't actually correspond to relative locations within my contribution JAR.(The motive might be that in moving from my test env to my deploy env i've shuffled the relative paths around for some reason). When reading BasicProfile 1.1, section 4.2.4, I take that to mean that our runtime should be able to handle an incorrect @location (though 4.2.3 says it shouldn't be empty). Instead we blow up. In reading the XSD spec quickly I think the same should apply to @schemaLocation on XSD import, though I don't see that BP says anything about this. I did test to confirm that if @schemaLocation is simply left blank then we have no problem finding the XSD within the contribution... it's just a problem if it's set to a value that doesn't correspond to anything in the JAR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2906) WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2906: Attachment: 2906.recreate.jar WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations - Key: TUSCANY-2906 URL: https://issues.apache.org/jira/browse/TUSCANY-2906 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Priority: Minor Attachments: 2906.recreate.jar My test app uses wsdl import and xsd import with @location and @schemaLocation, respectively, specifying values that don't actually correspond to relative locations within my contribution JAR.(The motive might be that in moving from my test env to my deploy env i've shuffled the relative paths around for some reason). When reading BasicProfile 1.1, section 4.2.4, I take that to mean that our runtime should be able to handle an incorrect @location (though 4.2.3 says it shouldn't be empty). Instead we blow up. In reading the XSD spec quickly I think the same should apply to @schemaLocation on XSD import, though I don't see that BP says anything about this. I did test to confirm that if @schemaLocation is simply left blank then we have no problem finding the XSD within the contribution... it's just a problem if it's set to a value that doesn't correspond to anything in the JAR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2861) Null input not handled correctly over JMS binding for wireFormat.object, etc.
Null input not handled correctly over JMS binding for wireFormat.object, etc. -- Key: TUSCANY-2861 URL: https://issues.apache.org/jira/browse/TUSCANY-2861 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz When invoking a no-arg method on a service exposed over binding.jms with Object wireFormat, we're passing a raw, 'null' as the message body from the binding layer into the Java invoker... causing an IllegalArgumentException. This is for a Java method: xxx myOperation(); I took a quick look and noticed that, in the binding-ws-axis2, we will send an Object[0] to this JavaImplementationInvoker code, (though that comes from a wrapped-style transform). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2851) What happens if @Init throws a runtime exception? Should the container mark the instance as bad?
What happens if @Init throws a runtime exception? Should the container mark the instance as bad? - Key: TUSCANY-2851 URL: https://issues.apache.org/jira/browse/TUSCANY-2851 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Reporter: Scott Kurz Priority: Minor See these posts: http://markmail.org/thread/e4mptcmpr2j7epyl http://markmail.org/thread/3fqvabcyptcrujji referencing these spec issues: http://www.osoa.org/jira/browse/JAVA-65 There is no lifecycle defined for SCA Components http://www.osoa.org/jira/browse/JAVA-53 What happens if init() throws a runtime exception -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673288#action_12673288 ] Scott Kurz commented on TUSCANY-2845: - Without a spec, I can't think of a better thing to do for now for throwing unchecked exceptions over a binding.jms service than to always use an ObjectMessage, but I think we should do it in a way such that we don't require any SCA or Tuscany code on the client. To do this, we're going to have to accept that we're going to accept that we'll lose the chain of exceptions we may have in the service-side container and simply throw a new java.lang.RuntimeException (and not ServiceRuntimeException), possibly reusing a chained exception's message (or maybe not even). So the non-SCA programming model for dealing with this becomes: // listen for a response if (responseMsg is ObjectMessage) look for RuntimeException in message and deal with this somehow else handle normally the message of=f expected message type (depending on wireFormat) And for an SCA reference we would have to do the same for every wireFormat on the reference side, (and dealing with the RuntimeExc would translate into throwing ServiceRuntimeException). Thoughts? Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2848) Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format
[ https://issues.apache.org/jira/browse/TUSCANY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673304#action_12673304 ] Scott Kurz commented on TUSCANY-2848: - I don't think we necessarily need to fix this. If we follow the binding.ws example, which uses the JAX-WS spec mapping between an exception in the Java runtime and the platform-neutral, schema-mappable fault carried by the exception, then we just need to worry about serializing the fault, and not the chained exceptions. This puts a burden on the bottom-up, interface.java programmer to understand this pattern when using checked Java exceptions with the text/xml wireformat. The alternatives would be to either start from WSDL, top-down, and generate the exception/fault, OR to use a different wireFormat, like wireFormat.jmsObject, in which Java serialization will be used and chained exceptions will be preserved (Of course that last alternative assumes a certain spec interpretation which hasn't been agreed upon, but I guess you could say that across the board). Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format - Key: TUSCANY-2848 URL: https://issues.apache.org/jira/browse/TUSCANY-2848 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-Next Reporter: ant elder Chained exceptions get lost when returning a checked exception with the JMS binding with text xml wire format. It looks like the databinding framework is not including the cause information when converting from the checked exception to XML in an OMElement -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2845: Component/s: Java SCA JMS Binding Extension Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException
[ https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673022#action_12673022 ] Scott Kurz commented on TUSCANY-2845: - I wrote this up as an issue with the textXML wireFormat handling... but let's look at the wireFormat.jmsObject handling... we can't throw FaultException in that case either. Checked exceptions w/ default JMS wireFormat over binding.jms should serialize fault, not FaultException -- Key: TUSCANY-2845 URL: https://issues.apache.org/jira/browse/TUSCANY-2845 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Reporter: Scott Kurz I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in binding.ws would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate exception from the fault. True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow? Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2798) Response destination not used in binding.jms when JMSReplyTo is absent
Response destination not used in binding.jms when JMSReplyTo is absent
Key: TUSCANY-2798
URL: https://issues.apache.org/jira/browse/TUSCANY-2798
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Reporter: Scott Kurz
The OASIS JMS Binding spec makes this clear whereas the OSOA doesn't, but if
the JMSReplyTo isn't present on the incoming requestMessage then the response
destination should be used.
Not sure the best place to tweak the code to add this just yet, but you can see
in TransportServiceInterceptor what we do today in sca-java-1.x
public Message invokeResponse(Message msg) {
...
if (requestJMSMsg.getJMSReplyTo() == null) {
// assume no reply is expected
if (msg.getBody() != null) {
logger.log(Level.FINE, JMS service ' + service.getName()
+ ' dropped response as request has no replyTo);
}
return msg;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2799) jmsObject wireFormat always returning Object[] over service response
jmsObject wireFormat always returning Object[] over service response
Key: TUSCANY-2799
URL: https://issues.apache.org/jira/browse/TUSCANY-2799
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Reporter: Scott Kurz
I wanted to note the problem before having time to think through all the issues
and code points we need to sort through.
To start note that WireFormatJMSObjectServiceInterceptor.invokeResponse() does:
...
Object[] response = {msg.getBody()};
But if my service interface is returning a non-array type like a simple String,
it seems more natural to return a single return value rather than an array
here.
Not sure where any OASIS specs or discussions of this issue stand at the
moment...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2658) @Callback should not be required on forward Java interface if component ref/service intf definition fully defines forward/callback interface pair
[ https://issues.apache.org/jira/browse/TUSCANY-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2658: Attachment: 2658.recreate.with.componentType Simon, I have to agree with your point. As much as I wish the user could, in this case, implicitly define a componentType in the component defintion, I have to admit we can't flagrantly violate the Assembly spec without more spec-level discussion. I'd originally hoped to hash out this type of point in the earlier ML discussion I linked to, but no one raised this point before I decided to open the JIRA. As it turns out, even with .componentType files with bidirectional interface definitions, we still apparently have a problem when the forward intf lacks the @Callback, as my updated recreate patch to the original itest/callback-basic shows. So we probably have a code fix to look at in any case...which we can say is the subject of this JIRA. But if there's any interest in exploring the idea of allowing for implicitly define a componentType in the component definition, it can be done outside of this JIRA, since it requires reconsidering of a fundamental Assembly spec statement. Thanks,Scott @Callback should not be required on forward Java interface if component ref/service intf definition fully defines forward/callback interface pair - Key: TUSCANY-2658 URL: https://issues.apache.org/jira/browse/TUSCANY-2658 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Reporter: Scott Kurz Attachments: 2658.recreate, 2658.recreate.with.componentType If we have a component reference/service interface definition which contains a forward/callback interface pair, then our runtime should not also require the @Callback to be present on the forward Java interface. E.g. if we have: component name=CallBackBasicClient implementation.java ... / reference name=aCallBackService target=CallBackBasicService interface.java interface=org.apache.tuscany.sca.test.CallBackBasicService callbackInterface=org.apache.tuscany.sca.test.CallBackBasicCallBack/ /reference ... component name=CallBackBasicService implementation.java .../ service name=CallBackBasicService interface.java interface=org.apache.tuscany.sca.test.CallBackBasicService callbackInterface=org.apache.tuscany.sca.test.CallBackBasicCallBack/ /service /component then we shouldn't require the CallBackBasicService class to carry the annotation: @Callback(CallBackBasicCallBack.class) In modifying the itest/callback-basic test I saw we had this problem (will attach this recreate patch). Issue was discussed here http://www.mail-archive.com/dev@tuscany.apache.org/msg03087.html and the motivating use case was the desire to avoid having to add @Callback to a wsimport-generated Java interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
